Respuesta rápida: Anthropic Scion es el sistema de control de versiones interno que Anthropic desarrolló después de que los agentes de programación dispararan la actividad de su monorrepositorio de unos 2500 merges al día en mayo de 2026 a más de 30 000 diarios en septiembre. Scion ejecuta los commits, merges y rebases en el servidor. Es de uso interno y Anthropic afirma que no está pensado como un reemplazo general para Git.
Qué hizo Anthropic con Scion y por qué
El 13 de octubre de 2026, el equipo de ingeniería de Anthropic publicó Redesigning source control at Anthropic. La afirmación inicial no se anda con rodeos: «programar ya no es el cuello de botella para crear sistemas o investigar». El verdadero cuello de botella, explican, reside en «toda la infraestructura para desarrolladores diseñada a escala humana: control de versiones, compilaciones y CI».
Las cifras lo explican con claridad. En mayo de 2026, la empresa integraba unos 2500 cambios de código al día. Para septiembre, la cifra superaba los 30 000. Se trata de un incremento de doce veces en solo cuatro meses, que Anthropic atribuye a que son los agentes quienes ahora escriben el código.
Git funcionaba bien a escala humana, pero colapsó a escala de agentes. Anthropic reporta alrededor de 25 millones de checkouts de CI al día, un historial de la rama principal cercano a los 100 GB y varios cientos de réplicas (mirrors) internas de Git en momentos de máxima demanda. Una estrategia de fetch convencional habría supuesto más de 600 PB de tráfico de Git al día.
Por ello, un equipo de siete personas construyó Scion, una herramienta de revisión de código llamada Antique, un buscador de código y un sistema de control de acceso por directorio. Migraron el monorrepositorio fuera de Git en cinco meses. Anthropic incluso recurrió a Claude Mythos Preview para reescribir el pipeline de ingesta de Git a Scion; la nueva versión consumió 20 veces menos memoria y se ejecutó 4 veces más rápido.
Si utilizas Claude Code, Codex u otro agente de programación en tu equipo, este artículo es un anticipo del próximo cuello de botella al que te enfrentarás. Sharkly se diseñó precisamente para resolver ese problema: centraliza el trabajo, los resultados y las revisiones de los agentes en tareas compartidas en lugar de dejarlos dispersos en terminales individuales.
En qué se diferencia Scion de Git
Git asume que cada clon es una copia completa y autosuficiente de todo el historial que puede funcionar sin conexión. Scion parte del principio opuesto: los clientes siempre están conectados y realizan muy poco cómputo por su cuenta.
| Git | Anthropic Scion | |
|---|---|---|
| Where commits, merges and rebases run | De forma local, en tu portátil | En el servidor |
| Local data | Historial completo | Caché de objetos acotada, checkout disperso (sparse) o virtualizado |
| Unit of work | Commit que apunta a un árbol (tree) | Changeset en un log de escritura previa (WAL), listando los archivos modificados |
| Branches and refs | Económicas y promovidas | Desaconsejadas, salvo main y ramas de release |
| Fetch | Packfiles | Por objeto (árboles, luego blobs), sin mantenimiento del repositorio |
| Offline work | Sí | No |
| Main clients | Personas | Agentes, CI y tareas de investigación |
La arquitectura consta de tres niveles: scion-daemon en cada nodo, scion-cache por región y un scion-server autoritativo. La CLI para el cliente es scn. Las tasas de acierto de caché superan el 99 % en cada nivel.
El beneficio es enorme. El consumo de CPU y memoria es 200 veces menor en comparación con el antiguo esquema de réplicas de Git. Los checkouts para CI e investigación toman segundos en lugar de minutos, y la infraestructura de CI recuperó un 25 % de capacidad de CPU.
A qué renuncias con los commits en el servidor
Llevar los commits al servidor implica renunciar a la característica que hizo triunfar a Git: contar con un historial local completo con el que poder trabajar incluso en un avión. Anthropic lo reconoce abiertamente. Scion «no es de ninguna manera un reemplazo adecuado de git para uso general», y distribuirlo de forma que otras organizaciones puedan usarlo resultaría complejo. No es un producto público y el artículo no lo describe como código abierto.
El modelo de concurrencia también se aparta de lo habitual. Anthropic no serializa cada merge mediante un bloqueo global. Los cambios concurrentes pueden entrar en conflicto, y el equipo detecta esas colisiones mediante pruebas posteriores al merge (post-merge) y previas al despliegue (pre-deploy).
Git para agentes de IA: la lección para equipos que no cuentan con Scion
No vas a tener acceso a Scion, y tampoco lo necesitas. Tu repositorio no pesa 100 GB ni ejecutas 25 millones de checkouts al día. Lo verdaderamente útil del artículo es el patrón del problema, que se manifiesta a cualquier escala.
Cuando los agentes escriben el código, el cuello de botella se desplaza hacia las fases posteriores: primero al merge y luego a la revisión. Tanto la cobertura de DevOps.com como el análisis de TechSpot describen Scion como un intento de la infraestructura por alcanzar el ritmo de producción de los agentes. Un equipo de cinco personas con diez agentes se topará con una versión a menor escala de este mismo obstáculo.
Reconocerás los síntomas:
- Dos agentes editan el mismo archivo durante la misma tarde y tienes que resolver el conflicto a mano.
- Las pull requests se acumulan más rápido de lo que el equipo puede revisarlas.
- Las colas de CI crecen cada semana, mientras que los agentes siguen trabajando a toda velocidad.
- Nadie puede determinar con certeza qué agente modificó qué cosa ni por qué.
- Una rama creada el martes se convierte en un caos inmanejable al hacerle rebase el viernes.
Anthropic atacó los puntos 1 y 3 creando nueva infraestructura. Tú puedes abordar los cinco puntos mejorando tus procesos y aprovechando las herramientas de Git que ya tienes.
Conflictos de merge con agentes de programación: por qué se multiplican
Los conflictos de merge crecen con el solapamiento, no con la cantidad de personas o agentes. Diez agentes que trabajan en un objetivo amplio tocan constantemente los mismos archivos. Diez agentes dedicados a diez tareas bien delimitadas rara vez colisionan. El alcance de cada tarea influye mucho más que el número de agentes.
Las ramas de larga duración empeoran las cosas. Cada hora que una rama permanece abierta, main avanza por debajo. Los agentes agravan esta situación porque abren ramas a un ritmo muy superior al que los humanos tardan en cerrarlas. Nuestro artículo anterior sobre cuántas jornadas de trabajo de agentes puede revisar una jornada humana ilustra esta brecha con cifras concretas.
Qué puedes hacer hoy sin necesidad de Scion
Estos cinco hábitos cubren la mayor parte de lo que necesita un equipo común. Ninguno de ellos exige cambiar de sistema de control de versiones.
Asigna un worktree propio a cada tarea
Un Git worktree es un directorio de trabajo secundario vinculado al mismo repositorio. Contar con un worktree por tarea garantiza que dos agentes nunca escriban en el mismo directorio simultáneamente.
git worktree add ../tasks/COIN-212 -b agent/COIN-212 origin/main
cd ../tasks/COIN-212
# run the agent here, commit, push, open a PR
git worktree remove ../tasks/COIN-212
Explicamos la configuración en Git worktrees para agentes de programación de IA y la limpieza posterior en cómo gestionar worktrees sin las complicaciones de limpieza.
Mantén las tareas pequeñas y acotadas
Define cada tarea especificando los archivos o módulos que puede tocar y la prueba que demuestre que está lista. Una tarea que se resume en un diff fácil de revisar se integra de forma limpia. Una tarea que solo dice «refactorizar autenticación» no lo hace.
Implementa una cola de merge frente a main
Una cola de merge (merge queue) prueba cada pull request contra la versión más reciente de main sumada a todos los cambios en cola por delante de ella, y luego realiza el merge en orden. La cola de merge de GitHub se encarga de esto en ramas protegidas. Es la solución para equipos pequeños equivalente a lo que Anthropic resuelve con pruebas post-merge: dejas de descubrir combinaciones incompatibles después de que ya están integradas.
Vincula la revisión a la tarea aportando evidencias
Un diff por sí solo no explica al revisor qué se le pidió al agente ni qué comprobaciones realizó este. La revisión es mucho más ágil cuando la solicitud, la ejecución, los resultados de las pruebas y el diff se encuentran en un único lugar. Consulta cómo revisar código generado por IA con evidencias a nivel de tarea y por qué la revisión humana se convierte en el cuello de botella.
Haz que los agentes esperen la aprobación humana
Deja que los agentes investiguen, escriban, prueben y generen informes. Deja que las personas fijen el rumbo, autoricen los pasos críticos y acepten el resultado. Un agente que se detiene y espera a una persona antes de hacer merge te cuesta unos minutos; uno que integra código no revisado directamente en main puede costarte todo un día de trabajo. Nuestra guía sobre controles de aprobación para agentes de programación muestra dónde ubicar estos puntos de control.
El papel que desempeña Sharkly
Sharkly no reemplaza a Git ni resuelve conflictos de merge por ti. Tus agentes siguen haciendo commits en tu repositorio a través de tu proveedor de Git habitual. Lo que Sharkly organiza es el flujo de trabajo en torno a esos commits.
Cada tarea encomendada a un agente es una Task con un responsable asignado (Assignee), un estado y un registro de ejecución. Los agentes operan en tus propios equipos (Computers), usando Claude Code, Codex o el entorno de ejecución que ya utilices. En el modo Temporary, cada tarea obtiene un directorio aislado y las ejecuciones vinculadas a un repositorio pueden preparar un worktree independiente, evitando que tareas concurrentes escriban en la misma carpeta compartida.
Cuando un agente termina, puede dejar la tarea en espera de revisión humana. Esa notificación llega al Inbox, donde la persona responsable abre la tarea, examina el resultado en su contexto y decide si la aprueba, la reintenta o la reasigna. La ejecución de la tarea y la conversación posterior quedan registradas en el historial de la tarea, convirtiendo el tablero en tu cola de revisión.
Esta combinación aúna las buenas prácticas de Git descritas anteriormente con un entorno compartido para la solicitud, la ejecución, las evidencias y las decisiones. Si estás evaluando distintas opciones, nuestra comparativa de herramientas para gestionar agentes de programación paralelos repasa todo el panorama actual.
Quiénes deberían tomar medidas ahora
Equipos con tres o más agentes en ejecución diaria: Están cerca de chocar contra el muro de los merges. Añade worktrees y una cola de merge esta misma semana.
Desarrolladores individuales que ejecutan agentes en paralelo: Tu cuello de botella no es el merge, sino la revisión. Reduce el tamaño de las tareas hasta que cada diff requiera menos de diez minutos de lectura.
Responsables de plataforma e infraestructura: Vigila los tiempos de espera en CI y la antigüedad de las PR. El artículo de Anthropic señala que el control de versiones y la CI fallaron antes que cualquier otra cosa; espera que los tuyos fallen en el mismo orden. Implementar agentes paralelos con worktrees aislados te dará un margen de tiempo valioso.
Conclusión
Anthropic Scion es una advertencia de hacia dónde va la industria, no un producto que puedas adoptar. El volumen de merges de Anthropic se multiplicó por doce en cuatro meses, el diseño desconectado por defecto de Git dejó de encajar y un equipo de siete personas reconstruyó el control de versiones pensando en clientes que son, en su mayoría, agentes de software. La mayoría de los equipos nunca necesitará algo así.
Sin embargo, cualquier equipo que use agentes de programación experimentará esta misma transición: escribir código se vuelve muy económico, mientras que integrarlo y revisarlo resulta cada vez más costoso. Aísla cada tarea, mantén un alcance reducido, gestiona tus merges mediante colas y revisa siempre apoyándote en evidencias.
Si quieres centralizar todo el proceso de revisión en un solo lugar, conecta un equipo a Sharkly, crea un agente y asígnale una tarea pequeña y de bajo riesgo. Comprueba cómo se gestiona el resultado y toma tus decisiones a partir de ahí.
Preguntas frecuentes
¿Qué es Anthropic Scion?
Scion es el sistema interno de control de versiones de Anthropic, que sustituyó a Git en el monorrepositorio de la empresa en 2026. El servidor se encarga de ejecutar los commits, merges y rebases, mientras que los clientes solo mantienen una caché local acotada.
¿Por qué Anthropic sustituyó Git?
Los agentes de programación dispararon los merges diarios de unos 2500 en mayo de 2026 a más de 30 000 en septiembre. La replicación en Git, los checkouts y la CI no pudieron sostener semejante volumen, convirtiendo al control de versiones en el cuello de botella principal.
¿Es Scion de código abierto o está disponible para su uso?
No existe ninguna versión pública. Anthropic afirma que Scion no es un reemplazo general adecuado para Git y que resultaría difícil ofrecerlo a otras organizaciones. Compartieron su diseño para que otros puedan aplicar estos mismos principios sobre Git.
¿Cómo reduzco los conflictos de merge entre agentes de programación?
Asigna a cada tarea su propio worktree, mantén las tareas lo bastante delimitadas como para generar un diff fácil de revisar, haz merge con frecuencia e instala una cola de merge delante de main. Los conflictos responden al solapamiento de archivos, por lo que acotar el alcance es mucho más determinante que la cantidad de agentes.
¿Necesitan los equipos pequeños un nuevo sistema de control de versiones?
Casi nunca. El problema de Anthropic se originó por un historial de 100 GB y 25 millones de checkouts diarios. A una escala normal, los worktrees, las colas de merge y las revisiones a nivel de tarea son más que suficientes para gestionar la carga.
