Anthropic pasó de 2,500 a 30,000 cambios fusionados al día. Las suposiciones de Git se rompieron antes que Git
Anthropic reemplazó Git internamente con Scion tras multiplicarse las fusiones por los agentes. La mayoría de empresas nunca necesitará Scion; las suposiciones que descartó merecen revisión.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
En mayo de 2026, alrededor de 2,500 cambios al día se fusionaban en el repositorio principal de Anthropic. Para septiembre, más de 30,000 lo hacían. La historia de main se acercaba a los 100 GB, una copia de trabajo comprimida superaba los 25 GB, y CI ejecutaba alrededor de 25 millones de checkouts al día, sin contar entornos de desarrollador, sandboxes de agentes y trabajos de investigación. Extraídos de la forma habitual, Anthropic estima que esa carga habría superado los 600 PB de tráfico de Git al día.
El post de ingeniería de Anthropic, publicado el 13 de octubre, describe lo que hizo después: trasladó su monorepo de Git a un sistema interno llamado Scion, construido por un equipo de siete personas en unos cinco meses, junto con una herramienta de revisión de código llamada Antique. El post es inusualmente franco sobre los límites de su propia lección. Anthropic dice que su uso de Claude para programar, y su gasto interno en tokens, están muy por encima de los presupuestos empresariales típicos, y que Scion no es un reemplazo general de Git. Su consejo para todos los demás es llevar las ideas útiles a Git.
Ese consejo es la razón para leerlo. Lo interesante no es que Git se rompiera. Es cuáles de las suposiciones de Git dejaron de ser ciertas.
| Diseñado para personas | A escala de agente, según Anthropic | |
|---|---|---|
| Clientes | Desarrolladores que a veces trabajan sin conexión con una copia completa | Casi todos los clientes son agentes o trabajos siempre conectados |
| Commits | Hechos localmente, luego enviados | Hechos en el servidor; nada que enviar |
| Checkouts | Todo el árbol de trabajo | Solo los archivos que lee un trabajo, o ningún checkout |
| Orden de fusión | Una cola que serializa las fusiones | Pruebas posteriores a la fusión y previas al despliegue; un bloqueo global no es práctico |
| Revisión | Una persona lee cada línea | Reglas de aprobación semántica separan cambios triviales de los sensibles |
La descentralización dejó de ser rentable
Git fue diseñado para que cada desarrollador tenga el historial completo y pueda trabajar desconectado. En Anthropic, casi todos los clientes eran un agente o un trabajo de CI que siempre está en línea y necesita unos pocos directorios. Llevar el historial completo a cada uno de ellos era puro costo. El cliente de Scion obtiene contenido bajo demanda de un servidor, mantiene una caché acotada y permite que muchos trabajos omitan por completo un checkout al consultar el control de código fuente a través de APIs. Anthropic reporta checkouts aproximadamente dos órdenes de magnitud más rápidos, de minutos a segundos, una ganancia de alrededor del 25% en capacidad de CPU de CI, y una huella aproximadamente 200 veces menor que su infraestructura de espejo de Git anterior.
La mayoría de las empresas no alcanzará estos volúmenes. Muchas alcanzarán la versión más pequeña: sandboxes de agentes y runners de CI que clonan cada uno un repositorio grande, espejos que se quedan atrás de main, y minutos de compilación que crecen más rápido que el equipo. Los checkouts dispersos, los clones superficiales y las operaciones del lado del servidor ya existen en Git, y son lo primero que hay que probar.
El cuello de botella se traslada a la revisión y la fusión
Las lecciones más transferibles están en las dos últimas filas. Con decenas de miles de fusiones al día, una cola de fusión que serializa los cambios no puede seguir el ritmo, por lo que Anthropic confía en pruebas posteriores a la fusión y previas al despliegue, y dice que Claude suele resolver conflictos entre fusiones concurrentes más rápido de lo que las personas los notan. Y la revisión cambia de forma: Antique admite reglas de aprobación semántica, por lo que un cambio que solo contiene comentarios no se trata como uno sensible, y los revisores se centran en la intención de un cambio en lugar de leer cada línea.
Para una empresa, ambas son decisiones de gobernanza disfrazadas de herramientas. Mover las pruebas después de la fusión significa aceptar que main puede romperse brevemente e invertir en detección rápida y rollback. Dejar que las reglas decidan qué cambios necesitan a una persona significa escribir de antemano qué rutas y tipos de cambio son sensibles. Ese es el mismo ejercicio que recomendamos para tratar a los agentes como autores de cambios en producción: clases de cambio, con la aprobación que cada una necesita, decididas antes de que llegue el volumen.
Dónde mirar antes de que llegue el volumen
La producción de los agentes no necesita multiplicarse por doce para tensionar su sistema de entrega. Un equipo que duplica sus pull requests con agentes de programación encontrará el límite primero en los revisores, luego en la capacidad de CI, después en la cola de fusión, y solo mucho más tarde en el propio control de código fuente. La ejecución nocturna de agentes de Google planteó el mismo punto a pequeña escala: de seis cambios propuestos, los ingenieros conservaron dos, y la revisión fue el trabajo.
Vale la pena hacer seguimiento mensual de tres números a medida que se difunden los agentes de programación: cambios fusionados por día, tiempo medio que un cambio espera para revisión, y minutos de CI por cambio fusionado. Cuando el primero crece y los otros dos crecen más rápido, su Git está bien. Su proceso es lo que ha alcanzado el problema de Anthropic, solo que antes en la curva.