Escalando Git en OpenAI
El crecimiento explosivo del código generado por IA está llevando la infraestructura Git de OpenAI a sus límites, lo que ha impulsado un sistema personalizado (“Pando”) para manejar monorepos a escala de petabytes y decenas de miles de commits al día. Los comentaristas debaten si esto refleja auténticas ganancias de productividad o simplemente “AI slop” — enormes cantidades de código redundante, de baja calidad o reescrito constantemente que los humanos ya no pueden comprender o revisar por completo. El hilo plantea cuestiones más amplias sobre mantenibilidad, seguridad y el papel futuro de los desarrolladores humanos mientras los grandes laboratorios rediseñan el control de versiones para el desarrollo de software impulsado por agentes.
Explosión percibida de código y commits
- Muchos se quedan atónitos por el enorme volumen de commits/LOC y cuestionan cómo puede ser un activo en lugar de una carga.
- Otros señalan que, en relación con el tamaño de la empresa, el volumen puede ser “moderado”, y que las métricas tradicionales de LOC están dejando de ser tan significativas como el tamaño del repositorio y los patrones de rotación.
“Slop” generado por IA vs productividad
- Varios comentaristas describen la salida de los agentes de IA como un “slop” voluminoso: abstracciones sobredimensionadas, lógica duplicada, comentarios interminables y commits de “arreglo” sin fin.
- Informan que tareas pequeñas se convierten en enormes recuentos de tokens y commits, con agentes parcheando repetidamente sus propios errores.
- Quienes lo apoyan argumentan que esto es aceptable si el cómputo es barato: el código y las pruebas pueden regenerarse o refactorizarse repetidamente hasta cumplir los benchmarks.
Supervisión humana, confianza y responsabilidad
- Un sector argumenta que los LLM pueden escribir y revisar de forma fiable la mayor parte del código, y que los humanos solo se necesitan para casos fuera de distribución o de alto riesgo.
- Los críticos enfatizan los incentivos (la gente es despedida por mal código, los modelos no), las responsabilidades regulatorias y con los datos de clientes, y la necesidad de que alguien entienda de verdad cómo se procesan los datos.
- Hay preocupación de que los gerentes terminen teniendo que responder “no lo sé, el modelo lo hizo”, y de la pérdida de capacidad humana para depurar.
¿Qué hace todo este código?
- Entre las especulaciones figuran: entornos de RL, infraestructura de entrenamiento/serving, apps internas, experimentación masiva y capturar cada edición del agente para entrenamiento.
- Otros sospechan duplicación, scripts efímeros y “cachear” código generado que podría regenerarse bajo demanda.
- A algunos les preocupa que el beneficio para los usuarios no esté claro dada la relativamente modesta cantidad de cambios visibles en el producto y, a veces, las aplicaciones cliente torpes.
Git, monorepos y modelos alternativos de VCS
- Varios señalan que Git ya tuvo problemas a gran escala en monorepos (Meta, Google); OpenAI está alcanzando límites similares o peores con flujos de trabajo impulsados por agentes.
- Se debate si esto es fundamentalmente un problema de monorepo, un problema de Git o un nuevo caso de uso a “escala de agentes” (alta tasa de commits, uso tipo instantánea/registro).
- Algunos argumentan que los grandes actores deberían adoptar topologías de VCS completamente nuevas y centralizadas en lugar de estirar Git; otros ven a Git evolucionando más bien hacia una capa de protocolo.
Implicaciones más amplias
- Algunos ven esto como una prueba impresionante de que los LLM pueden construir sistemas complejos rápidamente.
- Otros lo ven como una advertencia: codebases que explotan, superficies de ataque mayores y una cultura de desarrollo que optimiza el rendimiento por encima de la claridad y la mantenibilidad.