OpenAI reconstruyó su backend de Git (Pando) por el tráfico de los agentes de código, según su CTO de Aplicaciones

Por Nate (Nate's Substack) · Fri, 6 Nov 2026.

El correo es la introducción (parte pública) de un artículo de Nate basado en una entrevista con Vijaye Raji, CTO de Aplicaciones de OpenAI. Raji llegó a OpenAI a través de la adquisición de Statsig, la empresa que él fundó.

Según el texto, los agentes de programación de OpenAI aumentaron la cantidad de trabajo que circula por sus sistemas de desarrollo. Los ingenieros pueden perseguir más cambios a la vez, y los agentes recuperan código, ejecutan pruebas y envían su trabajo de forma repetida. La infraestructura que sostenía esas actividades tuvo dificultades para seguir el ritmo.

OpenAI construyó Pando para resolver la parte del problema que afecta al repositorio. La compañía publicó su explicación técnica el 2 de noviembre. El índice del artículo menciona dos cambios de diseño detrás de Pando y una caída de casi el 80 % en la latencia mediana de los push, cifra que según Nate reporta OpenAI. El correo no detalla cuáles son esos dos cambios.

La tesis central del autor es que, cuando una parte del trabajo se acelera, cambia lo que el resto de la organización debe absorber: cada ingeniero individual es más productivo, pero el equipo entrega mucho menos de esa mejora. Propone identificar los retrasos resultantes, entender sus causas y cambiar los sistemas o decisiones responsables. Añade que los agentes también pueden ayudar en ese trabajo.

El índice del artículo completo incluye cinco bloques:

1. Por qué OpenAI reconstruyó su backend de Git: qué hizo el tráfico de agentes al monorepo de OpenAI, los dos cambios de diseño de Pando y la caída cercana al 80 % en la latencia mediana de push.

2. Dónde se estanca la aceleración: el caso de FurtherAI, donde se quintuplicaron los cambios integrados (merged) por ingeniero y el cuello de botella se desplazó hacia las pruebas, la revisión y la decisión de qué construir.

3. Reglas de revisión que un agente puede ejecutar por sí mismo: cómo FurtherAI convirtió comentarios de revisión repetidos en 21 comprobaciones automáticas, cuyos fallos corrigen los agentes antes de que intervenga una persona.

4. Prototipos que estás dispuesto a tirar: el argumento de Vijaye de no apegarse al código y cómo presentar una demo funcional a un equipo sin cerrar el debate.

5. Una revisión de restricciones en siete preguntas: una tabla para rellenar con trabajo reciente, localizar dónde espera el trabajo y ejecutar un experimento.

La conversación completa con Vijaye acompaña a la pieza, y el contenido íntegro, junto con la Library MCP de Nate y su comunidad de Slack, está reservado a suscriptores de pago. El correo termina ahí, por lo que no se dispone de más detalle sobre Pando ni sobre la entrevista.