Anthropic deja Git: Scion y 30.000 merges al día

¿Qué pasó con Git en Anthropic?

En mayo de 2026, Anthropic fusionaba unas 2.500 modificaciones de código al día. En septiembre, esa cifra superó las 30.000 diarias. Ese salto de más de diez veces en cuatro meses rompió la infraestructura que la compañía había construido para un ritmo humano, y la obligó a hacer algo que casi ninguna empresa hace: escribir su propio sistema de control de versiones.

El resultado se llama Scion, y la migración completa de su monorepo desde Git tomó cinco meses, según el post de ingeniería que la compañía publicó el 13 de octubre de 2026. El detalle que más incomoda al sector: el equipo que lo construyó tiene siete personas.

¿Por qué Git dejó de alcanzar?

Git está diseñado como un sistema descentralizado: cada clon es una copia completa y autónoma del repositorio, capaz de calcular diffs, leer historial y hacer checkout sin conexión. Para la mayoría de los repositorios del mundo ese diseño es correcto, y es buena parte de la razón por la que Git se volvió el estándar. Para el monorepo de Anthropic, se convirtió en un lastre.

Los números que publicó la compañía:

• El historial de su rama principal pesa casi 100 GB, y una copia de trabajo comprimida supera los 25 GB.
• Realiza del orden de 25 millones de checkouts de código por día solo para CI, sin contar entornos de desarrollo, sandboxes de agentes y trabajos de investigación.
• Traído de forma ingenua, eso equivaldría a más de 600 PB de tráfico de Git por día.

Anthropic ya había exprimido todos los atajos convencionales: llegó a operar varios cientos de espejos internos de Git para repartir la carga. Funcionó un tiempo, pero con el ritmo de merges en aumento los espejos se volvieron difíciles de sincronizar y operaciones que dependen del historial, como diff y blame, se volvieron frágiles sobre clones parciales.

La conclusión del equipo es la parte interesante para cualquier empresa que use agentes: sus clientes ya no son laptops de humanos que trabajan offline. Son agentes y trabajos automatizados que están online por definición. Las propiedades que hacen a Git excelente para el trabajo distribuido estaban saboteando su capacidad de escalar.

¿Qué es Scion y en qué se diferencia de Git?

Scion invierte el modelo. El servidor es la única fuente de verdad y los clientes piden solo lo que necesitan. Nada en el sistema requiere una copia completa del repositorio, ni siquiera en el servidor. Los commits, rebases y merges ocurren del lado del servidor, y los checkouts son dispersos por defecto: un trabajo solo baja los archivos que realmente toca.

Los principios que guiaron el diseño, según el post de Anthropic:

• Clientes siempre online. El cliente pide datos cuando los necesita en lugar de mantener una copia completa del repositorio.
• Asimetría cliente-servidor. El servidor responde sobre historial y blame, crea commits, hace merges y rebases. El cliente mantiene una caché local acotada.
• Todo debe escalar horizontalmente. No hay equivalente a los packfiles de Git, así que no hay mantenimiento de repositorio.
• Commits baratos, incrementales y sin locks. El costo de crear un commit escala con el tamaño del cambio, no con el tamaño total del repositorio.

El equipo reconoce que hay antecedentes: menciona Piper de Google y Sapling de Meta como trabajos previos en control de versiones para monorepos gigantes.

Los resultados que reporta la compañía: la huella de infraestructura de Scion es 200 veces menor que su anterior esquema de espejos de Git en CPU y memoria; los trabajos de CI e investigación hacen checkout en segundos en lugar de minutos; y solo CI liberó 25% de capacidad de CPU en su flota.

¿Qué es Antique y por qué importa el code review?

Junto con Scion, el mismo equipo construyó Antique, su herramienta de revisión de código, además de un sistema de búsqueda de código y una capa de permisos para el monorepo, todo en la misma ventana de cinco meses.

Antique permite expresar restricciones semánticas complejas sobre las aprobaciones, de modo que un cambio que solo toca comentarios se distingue de un cambio lógico sensible. Eso deja a los revisores humanos concentrados en lo que de verdad importa, en lugar de revisar línea por línea cada propuesta.

El detalle más incómodo: Claude construyó la herramienta que Claude necesitaba

