Claude escribe tanto código que git dejó de dar abasto en Anthropic. La empresa montó su propio sistema de control de versiones, Scion, y migró su monorepo en cinco meses. No es para todo el mundo, y ellos lo dicen.
Anthropic construye Scion para reemplazar a git en su monorepo
Anthropic publicó el 14 de octubre en su blog de ingeniería cómo dejó atrás git para pasar a Scion, un sistema de control de versiones desarrollado en casa. La razón no es un capricho técnico, sino un problema de escala: el código que escribe Claude disparó el volumen de cambios que la empresa tenía que fusionar cada día.
Los números explican la presión. En mayo de 2026, Anthropic fusionaba unos 2.500 cambios de código al día. En septiembre, la cifra superaba los 30.000. En apenas cuatro meses, la carga se multiplicó por más de diez. El equipo de ingeniería lo resume sin rodeos en el blog: git se diseñó para un ritmo humano, y ellos ya no trabajan a ritmo humano.
Una nota importante antes de seguir: esto no es una herramienta que vayas a instalar. Scion es interno, no se ha publicado como software abierto y la propia empresa advierte que no es un sustituto de git pensado para todo el mundo.
Por qué git se quedó corto en el monorepo
Git no está roto. El problema de fondo está en cómo funciona git. Es un sistema descentralizado: cada copia del repositorio es completa y puede calcular diferencias, leer el historial y consultar quién cambió una línea, incluso sin conexión. Para la gran mayoría de proyectos, esa es la decisión correcta, y por eso git se volvió el estándar.
En el monorepo de Anthropic, ese diseño se vuelve un lastre. El historial de la rama principal pesa casi 100 GB, y una copia de trabajo comprimida supera los 25 GB. La empresa realiza del orden de 25 millones de extracciones de código al día solo para integración continua, antes de contar los entornos de desarrollo, las cajas de arena de los agentes y los trabajos de investigación. Traído de forma directa, eso serían más de 600 petabytes de tráfico diarios.
Los parches no bastaban. La compañía tiró de los trucos habituales: clones superficiales, extracciones parciales, espejos internos de git y copias de seguridad en almacenamiento. Llegó a operar varios cientos de espejos internos. Ganaron tiempo, pero cada vez costaba más mantenerlos a medida que subía el ritmo de fusiones.
La conclusión a la que llegaron fue casi obvia una vez formulada: usaban git como sistema centralizado, con una copia autoritativa, pero casi todos sus clientes eran agentes y tareas que están conectados por definición. Las virtudes de git para el trabajo distribuido y sin conexión estaban saboteando su capacidad de escalar.
Las decisiones de diseño detrás de Scion
Scion parte de una idea contraria a la de git: los clientes siempre están conectados. En lugar de que cada copia guarde todo el repositorio, es el servidor el que responde a las preguntas sobre el historial, crea los cambios y hace las fusiones. El cliente mantiene una caché local acotada y prácticamente no calcula nada por su cuenta.
El cambio es de fondo. Esa asimetría entre cliente y servidor es el corazón del sistema. También lo es que cambia la pieza básica de trabajo: en lugar del commit de git, Scion usa un "changeset" (conjunto de cambios) que guarda solo los archivos que cambiaron respecto a su primer padre, con punteros al contenido comprimido. Se crean en el servidor y están disponibles en todas partes al instante, sin ficheros empaquetados ni bloqueos.
Otra decisión clave: la copia de trabajo es opcional. Como el monorepo es enorme y se extrae decenas de millones de veces al día, muchas tareas ni siquiera necesitan descargar archivos. Preguntan al servidor la diferencia entre dos cambios y listo. Cuando sí hacen falta los archivos, el cliente solo paga por lo que lee de verdad.
Los números asombran. El resultado que reporta la empresa es llamativo. Su infraestructura actual de Scion usa 200 veces menos CPU y memoria que la anterior montada sobre espejos de git. Las tareas de integración e investigación extraen código dos órdenes de magnitud más rápido, en segundos en lugar de minutos, y solo la integración continua se anotó una ganancia de capacidad de CPU del 25 %.
Un equipo de siete personas y cinco meses
El dato que más llama la atención en el blog no es técnico, sino humano. Un equipo de siete ingenieros construyó Scion y Antique (la herramienta de revisión de código), además de media docena de sistemas relacionados, y completó la migración en cinco meses, mientras el volumen de código fusionado se multiplicaba por diez.
El modelo se superó a sí mismo. La propia Anthropic atribuye buena parte de esa velocidad a Claude. Cuenta que reescribió un pipeline de ingesta de git a Scion con un prototipo inicial hecho a mano que consideraban bueno; al pedírselo a una versión interna de Claude, esta produjo una versión que consumía 20 veces menos memoria y era cuatro veces más rápida, sin instrucciones adicionales.
El papel de los ingenieros también cambió. La empresa sostiene que todos los que trabajaron en el sistema ahora calificarían a Claude como mejor escribiendo código que ellos. Su valor, dice, está en el criterio de alto nivel: elegir qué problemas resolver, marcar los límites y decir que no cuando el modelo se pasa de ingenioso. Ponen un ejemplo concreto: un modelo de revisión del propio Claude añadía validaciones excesivas por desconfiar de otro servicio interno, y fueron personas quienes lo frenaron.
Qué significa esto para el resto
No corras a migrar. El hallazgo más útil para quien lee esto con su propio repositorio en mente es que Anthropic no predica una migración masiva. Reconoce que su carga de trabajo es poco común y admite que aún no espera que muchas organizaciones tengan estos problemas a corto plazo. Lo que sí anticipa es que no tardarán en aparecer en otras empresas que usen herramientas de código con IA.
Visto así, Scion funciona como una señal temprana. Si el código generado por IA sigue multiplicando el volumen de cambios, los cuellos de botella dejan de estar en escribir software y se desplazan a la infraestructura que lo sostiene: control de versiones, compilaciones e integración continua. Anthropic acaba de pasarse cinco meses resolviendo uno de esos cuellos de botella. Es probable que otras empresas se enfrenten al mismo.
