OpenAI acelera casi cinco veces los envíos a Git con Pando

Un agente ha terminado un cambio, pero las pruebas aún no han empezado: primero hay que enviar los cambios y descargar el código en el entorno de pruebas. Con decenas de tareas en paralelo, la espera de Git puede consumir parte del tiempo ganado con la generación rápida de código. El caso de Pando resulta útil para los equipos que están aumentando el número de agentes y quieren entender dónde aparecerá la siguiente cola.

Qué mostró OpenAI

En un análisis técnico publicado el 2 de noviembre, OpenAI describió Pando, su backend interno de Git. La empresa afirma haber reducido casi cinco veces la mediana de la latencia de push y distribuir casi un petabyte de datos de Git al día. Se ha mantenido la compatibilidad con el cliente y el protocolo de Git.

El sistema se basa en dos decisiones: actualizar distintas ramas de forma independiente y reutilizar paquetes de datos ya preparados para las operaciones de lectura. Sin embargo, leer varias ramas no garantiza obtener una única instantánea de todo el repositorio correspondiente al mismo momento. Pando funciona dentro de OpenAI; la empresa está estudiando cómo compartir la tecnología, pero no ha dado fechas de lanzamiento.

Para llevarlo a la práctica, importa el alcance de la medición. La mediana de la latencia de push describe la demora típica de una operación. No permite calcular cuánto más rápido lanza un equipo su producto. Entre el envío de los cambios y el lanzamiento siguen estando las pruebas, las revisiones, las correcciones y las aprobaciones. Acelerar esta etapa casi cinco veces no promete, por sí solo, una mejora equivalente en la velocidad de desarrollo.

Ejemplo: los agentes preparan varios cambios

Imaginemos el equipo de desarrollo de una tienda en línea. Un agente modifica la búsqueda, otro arregla el carrito y un tercero actualiza las dependencias. Cada uno trabaja en su propia rama. Tras el envío de los cambios, el sistema de pruebas debe obtener la versión adecuada del código y ejecutar las pruebas. Si las comprobaciones arrancan al mismo tiempo, varios lectores acceden al mismo historial del repositorio.

Separar el trabajo por ramas permite tratar estas operaciones de forma independiente. Un cambio en la búsqueda no tiene por qué esperar a una actualización del carrito solo porque ambos estén en el mismo repositorio. A su vez, distribuir repetidamente un paquete ya preparado se parece a enviar el mismo archivo comprimido a varios destinatarios: al servidor le conviene reutilizar los datos que ya ha preparado. Es una ilustración simplificada de los dos principios de Pando, no una descripción de la infraestructura de una tienda concreta.

Pero sigue existiendo otra cola: todavía hay que integrar los cambios. Si dos agentes modifican la misma sección de código, un servidor rápido no decidirá por el equipo qué versión aceptar. Para ello hacen falta reglas que definan quién es responsable de cada tarea, comprobaciones de conflictos y un procedimiento claro de fusión. Conviene medir por separado el rendimiento del almacenamiento y la calidad de la colaboración.

También hay una implicación para la automatización. Si un proceso toma decisiones sobre varias ramas a la vez, debe definir explícitamente qué versiones compara. Por ejemplo, una comprobación de compatibilidad entre dos cambios debe fijar commits concretos. De lo contrario, una nueva ejecución podría comprobar una combinación de código distinta, lo que dificultaría al desarrollador reproducir el resultado.

Qué revisar en tu propio flujo de trabajo

Puedes empezar midiendo una tarea completa, desde que el cambio está listo hasta que llega el resultado de las pruebas. Divide el tiempo entre el envío de los cambios, la obtención del código, la espera de un ejecutor disponible y las propias pruebas. Este desglose mostrará qué etapa está frenando realmente el trabajo. Si la mayor parte de la demora se debe a la cola de pruebas, sustituir el servidor Git tendrá un efecto limitado.

Después, repite la medición con los niveles habituales y máximos de paralelismo. Para el equipo, lo importante es identificar el momento en que añadir agentes deja de reducir el tiempo de ejecución de las tareas. Conviene observar tanto las latencias típicas como las esperas largas ocasionales: estas últimas pueden retrasar una corrección urgente. Los resultados deben compararse con las mismas tareas y el mismo número de comprobaciones.

Estos datos ayudarán a los responsables de producto y a los fundadores a evaluar el coste de acelerar el trabajo. Un agente adicional aporta valor si su resultado recorre todo el proceso hasta convertirse en un cambio aceptado. Si solo crece el número de ramas y de comprobaciones pendientes, conviene resolver primero la cola. La lección práctica de Pando es incluir Git y la entrega del código en la medición de la productividad del desarrollo con agentes. La decisión sobre una nueva infraestructura debería tomarse después, a partir de mediciones propias.