La ironía que el propio equipo señala es que la capacidad de Claude para escribir código fue tanto la causa del problema como la razón por la que pudieron resolverlo tan rápido.

El ejemplo más concreto está en el pipeline de migración de Git a Scion. La primera versión la escribieron a mano. Cuando tuvieron acceso a un snapshot interno temprano de Claude Mythos Preview, le pidieron que lo reescribiera. Sin más instrucciones, produjo una versión que consumía 20 veces menos memoria y corría cuatro veces más rápido, preservando los invariantes implícitos del orden de ingesta y de las estructuras de datos.

Según Crypto Briefing, reportes de inicios de 2026 indicaban que Claude escribía más del 80% del código de producción fusionado en Anthropic, frente a un dígito porcentual antes de febrero de 2025. El mismo medio reporta que Claude generó 388 pull requests de mantenimiento de forma autónoma, de los cuales cerca del 46% se fusionaron tras revisión humana.

Pero el rol del ingeniero no desapareció, se movió. Los ingenieros del proyecto dicen que hoy calificarían a Claude como mejor escribiendo código que ellos mismos. Su trabajo pasó a ser decir "no": frenar atajos que violan restricciones del sistema y contener código defensivo excesivo, un efecto secundario de la cultura de revisión adversarial que Anthropic usa internamente.

¿Qué significa esto para tu startup?

Probablemente no necesites escribir tu propio sistema de control de versiones. Anthropic lo dice explícitamente: Scion solo tiene sentido para monorepos verdaderamente enormes, con decenas de miles de ingenieros o enjambres de agentes generando código sin parar. Adoptarlo requeriría migrar todo el ciclo de desarrollo, incluidos code review, búsqueda de código y CI propios, y la compañía admite que sus versiones internas son demasiado a medida para que otras organizaciones las adopten tal cual.

Lo que sí es accionable:

• Mide dónde se mueve tu cuello de botella. El mensaje central del post es que cuando el código deja de ser el cuello de botella, el problema se traslada a la infraestructura: control de versiones, builds y CI. Si tu equipo ya usa agentes de código, revisa si tus tiempos de CI y de checkout están creciendo más rápido que tu plantilla.
• Cuestiona tus procesos diseñados "para humanos". Anthropic no logró replicar el estándar de la industria de un lock global en la cola de merges a escala de agentes, y en su lugar invirtió en testing post-merge y pre-deploy. Vale preguntarse qué procesos de tu equipo asumen que un humano escribe y revisa cada cambio.
• Prepara el rol de "decir no". Si vas a usar agentes para escribir código, el valor de tus ingenieros senior se concentra en el diseño de sistemas y en detectar cuándo el agente viola una restricción que no debería. Es una habilidad distinta a escribir código, y conviene entrenarla desde ahora.

Anthropic anticipa que esta clase de problemas se volverá más común en los próximos seis a doce meses a medida que más empresas adopten herramientas de código agéntico. Su apuesta es que las ideas de Scion, como los RPCs del lado del servidor y protocolos de negociación más eficientes, se incorporen a Git en lugar de que cada empresa resuelva el mismo problema por su cuenta.

Conclusión

Scion no es un producto que vayas a instalar. Es una señal de hacia dónde se mueve la infraestructura de desarrollo cuando los agentes escriben la mayor parte del código. El dato que resume el cambio de época no es el 200x de eficiencia ni los 30.000 merges diarios: es que siete personas hayan reemplazado el sistema de control de versiones de una empresa entera en cinco meses, con la misma herramienta de IA que provocó la necesidad de hacerlo.

Para un founder, la lección práctica es de timing. Si tu equipo todavía no siente presión sobre CI y control de versiones, probablemente sea porque el volumen de código generado por agentes aún no llegó a ese punto. Anthropic apuesta a que llegará, y publicó su experiencia justamente para que otras empresas no tengan que descubrir el problema solas.

Fuentes

• Redesigning source control at Anthropic (Simon Willison) (fuente original)
• Redesigning source control at Anthropic (Anthropic Engineering)
• Anthropic Builds In-house Version Of Git Called Scion After Code Merges Rise 12x In 4 Months (OfficeChai)
• Anthropic's daily code merges jump 10x since May as Claude takes over the keyboard (Crypto Briefing)