El 13 de octubre, Anthropic publicó un balance de ingeniería en el que revela que tardó cinco meses en migrar todo su monorepo de git a Scion, un sistema de control de versiones desarrollado internamente. En paralelo, también creó una herramienta de revisión de código llamada Antique. El equipo central tenía solo 7 personas.
El origen fue el volumen de merges. En mayo de 2026, el monorepo de Anthropic recibía unos 2.500 merges diarios; en septiembre, la cifra superó los 30.000. El balance señala:
"As our merges per day grew more than tenfold, source control became our biggest development bottleneck."
Cuando nuestros merges diarios crecieron más de diez veces, el control de código fuente se convirtió en nuestro mayor cuello de botella de desarrollo.
Escribir código ya no es lo que frena. Lo que se atasca es el control de código fuente, la compilación y la CI.
Dónde git no da más de sí
Anthropic aporta varias cifras: el historial de la rama principal ronda los 100 GB, la copia de trabajo comprimida supera los 25 GB y la CI realiza cada día unos 25 millones de checkouts. Si cada uno descargara todo, el tráfico diario de git superaría los 600 PB. En las horas punta, la empresa mantiene varios cientos de réplicas internas de git; cuanto más rápido se hacen los merges, más difícil resulta mantener las réplicas y los snapshots preparados.
La causa de fondo que señala el balance es que los objetivos de diseño no coinciden. Git nació para la colaboración distribuida y sin conexión entre personas, con un repositorio completo en manos de cada una; los principales clientes de Anthropic hoy son agentes y tareas automatizadas que están siempre conectados.
Por eso Scion sigue la lógica inversa: historial, blame, commits, merges y rebases residen en el servidor, y el cliente solo conserva una caché local y una copia de trabajo limitadas, con los datos obtenidos bajo demanda. El commit se completa en el servidor y su coste depende del tamaño del cambio, no del tamaño total del repositorio. Solo se mantienen la rama principal y las ramas de lanzamiento; mover un puntero de rama equivale a una operación de comparar e intercambiar (compare-and-swap) sobre una fila de la base de datos. El cliente pasa por un daemon local y cachés por capas antes de llegar al servidor, y la tasa de aciertos de caché en cada capa supera el 99 %.
Echando cuentas
Con las cifras del balance, un cálculo aproximado: 600 PB entre 25 millones de checkouts son unos 24 GB por checkout, lo que encaja con una copia de trabajo de más de 25 GB. Es decir, los 600 PB son un techo estimado suponiendo una descarga completa cada vez.
Repartidos en 24 horas, 30.000 merges son algo más de 20 por minuto. Con el modelo de push de git, cada push exige sincronizar antes con el remoto; a esa frecuencia, los reintentos por conflictos atascan la cola. Scion traslada el merge al servidor y elimina el paso del push. Además, Anthropic abandonó el bloqueo global de merges y confía en pruebas automatizadas posteriores al merge y previas al despliegue; cuando cambios simultáneos chocan, se los encarga a Claude.
El resultado, según los datos de la propia empresa: la infraestructura de Scion consume unas 200 veces menos CPU y memoria que el anterior clúster de réplicas de git; los checkouts para CI y tareas de investigación bajan de minutos a segundos; solo en CI se liberan alrededor del 25 % de la capacidad de CPU.
Qué hizo Claude en todo esto
La propia migración también recurrió al modelo. La canalización de importación de git a Scion, escrita a mano en un principio, fue reescrita por Claude Mythos Preview: el uso de memoria bajó a 1/20 del original y la velocidad aumentó unas 4 veces. El balance afirma que Claude también encontró optimizaciones a nivel de algoritmos y escribió gran cantidad de pruebas, simulaciones y pruebas de fuzzing; el trabajo de los ingenieros pasó a ser mantener la intención del diseño, descartar soluciones poco razonables y revisar la intención de los cambios en lugar de leer el código línea por línea.
El balance no entra en detalle sobre Antique; solo menciona que permite fijar reglas semánticas para las aprobaciones, separando los commits que solo modifican comentarios de los que tocan lógica sensible, para que la revisión humana se concentre en estos últimos.
Scion no es de código abierto. Anthropic lo dice sin rodeos: "Scion is by no means a suitable replacement for git for general use." Los componentes internos están demasiado personalizados para empaquetarlos para terceros. La compañía espera que GitHub, GitLab y la comunidad de código abierto tomen ideas como el RPC en el servidor y el sparse checkout para mejorar git. Piper de Google y Sapling, de código abierto de Meta, recorrieron caminos parecidos; la diferencia es que esta vez la presión para reescribir procede del volumen de código escrito por IA.
Fuentes: Anthropic Engineering Blog, CocoLoop; los merges diarios, el número de checkouts y los factores de consumo de recursos son cifras comunicadas por la propia Anthropic, y el tamaño de cada checkout es un cálculo aproximado de la redacción a partir de esos datos.