El 13 de octubre, Anthropic publicó una entrada detallando cómo sustituyó Git por un sistema
de control de versiones propio, llamado Scion, en todo su monorepo interno. La empresa explica
que el crecimiento del volumen de código generado por sus propios agentes Claude acabó saturando
la infraestructura clásica de Git, pensada para desarrolladores humanos y no para miles de
clientes automatizados siempre conectados.
Un volumen de cambios multiplicado por doce en cuatro meses
El número de cambios fusionados cada día en el monorepo pasó de unos 2.500 en mayo de 2026 a
más de 30.000 en septiembre. El historial de la rama principal pesa casi 100 GB, y una copia de
trabajo comprimida supera los 25 GB. Solo las verificaciones de integración continua suponían
unos 25 millones de clonados diarios, antes de contar siquiera los entornos de desarrollo, los
entornos aislados de los agentes y las tareas de investigación.
Por qué Git dejó de ser suficiente
El modelo de Git se basa en una copia completa del historial en cada clonado, una opción
razonable cuando los clientes son máquinas de desarrolladores que se conectan ocasionalmente. En
Anthropic, casi todos los clientes son agentes o tareas de integración continua siempre
conectados: obtener el historial de forma ingenua habría supuesto más de 600 petabytes de
tráfico Git al día. Para compensarlo, la empresa operaba varios cientos de réplicas internas de
Git, una infraestructura que se convirtió en sí misma en el principal centro de coste.
| Indicador | Antes (réplicas Git) | Con Scion |
|---|---|---|
| Cambios fusionados / día | ~2.500 (mayo de 2026) | >30.000 (septiembre de 2026) |
| Huella de CPU/memoria de la infraestructura | Referencia | ~200 veces menor |
| Duración de un clonado en CI | Varios minutos | Segundos |
| Capacidad de CPU disponible para CI | Referencia | +25 % |
| Tasa de aciertos de caché (por nivel) | Variable | >99 % |
Scion y Antique: la arquitectura elegida
Scion sustituye el modelo de Git por un registro de escritura anticipada: cada
changeset describe los archivos modificados respecto a su primer padre y apunta a blobs
direccionados por contenido, sin archivos pack ni bloqueo de referencias. Los datos
derivados (blame, historial de rutas, grafo de commits) se calculan de forma recursiva a partir
de los changesets padres, y los clientes solo obtienen los árboles y blobs que realmente
necesitan, lo que hace que los clonados parciales sean nativos, sin configuración especial. Tres
niveles de servicio (un demonio local, cachés regionales, servidores autorizados respaldados por
Spanner) mantienen cada uno una tasa de aciertos de caché superior al 99 %. Antique, la
herramienta de revisión de código asociada, completa el conjunto con búsqueda de código y
permisos detallados por origen.
Historial Git clásico:
clonado completo -> bloqueo de referencias -> packfiles -> fetch costoso para un agente
Modelo Scion:
changeset (registro de escritura anticipada) -> blobs por contenido -> fetch parcial
por niveles (demonio local / caché regional / servidor Spanner), >99% de aciertos
«El cuello de botella, ahora, es toda la infraestructura de desarrollo construida para la escala humana.»
Scion no es un producto público ni un sustituto generalista de Git: Anthropic lo precisa
explícitamente en su entrada. El interés para los equipos web ordinarios sigue siendo indirecto,
pero ilustra una tensión que alcanzará a otros proveedores de herramientas a medida que los
pipelines impulsados por agentes de código generen un volumen de cambios que las colas de fusión
clásicas no fueron diseñadas para absorber.
Un equipo de siete personas, cinco meses de migración
La construcción de Scion, Antique y alrededor de media docena de sistemas asociados movilizó a
siete personas durante cinco meses, con Claude escribiendo buena parte del código de migración.
Los ingenieros describen su papel como principalmente decirle no a Claude cuando buscaba
sobrediseñar una solución, y revisar la intención de los cambios en lugar de cada línea. La
entrada llega a afirmar que todos los ingenieros que trabajaron en el proyecto consideran ahora a
Claude mejor que ellos escribiendo código, una afirmación que conviene tomar con la prudencia
habitual tratándose de un texto publicado por el propio creador del modelo, pero que coincide con
testimonios similares en otras partes del ecosistema, incluido en torno al protocolo MCP y su
rápida adopción en las cadenas de herramientas agénticas.
Lo que hay que recordar
El caso de Anthropic sigue siendo extremo, propio de una empresa que hace funcionar sus
propios agentes a muy gran escala sobre su propio código. Aun así, ofrece una señal útil: las
herramientas de control de versiones e integración continua pensadas para humanos conectados de
forma ocasional empiezan a mostrar sus límites frente a clientes automatizados permanentes, y es
probable que las alternativas a Git centradas en el servidor ganen visibilidad en los próximos
meses, sin por ello sustituir a Git para la inmensa mayoría de los equipos.
Sigo siendo escéptico sobre el alcance práctico de este tipo de anuncios para la mayoría de
los equipos con los que trabajo: ninguno se acerca, ni de lejos, a los 30.000 cambios diarios que
motivaron este proyecto. Lo que sí me parece a vigilar es la presión creciente que los agentes de
código ejercen sobre las CI clásicas, incluso a una escala mucho más modesta, un asunto que ya
afecta a los proyectos en los que intervengo. — Simon Janvier
Para profundizar: la entrada completa está disponible en
el blog de ingeniería de Anthropic.
