En mayo de 2026, Anthropic integraba en su rama principal unos 2500 cambios al día. En septiembre ya eran más de 30 000. Anthropic escribe software con Claude más que casi cualquier otra empresa, y el mayor cuello de botella del desarrollo resultó ser git. Hoy el equipo de control de versiones publicó cómo sustituyeron git por su propio sistema, Scion. En la práctica es una alternativa a git pensada primero para agentes de IA y después para personas.
Resumo por qué git dejó de dar abasto, cómo funciona el nuevo sistema, a qué renunciaron y qué sirve en un proyecto normal, con dos o tres agentes en vez de miles. Escribo como alguien con varios repositorios, y en cada uno trabajan agentes de programación. Scion no lo necesito. Algunas de sus ideas, sí, y ya.
Por qué Anthropic necesitó una alternativa a git#
La escala, según el artículo. Solo el historial de la rama principal ocupa casi 100 GB, y una copia de trabajo comprimida supera los 25 GB. Únicamente CI hace del orden de 25 millones de checkouts al día. Con una descarga ingenua serían más de 600 PB de tráfico git diario.
Probaron los trucos habituales: clones shallow y sparse, partial clone, copias preparadas en almacenamiento de blobs. En el pico mantenían varios cientos de espejos internos de git. Con más merges, los espejos costaban más de operar y las copias preparadas se alejaban cada vez más de la punta de main.
Su observación central: git nació como sistema de control de versiones distribuido, para trabajar sin conexión con una copia completa del historial. Sus clientes, en cambio, son agentes y trabajos de CI siempre conectados. Ya usaban git como un sistema de control de versiones centralizado, y el diseño distribuido les estorbaba.
Cómo funciona Scion#
Scion parte de que el cliente siempre está en línea. De ahí sale todo lo demás.
- El servidor hace el trabajo pesado. Historial, blame, commits, merges y rebases se calculan en el servidor. El cliente guarda una caché de objetos acotada, coloca los archivos y vigila el sistema de archivos.
- Un changeset en lugar de un commit. La unidad de trabajo es una entrada en un registro de escritura anticipada (write-ahead log). No apunta a un árbol completo: enumera los archivos cambiados respecto al primer padre. Se crea en el servidor, así que no hay nada que empujar.
- Mover una rama es una operación atómica. Actualizar un ref es un compare-and-swap sobre una fila de Spanner, separado de la creación de changesets. Evitan refs aparte de
mainy las ramas de release, porque el estado global escala mal. - El cliente pide solo lo que le falta. En git el cliente le cuenta al servidor lo que ya tiene. En Scion parte del árbol raíz y pide los árboles y blobs que le faltan. Los objetos son inmutables, así que cualquier caché puede servirlos.
- Tres niveles de servicio.
scion-daemonen cada máquina,scion-cacheregional en memoria yscion-serversobre Spanner y almacenamiento en la nube. Hablan el mismo protocolo, pero los niveles están aislados: si cae una caché regional, no inunda los servidores. - La copia de trabajo es opcional. Muchos trabajos de CI no hacen checkout y usan la API. Cuando hace falta copia, es parcial o virtual: el archivo aparece en disco solo cuando alguien lo lee.
Las ideas no son nuevas, y los autores lo dicen. Para monorepos gigantes ya existían Piper en Google y Sapling en Meta. Lo nuevo es la carga: los clientes son agentes, y hay órdenes de magnitud más que personas.
Los resultados en cifras#
| Métrica | Valor |
|---|---|
| Merges al día | ~2500 en mayo → más de 30 000 en septiembre |
| Infraestructura frente a los espejos git | 200 veces menor |
| Checkout en CI | segundos en vez de minutos |
| CPU de CI | 25 % liberado |
| Aciertos de caché por nivel | más del 99 % |
| Equipo y plazo | 7 personas, 5 meses |
Siete personas construyeron en cinco meses Scion, la herramienta de revisión de código Antique, búsqueda de código, un sistema de permisos y varios servicios relacionados. La migración ocurrió mientras el volumen de merges se multiplicaba por diez. Lo construyeron con Claude: el equipo escribió a mano un prototipo del pipeline de ingesta de git a Scion, y una versión temprana de Claude Mythos Preview lo reescribió para usar 20 veces menos memoria y ser 4 veces más rápido.
A qué renunciaron#
Para mí es la parte más útil del artículo.
No sustituye a git#
Los autores dicen claramente que Scion no sirve como git de uso general. Adoptarlo obligó a reemplazar la revisión de código, la búsqueda y CI. No piensan ofrecerlo fuera: sus herramientas internas son demasiado a medida.
Historial solo de la línea principal#
Un changeset guarda cambios respecto al primer padre. Blame y el historial de rutas están optimizados para main. Eso solo funciona con desarrollo trunk-based.
Sin bloqueo global de la cola de merges#
A este ritmo no pudieron reproducir el bloqueo global de la cola de merges que es estándar en la industria. En su lugar, prueban después del merge y antes del despliegue. A veces los cambios paralelos chocan, y Claude suele arreglar el conflicto antes de que una persona lo note. Para mí es la señal principal: la merge queue se diseñó para el ritmo humano, y con agentes puede salir más fácil sustituirla por otro esquema que escalarla.
El trabajo del ingeniero: decirle "no" a Claude#
Según los autores, la arquitectura y los compromisos los siguen decidiendo personas. Lo más frecuente era decirle al agente que no. Ejemplos del artículo: un agente que recorre el historial de commits a fuerza bruta en vez de consultar la herramienta de revisión, y otro que llena el código de validaciones defensivas tras una revisión adversarial.
Los revisores miran la intención del cambio más que cada línea. Producción la vigilan instancias de Claude separadas, una por componente, a las que llaman "superfans". Leen telemetría y logs y detectan lo que las alertas estáticas no ven.
Qué copiar: monorepo git y agentes de IA para programación, sin Scion#
Mi escala es otra: unos cuantos sitios y apps, con uno o dos agentes en cada uno. Aun así, tres ideas de Scion funcionan con git normal.
1. No clones lo que no necesitas. Partial clone y sparse checkout existen en git desde hace años, y un agente rara vez necesita todo el historial:
git clone --filter=blob:none --sparse https://github.com/org/monorepo.git
cd monorepo
git sparse-checkout set apps/ios packages/sharedPara repositorios grandes está scalar clone, incluido en git desde la 2.38, que activa estos ajustes y el mantenimiento en segundo plano de una vez.
2. Un árbol de trabajo por agente. Hoy un agente publicó un cambio en meteohealth.pro, donde mi rama de trabajo tenía un commit sin subir. No la tocó: creó un worktree aparte desde origin/main:
git worktree add -b fix-key ../site-main origin/main
git -C ../site-main push origin fix-key:main
git worktree remove ../site-mainEs la versión local de la copia de trabajo barata y opcional de Scion.
3. Comprobaciones automáticas y antes del merge. No tengo bloqueo global; ese papel lo cumple un hook pre-push. En meteohealth.pro ejecuta la verificación de tipos, un control de traducciones y la maquetación de la cabecera en 108 combinaciones de idiomas y anchos. Un agente no puede saltárselo pidiéndolo con amabilidad. A las personas les queda juzgar la intención del cambio, igual que en Anthropic.
Lo que no copiaría: renunciar a las ramas y al historial completo. Es un precio razonable con 30 000 merges al día. Con treinta merges a la semana no aporta nada.
Lo que el artículo no cuenta#
- El código fuente, ni siquiera una descripción de la API del cliente
scn. No se puede reconstruir el sistema a partir del texto, y los autores no lo pretenden. - Una comparación con otros enfoques bajo la misma carga. Las cifras de "200 veces" y "segundos en vez de minutos" se miden frente a su propio esquema de espejos git. Nadie lo comparó con Piper ni con Sapling.
- Cuándo lo necesitaremos los demás. Los autores esperan que este tipo de problemas se generalice en 6 a 12 meses y quieren compartir ideas con GitHub, GitLab y la comunidad open source. Qué RPC de servidor y qué modos sparse o shallow propondrán aún no se sabe.
Si tienes un monorepo git y los agentes empiezan a superar en número a las personas, revisa los tres puntos de arriba antes de llegar a los espejos. Cómo dar a los agentes una memoria compartida del proyecto lo explico en el artículo sobre una wiki para agentes de programación vía MCP. Cómo varios agentes se reparten el trabajo sin conflictos, en el de reservas de agentes en una wiki compartida.
