Cuando los agentes tumban a git: Anthropic reescribió su control de versiones en 5 meses

Cuando los agentes tumban a git: Anthropic reescribió su control de versiones en 5 meses

Los agentes de IA ya no son un juguete para demos: están rompiendo herramientas que diseñamos para humanos

Anthropic publicó esta semana un post de ingeniería que debería leer cualquier persona que mantenga infraestructura: reescribieron de cero su sistema de control de versiones en cinco meses porque git ya no daba abasto. No es un fork con otra interfaz ni un refactor de vitrina: construyeron Scion, un sistema propio, y migraron un monorepo con casi 100 GB de historial. ¿El motivo? Sus agentes de código generaban tanto trabajo que git se convirtió en el cuello de botella número uno de la empresa. En mayo mergeaban unos 2.500 cambios diarios; en septiembre, más de 30.000. Diez veces más en cuatro meses, casi todo escrito por modelos.

Acá viene lo que a mí me parece interesante de verdad: la lección no es «git es malo». La lección es que las herramientas diseñadas para humanos, a escala de agentes, dejan de servir. Git asume que el cliente trabaja offline, que cada clone es una copia completa y autónoma, que sincronizar es cosa de seres humanos que tienen el tiempo de hacer push y pull. Nada de eso aplica cuando tus «usuarios» son miles de sandboxes conectadas las 24 horas, que no necesitan poseer el repositorio: solo consultan datos puntuales.

Por eso Scion invierte toda la arquitectura: los clientes son delgados y casi sin estado, y el servidor hace el trabajo pesado. Los commits se crean del lado del servidor, no hay packfiles, no hay refs globales que mover y los checkouts son sparse por diseño. Se acabó el ritual del clone: un job de CI pregunta por el diff y listo. La infraestructura nueva gasta 200 veces menos CPU y memoria que los cientos de mirrors internos de git que operaban antes, y los checkouts de CI pasaron de minutos a segundos. Quien haya mantenido mirrors y sincronización sabe que ese tipo de resultado no es menor.

Y hay un dato que me gusta incluso más: el mismo Claude que creó el problema ayudó a resolverlo. En una parte del post cuentan que le pidieron a un modelo interno reescribir un pipeline de ingesta, sin más instrucciones, y devolvió una versión que usaba 20 veces menos memoria y era 4 veces más rápida, conservando todos los invariantes del sistema. El mismo equipo reconoce que los agentes, por sí solos, violaban restricciones core del sistema y sobre-ingenierizaban por culpa de una revisión adversaria demasiado paranoica. Ahí está el nuevo rol del humano: diseñar, decidir tradeoffs y decirle «no» al modelo. Me resuena con lo que vivo en mi pega: delegar es fácil; saber frenar es lo que vale.

Un detalle que no quiero dejar pasar: el propio Anthropic admite que Scion no le sirve a nadie fuera de su escala. Necesitas un monorepo enorme, miles de agentes pegando código a la vez y un presupuesto de tokens que ningún negocio normal querría gastar. O sea, esto no es un producto ni una guía de «haz esto en tu servidor». Pero el consejo que sí dejan para el resto de nosotros es claro: un servidor de git no tiene que funcionar como un cliente de git. Los forges pueden exponer como API lo mismo que hoy te obliga a clonar: diff, blame, historial de un archivo. Si mantienes CI en infraestructura propia como yo, esa idea te sirve hoy sin migrar nada: revisa qué jobs tienen un clone completo solo para calcular un diff, y pregúntate si de verdad necesitan ese working copy.

Mientras tanto, acá abajo seguimos con git en el VPS, los cron corriendo y los backups fuera del servidor. No por conservadores: a la escala donde operamos, git sigue siendo la herramienta correcta. Lo que cambia es el horizonte del problema. Si los agentes siguen multiplicando el código que se genera, más de una empresa va a acordarse de este post en seis o doce meses, tal como ellos predicen.

Fuente del tema: Redesigning source control at Anthropic, del blog de ingeniería de Anthropic.

Fuente de inspiración: Redesigning source control at Anthropic