Saltar al contenido

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.

Por Tech AI Wire Team

4 min de lectura

XLinkedIn
El artículo de ingeniería de Anthropic «Redesigning source control at Anthropic», publicado el 13 de octubre de 2026, que describe su paso a un sistema de control de versiones propio.

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:

MedidaCifra
Historial de la rama principalCasi 100 GB
Copia de trabajo comprimidaMás de 25 GB
Checkouts al día solo para CIUnos 25 millones
Tráfico de git si cada checkout fuera un clon normalMás de 600 PB al día
Réplicas internas de git en el momento de máxima cargaVarios 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

  1. Redesigning source control at Anthropic - Anthropic
  2. Anthropic reinvents source control as Claude floods the world with code - The Register

Artículos relacionados