La fiabilidad cayó por debajo del 90%
OpenAI publicó el lunes un relato de por qué reconstruyó la capa de almacenamiento bajo su monorepositorio, y el diagnóstico es directo. “Hacia finales del año pasado, los sistemas que sostenían nuestro monorepositorio empezaban a no dar abasto”, escriben Aaron Friel, Taylor Blau y Ted Nyman, miembros del personal técnico. “Sufrimos descargas y envíos lentos junto con fusiones fallidas, con una fiabilidad que a veces caía por debajo del 90%”.
La causa que señala el texto es Codex. El desarrollo asistido por agentes significa más ramas, más envíos, más fusiones y más descargas y clonaciones desde entornos de desarrollo, trabajos de investigación e integración continua. Un solo ingeniero puede tener ahora varios cambios en cola para integración continua, y cada envío pone varios trabajos a descargar el mismo commit.
Qué es Pando
Pando es un nuevo backend para repositorios Git. Ahora sostiene todo el desarrollo del monorepositorio de OpenAI y se desplegó sin interrumpir el trabajo de ingeniería ni cambiar la forma en que el equipo usa Git: el protocolo de Git y el cliente estándar siguen funcionando.
Dos decisiones de diseño hacen el trabajo. Pando coordina las actualizaciones de cada rama por separado, de modo que los envíos a ramas no relacionadas avanzan en paralelo. Y reutiliza los packfiles —el formato de Git para comprimir objetos juntos— entre descargas en vez de construir uno nuevo por cliente, así el servidor puede servir los mismos bytes a muchos lectores con poco cálculo.
Ambas decisiones tienen un coste declarado. Quien mira varias ramas puede verlas en momentos distintos en el tiempo, y un cliente puede descargar objetos que ya tiene.
Las cifras
OpenAI informa de que en producción Pando redujo la latencia mediana de envío casi cinco veces y de que ahora entrega cerca de un petabyte de datos de Git al día. Ambas cifras son de la empresa, de su propia infraestructura, sin ninguna medición externa a su lado.
El equipo dice que quiere enviar mejoras desde su propia copia de Git al proyecto Git original, lo que haría útil fuera de OpenAI el trabajo hecho en el cliente.
Por qué importa más allá de un monorepositorio
Lo interesante no es la arquitectura. Es que un laboratorio de frontera chocó con un muro de escala en el control de versiones antes que en cualquier sitio más exótico, porque su propio agente de programación genera ramas más rápido de lo que el utillaje de debajo estaba hecho para absorber. Cualquier organización que adopte agentes al mismo ritmo hereda el mismo cuello de botella sin la opción de reescribir el backend de Git.
Qué observar
Cuáles de los cambios de Git de OpenAI llegan al proyecto original, y si otras empresas que operan agentes de programación a escala informan del mismo fallo en su control de versiones antes que en ningún otro sitio.
