OpenAI reescribe su backend Git: lecciones para tu pyme

OpenAI ha detallado cómo ha construido un nuevo backend de Git para su monorepo. El proyecto, bautizado como Pando, nace de un problema muy concreto: su infraestructura Git tradicional se estaba quedando corta ante el volumen de commits que generan sus desarrolladores y, sobre todo, sus agentes de código. Según la compañía, los commits trimestrales a su monorepo habrán crecido más de un 2.400% a finales de este año respecto al primer trimestre de 2024. Y su backend anterior bajaba del 90% de fiabilidad, con fetches lentos y merges fallidos.

La decisión de OpenAI no fue abandonar Git, sino reescribir la forma de servirlo. El equipo se preguntó si habían llegado a un límite de Git en sí o de cómo servían su monorepo. La respuesta: el cliente y el protocolo Git no eran el problema, sino la arquitectura de los servidores Git convencionales. Pando mantiene la compatibilidad con Git, algo que les importaba porque llevan más de dos décadas construyendo herramientas alrededor de ese ecosistema.

Qué cambia Pando respecto a un servidor Git al uso

Pando elimina dos supuestos que casi todos los servidores Git tratan como obligatorios. El primero es mantener todas las ramas del repositorio en un estado consistente al mismo tiempo. El segundo es generar un packfile personalizado para cada cliente que hace fetch. En Git, una rama es un puntero al último commit, y mover ese puntero es la única parte de un push que requiere coordinación. Los servidores convencionales ordenan esas actualizaciones en todo el repositorio, de modo que un push a la rama de un agente puede quedar esperando a otro. Pando, en cambio, gestiona cada rama por separado, así que los pushes a ramas no relacionadas no se bloquean entre sí.

El tradeoff que asume OpenAI es que un cliente que mira varias ramas a la vez puede verlas en instantes ligeramente distintos. En la práctica, argumentan, tanto personas como agentes solo se preocupan por el orden de actualizaciones dentro de una misma rama. Al hacer push, Pando valida el packfile entrante mientras lo transmite a almacenamiento de blobs, sin descomprimirlo en un repositorio local. Registra la nueva punta de rama, la ubicación del packfile y sus dependencias en un almacén de metadatos. Por defecto, solo anuncia la rama troncal como base para los pushes de ramas de características, lo que hace que cada pack sea reutilizable por otros clientes que ya tienen esa historia.

En la lectura, Pando selecciona los packs almacenados que necesita cada cliente según la historia que ya posee y devuelve enlaces de descarga mediante packfile-uri, una característica del protocolo Git que permite descargar packs por separado. Un servicio de caché llamado Express los sirve desde cachés regionales con una tasa de acierto superior al 99%, según la compañía. En máquinas virtuales cloud estándar, clones y fetches pueden saturar un enlace de red de 10 Gbps. Los workers en segundo plano fusionan packs pequeños en otros más grandes con el tiempo, de forma parecida a como una base de datos log-structured compacta sus datos.

Por qué esto importa a una pyme

Puede parecer un problema de hiperescala, pero la tendencia nos afecta antes de lo que parece. OpenAI construyó Pando en Rust en 10 semanas, con un ingeniero diseñando el núcleo y equipos de agentes Codex implementándolo, y entró en producción en abril. No hace falta ser OpenAI para notar que los agentes de código multiplican los commits. Si tu equipo empieza a usar asistentes que abren ramas y hacen pushes de forma automática, el cuello de botella puede aparecer antes de lo previsto.

Para una pyme o un equipo IT mediano, las lecciones son más de higiene que de ingeniería extrema:

• Mide antes de optimizar. Si los tiempos de clone, fetch o push se degradan, revisa si el problema es la red, el tamaño del repositorio o el número de ramas activas. No asumas que Git es el culpable.
• Controla la proliferación de ramas. Los agentes tienden a crear ramas efímeras. Una política de limpieza y nombres claros evita que el servidor tenga que anunciar miles de referencias.
• Valora monorepos con criterio. Un monorepo facilita la coherencia, pero exige disciplina de empaquetado y caché. Si tu equipo es pequeño, quizá no necesites monorepo, pero sí un flujo de integración continua bien afinado.
• Revisa la revisión de código con IA. Cuando los agentes generan commits, la verificación humana y automatizada se vuelve crítica. En ForgeNEX ya hemos hablado de revisión de código con IA: verificar agentes, decidir personas, y este caso lo refuerza.
• No descartes la infraestructura gestionada. GitHub también está invirtiendo en mejorar su infraestructura. Para muchas pymes, la opción sensata es apoyarse en un proveedor que ya esté resolviendo estos problemas, en lugar de montar un backend propio.

Nuestra recomendación desde ForgeNEX

La noticia confirma una tendencia: la IA generativa está cambiando no solo lo que escribimos, sino cómo lo versionamos. Si estás introduciendo agentes en tu ciclo de desarrollo, empieza por medir el impacto en tu repositorio y en tus pipelines. Define límites de ramas, automatiza la limpieza y revisa la factura de tokens y de cómputo. Como comentamos en IA híbrida: el PC con agentes frena la factura de tokens, no todo debe ir al cloud sin control.

Pando no es una herramienta que vayas a instalar mañana en tu pyme, pero sí es una señal de hacia dónde va el desarrollo asistido por agentes. Mantén Git compatible, mide la latencia de tus operaciones y no dejes que la comodidad de los agentes te cree un monorepo inmanejable. La infraestructura también se diseña.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.