Cuando los agentes de código de una empresa empiezan a abrir ramas y a ejecutar tareas en paralelo a gran escala, la parte silenciosa de la cadena de herramientas en la que nadie piensa, el control de versiones, se convierte en lo que se rompe. OpenAI dice que eso es justo lo que le pasó a su propio servicio de Git, y su respuesta fue construir un nuevo backend desde cero. La señal útil aquí no es la herramienta en sí, sino el patrón de carga, con el que se encontrará cualquier equipo que amplíe el uso de agentes en su propia integración continua y control de versiones.
La presión vino de Codex, que permitió a los ingenieros de OpenAI hacer mucho más trabajo a la vez: más ramas, más push, más fetch desde entornos de desarrollo, tareas de investigación y CI. A partir de finales del año pasado, los sistemas tras su monorepo sufrieron, con una fiabilidad que a veces bajaba del 90%, es decir, push y merge lentos o fallidos. En lugar de abandonar Git, OpenAI mantuvo el flujo de trabajo conocido y reconstruyó el backend por debajo, llamando al resultado Pando. Los objetivos de diseño eran escalar las escrituras entre muchas ramas a la vez y servir la misma historia a muchos lectores desde caché.
Los resultados comunicados son notables. Pando redujo la latencia de un push mediano en casi un 80%, y ahora sirve cerca de un petabyte de datos de Git al día, con más de 57 terabytes en una sola hora y más del 99% de esos bytes procedentes de la caché de disco local. OpenAI lo construyó en Rust sin dependencias heredadas, y dice que pasó del arranque a producción en unas 10 semanas, con el propio Codex y una mezcla de modelos haciendo buena parte del trabajo. Empezó a servir tráfico de producción en abril.
La relevancia para el resto de nosotros es el patrón, no el producto. Pando no es de código abierto, así que la mayoría de los equipos no pueden adoptarlo. Solo las mejoras del lado del cliente que OpenAI devolvió a Git son públicas, a través de su propio fork, lo que significa que esto se lee más como una advertencia que como una herramienta: los sistemas en torno a Git se moldearon con dos décadas de flujos de trabajo humanos, y los enjambres de agentes los empujan de formas para las que esas herramientas no se dimensionaron.
Las salvedades honestas son las habituales en una publicación de ingeniería de un proveedor. Las cifras de fiabilidad y latencia son de la propia OpenAI y no se han verificado de forma independiente, y un backend afinado para un monorepo muy grande puede no trasladarse a repositorios más pequeños o de otra forma. Aun así, a medida que más equipos apuntan agentes a sus bases de código, la lección de que el trabajo paralelo de las máquinas tensiona la CI y el control de versiones de formas nuevas vale la pena tomarla en serio antes de que aparezca como merge fallidos propios. Reseñamos OpenAI Codex, el agente que creó esta carga en primer lugar.