Anthropic cambia git por Scion al superar las 30.000 fusiones diarias
Anthropic ha pasado su monorrepo de git a Scion, un sistema de control de versiones propio, después de que sus fusiones diarias subieran de unas 2.500 en mayo de 2026 a más de 30.000.
4 min de lectura

En cifras
- code changes merged per day in September, up from about 2,500 in May
- 30,000+
- size of the main branch's history
- ~100 GB
- less CPU and memory than the old git mirrors, per Anthropic
- ~200x
- to migrate, with a team of seven
- 5 months
Anthropic ha trasladado su principal repositorio de código de git a Scion, un sistema de control de versiones que ha creado ella misma. La empresa dice que fusionaba unos 2.500 cambios de código al día en mayo de 2026 y más de 30.000 al día en septiembre. The Register relaciona ese salto con que Claude escribe una parte mayor del código de la empresa. Git se basa en la idea de que cada copia guarda el historial completo. Eso dejó de tener sentido cuando casi todos los usuarios eran agentes de IA siempre conectados. Anthropic describió el sistema el 13 de octubre, pero no lo va a publicar.
Por qué git dejó de funcionar
«El cuello de botella, ahora, es toda la infraestructura para desarrolladores construida a escala humana», escribe Anthropic en su artículo de ingeniería. Escribir código ya no es la parte lenta. Lo son el control de código fuente, las compilaciones y la integración continua (CI), las pruebas automáticas que se ejecutan con cada cambio.
El repositorio es un monorrepo, un único repositorio que guarda la mayor parte del código de la empresa. Su tamaño explica la presión:
| Medida | Cifra |
|---|---|
| Historial de la rama principal | Casi 100 GB |
| Copia de trabajo comprimida | Más de 25 GB |
| Checkouts al día solo para CI | Unos 25 millones |
| Tráfico de git si cada checkout fuera un clon normal | Más de 600 PB al día |
| Réplicas internas de git en el momento de máxima carga | Varios cientos |
Anthropic probó las soluciones habituales. Usó clones superficiales y parciales (shallow y sparse), que descargan solo una parte de un repositorio, además de réplicas internas y copias preconstruidas. Cada una se volvió más difícil de mantener a medida que aumentaban las fusiones. Las copias preconstruidas se desviaban de la rama principal, y herramientas como diff y blame fallaban con los clones parciales.
Cómo funciona Scion
Scion da por hecho que sus clientes están siempre conectados. El servidor se encarga del historial, blame, los commits, las fusiones y los rebases. Cada máquina guarda solo una caché local limitada y su copia de trabajo, es decir, los archivos que de verdad está editando.
Cada cambio se guarda como un changeset en un registro de escritura anticipada (write-ahead log), un registro continuo de cambios. Enumera los archivos que cambiaron y apunta a su contenido en un almacenamiento de blobs. Los archivos se obtienen bajo demanda, así que un checkout nunca descarga primero un paquete de varios gigabytes.
Scion funciona en tres niveles: un daemon en cada máquina, una caché en cada región y un servidor de referencia. Anthropic dice que cada nivel de caché responde a más del 99 % de las peticiones. Se desaconsejan las ramas que no sean main ni ramas de lanzamiento.
Scion no es un sustituto directo de git. Nick G., ingeniero de Scion, explicó esa renuncia en Hacker News, según cita Simon Willison. «Como Claude es, con diferencia, el usuario más intensivo de Scion y está necesariamente conectado, simplemente no era importante hacerlo», escribió. Willison compara el resultado con sistemas centralizados más antiguos como Subversion.
Lo que Anthropic dice haber ganado
Anthropic informa de estos resultados en los repositorios que funcionan de forma nativa en Scion:
- Unas 200 veces menos CPU y memoria que sus antiguas réplicas de git.
- Checkouts de CI y de investigación unas 100 veces más rápidos, que tardan segundos en lugar de minutos.
- Un recorte del 25 % en la CPU que usa su sistema de CI.
Siete personas construyeron Scion, una herramienta de revisión de código llamada Antique y alrededor de media docena de sistemas relacionados. La migración llevó cinco meses. The Register informa de que el trabajo en Scion empezó en enero de 2026.
Las otras herramientas incluyen búsqueda de código, permisos de acceso por directorio y una forma de integrar cambios sin una única cola de fusión global. El equipo las construyó con ayuda de Claude. Una reescritura hecha por Claude de la primera canalización de importación de git a Scion usó 20 veces menos memoria y fue cuatro veces más rápida, según Anthropic.
Las personas siguieron dirigiendo el trabajo. «Muy a menudo, descubrimos que el papel de los ingenieros era decirle “no” a Claude», dijo Anthropic, según cita The Register.
¿Tendrá alguien más acceso a Scion?
No. Anthropic dice que es difícil ofrecer Scion de una forma útil para muchos y que no es adecuado para un uso general. En su lugar, comparte el diseño y dice que quiere trabajar con GitHub, GitLab y la comunidad de código abierto.
El artículo propone ideas que los servicios de alojamiento de git podrían adoptar sin cambiar cómo funciona git. Entre ellas, hacer más trabajo en el servidor y facilitar la combinación de clones parciales y superficiales. Git también está cambiando: este mes ya cubrimos el debate sobre el SHA-256 por defecto de Git 3.0.
Qué significa esto para los desarrolladores
- Git sigue siendo válido para la mayoría de los equipos. The Register señala que git sigue siendo la opción adecuada para la mayoría de los repositorios. Scion resuelve un problema que aparece con decenas de miles de fusiones al día.
- Vigile el coste de los checkouts de CI a medida que crecen los agentes. Unos 25 millones de checkouts al día es lo que rompió git aquí. Si sus agentes clonan el repositorio para cada tarea, mida ese tráfico ahora.
- Trate a los agentes como clientes siempre conectados. Las copias sin conexión importan a las personas, no a los agentes que se ejecutan en la nube. Las herramientas que obtienen archivos bajo demanda pueden reducir el coste de cada ejecución de un agente.
- Cuente con que los servicios de git adopten estas ideas. Anthropic quiere que GitHub y GitLab adopten partes del diseño. Las operaciones en el servidor y unos clones parciales mejores son los primeros pasos probables.
- Mantenga a personas en la revisión. Los ingenieros de Anthropic dedicaron gran parte de su tiempo a rechazar las sugerencias de Claude. Prevea esa carga de revisión cuando los agentes escriban la mayor parte del código.
Fuentes
Artículos relacionados

Las stacked pull requests de GitHub ya están disponibles para todos
GitHub puso las stacked pull requests a disposición de todos el 6 de octubre de 2026, en todos los planes de github.com, con colas de fusión compatibles con pilas y la CLI gh stack.

Claude Code 2.1.287 añade Claude Mods para plugins con más alcance
Claude Code 2.1.287, publicado el 1 de octubre, deja que los plugins cambien el comportamiento profundo del agente mediante Claude Mods y añade un agente auxiliar opcional que señala errores.

Claude Code solo lee AGENTS.md con la telemetría activada
El soporte de AGENTS.md en Claude Code 2.1.277 depende de un feature flag remoto y deja de funcionar en silencio sin telemetría, según una issue de GitHub.