Anthropic promediaba 2.500 fusiones de código por día en mayo de 2026. Para septiembre, la cifra superó las 30.000 fusiones diarias: un salto que convirtió a Git en el principal cuello de botella de la compañía y la empujó a construir Scion de Anthropic, su sistema de control de versiones propio, en apenas cinco meses.
La decisión no fue optimizar Git, sino dejarlo atrás. Casi todos los usuarios del monorepo ya no son personas: son agentes de Claude y trabajos automatizados que están conectados todo el tiempo, algo que el diseño original de Git nunca tuvo en cuenta.
TL;DR
- Anthropic migró su monorepo completo de Git a Scion, su sistema propio, en cinco meses durante 2026.- Las fusiones diarias pasaron de 2.500 en mayo a más de 30.000 en septiembre de 2026.- Scion asume que todos los clientes están siempre en línea, al revés del diseño descentralizado de Git.- El historial de la rama principal pesa casi 100 GB, y la copia comprimida supera 25 GB.- Solo en CI, la empresa ejecuta unos 25 millones de checkouts de código por día.
Qué es Scion de Anthropic
Scion de Anthropic es el sistema de control de versiones que la compañía construyó en 2026 para reemplazar a Git en su monorepo. A diferencia de Git, que es descentralizado, Scion asume que el servidor siempre está disponible y que los clientes piden solo los datos que necesitan.
El nombre responde a una idea concreta: tomar lecciones de otros monorepos gigantes, como Piper de Google y Sapling de Meta, pero ajustarlas a un escenario donde los clientes no son laptops de desarrolladores sino flotas de agentes y máquinas efímeras que se conectan, piden datos puntuales y se desconectan. Ahí está la diferencia de fondo con Git: Git se diseñó para que cualquier clon pudiera trabajar sin red; el sistema de Anthropic asume la red como parte del diseño desde el primer día.
Qué pasó
El 13 de octubre de 2026, Anthropic publicó en su blog de ingeniería el relato completo de la migración. En mayo de ese año, la empresa fusionaba en promedio 2.500 cambios de código por día en su monorepo; para septiembre, ese número superó los 30.000 merges diarios, unas doce veces el volumen de cuatro meses antes.
Ese crecimiento no vino de contratar más ingenieros, sino de Claude escribiendo, probando y fusionando código de forma autónoma: iterando sobre ciclos de investigación, haciendo micro-optimizaciones y construyendo servicios nuevos sin supervisión constante en cada paso. El cuello de botella dejó de ser programar y pasó a ser toda la infraestructura pensada para escala humana: control de versiones, builds y CI.
La respuesta de Anthropic fue construir, en cinco meses, un sistema de control de versiones propio (Scion de Anthropic) y migrar el monorepo completo desde Git. En paralelo, el equipo entregó una superficie de revisión de código llamada Antique, un buscador de código interno, un sistema de permisos para el repositorio y nuevas formas de integrar grandes volúmenes de cambios ya revisados.
El historial de la rama principal del monorepo de Anthropic pesa casi 100 GB.
Contexto e historia
Git es un sistema descentralizado: cada clon es un repositorio completo y autónomo, capaz de calcular diffs, leer historial y hacer blame sin conexión a internet. Para la enorme mayoría de proyectos esa sigue siendo la decisión de diseño correcta, y es buena parte de por qué Git se volvió el estándar. El problema de Anthropic es que su monorepo dejó de encajar en ese molde hace tiempo: el historial de la rama principal pesa casi 100 GB, y una copia comprimida del árbol de trabajo supera los 25 GB.
La compañía ya usaba los parches habituales para monorepos gigantes: shallow clones, sparse checkouts, promisor remotes y, sobre todo, cientos de espejos internos de Git más instantáneas (seeds) guardadas en almacenamiento de objetos. En su punto más alto, Anthropic llegó a operar varios cientos de espejos de Git a la vez para repartir la carga. Esos parches ganaron tiempo, pero se volvieron más difíciles de operar a medida que subía la tasa de fusiones: las seeds se alejaban más de la punta de la rama principal entre cada actualización, y mantener funcionando operaciones que dependen del historial, como diff y blame, exigía cada vez más cuidado manual.
El diagnóstico final fue que Anthropic, como casi cualquier empresa, usaba Git como un sistema centralizado con una sola copia autoritativa, cuando casi todos sus clientes (agentes y trabajos automatizados) ya estaban en línea por definición. Las propiedades que hacen a Git excelente para trabajo distribuido y sin conexión eran, en este caso, las mismas que le impedían escalar.
Detalles técnicos: así funciona el reemplazo de Git
El principio central del nuevo sistema es la asimetría cliente-servidor. En Git, cualquier cliente puede actuar como servidor completo: tiene todo el historial y puede responder cualquier consulta sin red. En el sistema que reemplazó a Git en Anthropic, el servidor es quien responde las preguntas sobre historial de archivos y blame, crea commits y ejecuta merges y rebases. El cliente, en cambio, solo mantiene una caché local de objetos con tamaño acotado, escribe los archivos del working copy en disco, vigila cambios del sistema de archivos y le da al usuario, humano o agente, una forma ergonómica de hablar con el servidor.
flowchart TD
A["Agente o CI job"] --> B["Cliente del VCS"]
B --> C["Servidor central"]
C --> D[("Historial y objetos")]
C --> E["Blame, diff, merge, rebase"]
subgraph Servidor
C
D
E
end
Esa asimetría es lo que permite bajar el consumo de red y disco: el cliente calcula poco por sí mismo, pero a cambio necesita muchísima menos información guardada localmente. Anthropic calcula que, si sus 25 millones de checkouts diarios de CI se sirvieran con Git de forma ingenua, clonando el repositorio completo cada vez, el tráfico superaría los 600 petabytes de datos por día. Con el cliente liviano, cada checkout solo pide los archivos y objetos que la tarea puntual necesita.
El otro cambio estructural es que todas las consultas de control de versiones quedan expuestas como API, no solo como comandos de un cliente. Con Git, un job de CI que necesita saber quién modificó una línea por última vez, o cómo se relacionan dos commits, tiene que mantener una copia local del repositorio o depender de una API específica de un proveedor externo. Con el nuevo sistema, esas mismas consultas están disponibles por API, así que en muchos casos un job no necesita repositorio local en absoluto. Esa propiedad habilitó herramientas internas nuevas, como bisect automatizado y reversión de cambios, construidas directamente sobre la API del servidor.
Anthropic operó varios cientos de espejos de Git antes de construir su reemplazo.
Impacto y análisis
El caso de Anthropic es, por ahora, una anomalía: pocas empresas fusionan 30.000 cambios de código al día. Pero la compañía argumenta que el patrón no es exclusivo de ellos. Cualquier organización que deje que Claude o modelos equivalentes escriban y fusionen código de forma autónoma, sin que un humano revise cada línea antes de cada commit, va a chocar antes o después con los mismos límites de diseño de Git: un sistema pensado para que cada desarrollador trabaje offline, en un mundo donde el cliente típico ya es un agente permanentemente conectado.
El sistema de control de versiones de Anthropic no resuelve el problema solo migrando de herramienta. Construirlo exigió, en paralelo y en los mismos cinco meses, rehacer la revisión de código, el buscador interno y el sistema de permisos del repositorio: un rediseño completo de la cadena que va de que Claude escriba un cambio a que ese cambio quede fusionado y auditable en el monorepo.
💭 Clave: el propio texto de Anthropic lo resume así: Claude fue a la vez la causa del problema, por el volumen de código que genera, y la herramienta que permitió resolverlo rápido, al ayudar a construir un sistema de control de versiones nuevo en cinco meses.
La limitación obvia es que este enfoque centralizado tiene un costo. Si el servidor del VCS interno de Anthropic cae, ningún cliente puede operar sin conexión, a diferencia de un repositorio Git clonado localmente. Para un monorepo con cientos de agentes y pipelines de CI dependiendo de ese servidor en todo momento, la disponibilidad del servidor pasa a ser, literalmente, la disponibilidad de poder programar.
Qué sigue
Anthropic no publicó una fecha para liberar como proyecto abierto el sistema que reemplazó a Git, y nada en el anuncio sugiere que lo vaya a hacer pronto: está hecho a medida para su propio monorepo y su propia escala de uso de agentes. Lo que sí confirmó la empresa es que va a seguir invirtiendo en esta infraestructura, porque la demanda interna de fusionar código es, en sus palabras, prácticamente infinita. Cada cuello de botella que eliminan dispara de inmediato un aumento en la cantidad de código que producen.
El caso vale como referencia para cualquier equipo que esté evaluando cuánto código puede empezar a fusionar un modelo como Claude sin intervención humana directa. Si la tasa de cambios por día se multiplica por doce en cuatro meses, como pasó en Anthropic entre mayo y septiembre de 2026, la pregunta deja de ser qué modelo usar y pasa a ser qué tan rápido se cae la infraestructura de desarrollo detrás de él.
📖 Resumen en Telegram: Ver resumen
Probalo vos: leé el anuncio técnico completo de Anthropic y fijate cuántos de los 25 millones de checkouts diarios que describen se parecen a los de tu propio pipeline de CI.
Preguntas frecuentes
¿Qué es el VCS interno de Anthropic y para qué sirve?
Es el sistema de control de versiones que Anthropic construyó para reemplazar a Git en su monorepo principal. Sirve para que agentes de Claude, pipelines de CI y desarrolladores humanos lean, modifiquen y fusionen código sin que cada cliente necesite una copia completa del historial.
¿Por qué Anthropic no se quedó con Git?
Porque el diseño descentralizado de Git, pensado para clientes que trabajan offline, dejó de encajar cuando casi todos los clientes del repositorio pasaron a ser agentes y trabajos siempre conectados. Mantener espejos y seeds de Git se volvió más difícil de operar a medida que las fusiones diarias crecieron de 2.500 a más de 30.000.
¿Cuánto tardó Anthropic en migrar de Git al nuevo sistema?
Cinco meses. En ese mismo período, el equipo también construyó Antique, su superficie de revisión de código, un buscador de código interno y un sistema de permisos para el repositorio.
¿En qué se inspiró Scion de Anthropic?
En proyectos previos de control de versiones a escala de monorepo, como Piper de Google y Sapling de Meta, que ya habían resuelto parte de los mismos problemas de escala para sus propios repositorios gigantes.
¿Qué pasa si el servidor del sistema de control de versiones de Anthropic falla?
A diferencia de un repositorio Git clonado, donde cada copia local sigue funcionando sin conexión, los clientes de este sistema dependen de que el servidor esté disponible para casi cualquier operación, desde hacer un commit hasta consultar el historial de un archivo.
Referencias
- Anthropic Engineering: el anuncio original sobre la migración de Git a Scion de Anthropic, publicado el 13 de octubre de 2026.- Wikipedia: ficha sobre Piper, el sistema de control de versiones interno de Google que inspiró parte del diseño.- Sapling: sitio oficial del sistema de control de versiones de Meta, la otra referencia citada por Anthropic.- Git: documentación oficial del sistema de control de versiones que Anthropic reemplazó en su monorepo.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (1)
good