Anthropic Scion: por qué dejó git y qué te enseña a ti
Anthropic Scion sustituye a git en su monorepo: de 2.500 a más de 30.000 merges al día. Qué cambia en el control de versiones y qué debes preparar en tu flujo.
En mayo de 2026, el monorepo de Anthropic recibía unos 2.500 merges al día. En septiembre recibía más de 30.000.
Casi todos los clientes del repo eran ya agentes y jobs automáticos. Y en algún punto de esa curva, git dejó de ser una herramienta y pasó a ser un problema de infraestructura.
El 13 de octubre de 2026, Anthropic publicó cómo lo resolvió: Anthropic Scion, un sistema de control de versiones propio que sustituye a git en su monorepo. El titular que más circuló fue "Anthropic abandona git". Es verdad, pero no es lo interesante.
Lo interesante es dónde se rompió primero. No fue el código. Fue todo lo que pasa después de escribirlo.
En corto: Anthropic sustituyó git por Scion, un control de versiones centralizado propio, porque su monorepo pasó de 2.500 a más de 30.000 merges diarios, con agentes como clientes principales. La propia Anthropic dice que Scion no sirve como reemplazo general de git. La lección para ti no es cambiar de herramienta: es que, cuando los agentes escriben el código, el cuello de botella se mueve a la integración y a la revisión.
¿Qué es Anthropic Scion?
Anthropic Scion es el sistema de control de versiones centralizado que Anthropic construyó para sustituir a git en su monorepo, diseñado para clientes que siempre están online —sobre todo agentes y jobs de CI— y en el que el servidor, no el cliente, crea los commits y hace los merges.
Viene acompañado de Antique, su herramienta de code review. Lo construyó un equipo de 7 personas y la migración duró 5 meses, según el post de ingeniería de Anthropic. Por debajo, mover una referencia (lo que en git sería actualizar una rama) es un compare-and-swap sobre una fila de Spanner: por eso los commits no necesitan locks.
Por qué Anthropic dejó git en su monorepo
La respuesta corta: usaban git como si fuera centralizado, y git está diseñado para lo contrario.
Git asume que cada developer tiene una copia completa, trabaja offline y sincroniza de vez en cuando. Anthropic tenía casi todos sus clientes siempre conectados: agentes y jobs. El diseño distribuido, que es la gran virtud de git, jugaba en su contra.
Las cifras que publica Anthropic lo dejan claro:
| Métrica (fuente: Anthropic, oct 2026) | Valor |
|---|---|
| Merges diarios en mayo 2026 | ~2.500 |
| Merges diarios en septiembre 2026 | más de 30.000 |
Historial de main |
casi 100 GB |
| Working copy comprimida | más de 25 GB |
| Checkouts al día solo para CI | ~25 millones |
| Tráfico git diario con un fetch ingenuo | más de 600 PB |
| Mirrors internos de git en el pico | varios cientos |
Ya usaban shallow clones y sparse checkouts. No bastaba.
Git vs Anthropic Scion: dos modelos de control de versiones
Scion no es "un git más rápido". Es otro modelo, más cercano a SVN o Perforce que a git.
| Git | Scion | |
|---|---|---|
| Modelo | Distribuido, pensado para trabajar offline | Centralizado, clientes siempre online |
| Dónde se crean commits y merges | En el cliente; luego push |
En el servidor; no existe push |
| Copia del repo | Cada clon tiene la historia completa (o parte, con shallow/sparse) | No existe copia completa en ningún sitio, ni siquiera en el servidor |
| Working copy | Necesaria para trabajar (salvo repos bare) | Opcional, sparse o virtualizada |
| Coste de un commit | Local y barato; lo que crece con el repo es sincronizar (clone, fetch, checkout) | Se crea en el servidor; el coste escala con el cambio, no con el repo |
| Para quién sirve | Prácticamente cualquier equipo y proyecto | Monorepos enormes con decenas de miles de ingenieros o enjambres de agentes |
| Limitación o riesgo | A escala de agentes masiva exige mirrors, cachés y mantenimiento de packfiles | Sin conexión no trabajas; no es open source; adoptarlo obliga a migrar review, code search y CI |
Según Anthropic, el resultado: una huella de infraestructura unas 200 veces menor que la de los mirrors de git, checkouts de CI en segundos en vez de minutos y un 25% de la CPU de CI liberada.
La merge queue clásica no aguanta el volumen de los agentes
Según Anthropic, una merge queue clásica no aguanta 30.000 merges al día: prescindieron de ella y movieron la validación a testing post-merge y pre-deploy. Esta es la parte que sí te afecta.
Anthropic lo escribe sin rodeos: "A proper merge queue, for example, doesn't make much sense at agent scale." (Una merge queue como tal, por ejemplo, no tiene mucho sentido a escala de agentes.)
Una merge queue serializa los cambios: prueba cada uno contra el estado más reciente de main antes de integrarlo. Con 30.000 merges al día, esa cola es un embudo. Su respuesta fue prescindir del lock global, que no lograron replicar a esa escala, invertir en testing post-merge y pre-deploy, y dejar que Claude arregle los conflictos.
Esa decisión solo es segura si tus tests son buenos de verdad. Un test que pasa siempre no protege nada. Por eso, antes de mover validación a post-merge, merece la pena medir la calidad real de tu suite, por ejemplo con mutation testing con Stryker, y proteger los tests para que el agente no los modifique cuando le estorban.
Revisar la intención, no cada línea
Revisar la intención es comprobar que el cambio hace lo que debía hacer, en vez de leer cada línea que escribió el agente. Es el segundo cambio, y el más incómodo.
Anthropic cuenta que sus ingenieros tuvieron que decirle "no" a Claude a menudo durante el proyecto. Claude proponía escaneos lineales del log de commits en lugar de consultar la herramienta de review, o añadía validación sobre-defensiva después de una revisión adversarial. La conclusión del equipo: ahora revisan la intención del cambio, no cada línea.
No es revisar menos. Es revisar otra cosa: tener escrito qué debe hacer el cambio y comprobar que lo hace.
Es exactamente la idea detrás de la revisión por contrato del código generado por agentes: defines el contrato antes, y revisas contra él. Y empieza por darle al agente contexto estable sobre tu proyecto, con un buen AGENTS.md para Claude Code.
Si quieres empezar gratis, el ebook El Developer Agéntico es el punto de partida para construir agentes de IA con criterio: herramientas, memoria, seguridad, permisos y evaluación.
Si quieres llevarlo a un flujo completo, es lo que trabajamos en el workshop SDD + Agentic Engineering: especificación, harness y revisión de lo que produce el agente.
Lo que dice Hacker News: ¿es git o es el monorepo?
El hilo de Hacker News superó los 940 comentarios. La respuesta corta a la pregunta del título: técnicamente, buena parte del problema es el monorepo; lo que forzó el cambio fue el volumen. El escepticismo fue bastante sano.
La crítica técnica más repetida: el problema no es git, es el monorepo. zmmmmm lo planteó directamente, y bob1029 fue más lejos: "This article doesn't do a very good job of convincing me that git is technically incapable of handling the described workload." (Este artículo no consigue convencerme de que git sea técnicamente incapaz de manejar esa carga.)
tancop lo resumió en una línea: "So it's a SVN/Perforce style server based VCS with a more modern design." (O sea, un VCS basado en servidor al estilo SVN/Perforce con un diseño más moderno.)
kburman apuntó al coste oculto: "I suspect we'll see a lot more reinvention of the wheel, even at smaller startups, as AI makes writing code significantly cheaper. […] Whether maintaining all that custom software turns out to be equally cheap is another question." (Sospecho que veremos mucha más reinvención de la rueda, incluso en startups pequeñas, porque la IA abarata escribir código. Si mantener todo ese software a medida resulta igual de barato es otra cuestión.)
Y duttish hizo la pregunta que más me importa: "Every time I stop reviewing the code from Claude I later find janky crap. […] how are they avoiding the janky crap?" (Cada vez que dejo de revisar el código de Claude, después encuentro chapuzas. ¿Cómo las evitan ellos?)
Mi opinión: la crítica de que "es el monorepo" tiene razón técnica, pero no cambia la lección. Lo que forzó el rediseño fue el volumen de cambios. Y la pregunta de duttish tiene respuesta: no dejas de revisar, cambias qué revisas. Revisar la intención sin un contrato escrito suele acabar en chapuzas.
Cuándo NO te sirve el enfoque de Anthropic Scion
La propia Anthropic lo dice claro: "Scion is by no means a suitable replacement for git for general use." (Scion no es, en absoluto, un reemplazo adecuado de git para uso general.)
Estas son las limitaciones que reconoce:
- Solo tiene sentido a una escala que casi nadie tiene. Monorepos enormes, con decenas de miles de ingenieros o enjambres de agentes. Si tu repo cabe en un portátil, git te sobra.
- Su presupuesto de tokens no es el tuyo. Anthropic reconoce que lo que gasta en tokens para uso interno supera con mucho lo que cualquier otra empresa querría gastar de forma realista. Parte de su manera de trabajar se apoya en ese gasto, y tú no partes de ahí.
- Adoptarlo es migrar todo el ciclo. No cambias solo el VCS: cambias review, code search y CI. Anthropic construyó Antique y el resto del ecosistema a la vez.
- No es open source. No puedes instalarlo. Anthropic dice que quiere compartir las ideas con GitHub, GitLab y la comunidad git, no el producto.
Qué hacer con tu flujo de trabajo esta semana
No necesitas Anthropic Scion. Necesitas que tu flujo aguante el volumen de cambios que tus agentes ya pueden generar.
Haz esta prueba:
- Cuenta cuántos PRs abrieron tus agentes este mes y el anterior.
- Mide cuánto tardó cada uno en llegar a
main. - Si el tiempo de espera crece más rápido que el número de PRs, tu cuello de botella ya no es escribir código: es integrar y revisar.
- Empieza por escribir la intención antes de pedir el cambio y revisa contra ella. Si quieres el método completo para trabajar con especificaciones, está en el libro Spec-Driven Development. Y si quieres verlo aplicado de la idea al producto con Claude Code, en el curso Construye con IA.
Preguntas frecuentes
¿Anthropic ha abandonado git?
Solo en su monorepo interno. Anthropic lo sustituyó por Scion en ese monorepo porque los merges pasaron de unos 2.500 diarios en mayo de 2026 a más de 30.000 en septiembre. La propia empresa dice que Scion no es un reemplazo de git para uso general.
¿Anthropic Scion es open source?
No. Anthropic no lo libera como open source. Su intención declarada es compartir las ideas de diseño con GitHub, GitLab y la comunidad de git.
¿Debería dejar de usar git?
No. Scion está pensado para monorepos enormes con decenas de miles de ingenieros o enjambres de agentes, y exige migrar review, code search y CI. Para casi cualquier equipo, git sigue siendo la opción correcta; lo que sí conviene revisar es tu proceso de integración y revisión.
¿Qué es Antique?
Antique es la herramienta de code review que Anthropic construyó junto a Scion. Forma parte del mismo ecosistema que también incluye code search e IAM de source control.
¿Qué es Claude Mythos Preview en esta historia?
Un snapshot interno temprano de Claude Mythos Preview reescribió el pipeline de ingesta de git a Scion sin más instrucciones, según Anthropic. El resultado usaba 20 veces menos memoria y era 4 veces más rápido, preservando las invariantes implícitas de orden de ingesta y de estructuras de datos.
¿Por qué Anthropic no usa una merge queue clásica?
Porque, según Anthropic, una merge queue como tal no tiene mucho sentido a escala de agentes, y no lograron replicar el lock global del repositorio que es estándar en la industria. En su lugar invierten en testing automático post-merge y pre-deploy, y Claude arregla los conflictos entre cambios concurrentes.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
¿Quieres construir con agentes en serio?
Curso «Construye con IA» con Claude Code, de la idea al producto.
Developer con más de 15 años en frontend y creador de Dominicode. Escribe sobre IA aplicada al desarrollo de software.
¿Te resultó útil este artículo?
Compártelo con tu comunidad y ayuda a otros desarrolladores.