Anthropic cambió git por Scion. Qué significa para ti

Anthropic reemplazó git por un sistema de control de versiones propio, Scion, después de que el código escrito por agentes llevara su monorepo de 2.500 merges diarios en mayo de 2026 a más de 30.000 en septiembre. Siete ingenieros lo construyeron en cinco meses. La lección para el resto no es "construye tu propio git": es que el código generado por agentes rompe tu pipeline de entrega mucho antes de romper tu producto, y el pipeline es justo donde casi nadie invirtió.

Qué es Scion y qué no es

Scion es un sistema de control de versiones centrado en el servidor, hecho para un único monorepo dentro de Anthropic. Invierte la premisa fundacional de git. Git es offline-first y le entrega una copia completa del historial a cada cliente; Scion asume que los clientes están siempre conectados, porque la mayoría son jobs de CI y agentes de código, no laptops dentro de un avión.

Las decisiones de diseño, según el artículo de ingeniería de Anthropic:

• Historial con autoridad en el servidor. Blame, historial de archivo, merges y commits los responde el servidor, no se reconstruyen desde un clon local.
• API-first. Toda consulta de control de versiones se expone por API, así que las herramientas no mantienen ningún repositorio local.
• Checkout disperso y virtualizado. El cliente baja solo los directorios que pidió; los archivos se materializan bajo demanda.
• Tres capas de caché. Un daemon en el nodo, una caché regional y los servidores autoritativos, cada capa con una tasa de acierto superior al 99%.
• Sin merge queue. Los cambios entran en paralelo y los conflictos se resuelven después.

Lo que Scion no es: algo que puedas usar. Anthropic dice con claridad que "no es, en absoluto, un reemplazo adecuado de git para uso general", y no liberará el código. Su recomendación al ecosistema es más estrecha y mucho más útil: un servidor de git no tiene por qué funcionar como un cliente de git. Las forges pueden ofrecer RPCs del lado del servidor y mejor arquitectura sin pedirle a nadie que abandone git.

Los números que forzaron la reescritura

El clon superficial, el checkout disperso y los snapshots semilla ayudaron, y todos se agotaron. En el pico, Anthropic mantenía varios cientos de mirrors internos de git solo para servir clones. El repositorio no se volvió patológico porque el producto se complicara: se volvió patológico porque la tasa de cambio se multiplicó por doce en cuatro meses.

El cuello de botella real es review, CI y merge

La frase más importante del artículo no es sobre almacenamiento. Es esta: "una merge queue de verdad... no tiene mucho sentido a escala de agente. ¿Qué significa CI cuando cientos o miles de cambios pueden entrar mientras corren las pruebas?"

Esa pregunta no tiene nada que ver con git y todo que ver con tu pipeline. Una merge queue es un lock global. Serializa la integración para que cada commit se pruebe contra el estado exacto en el que va a caer. Es un buen trade cuando haces 20 merges al día. Con 200 se vuelve el camino crítico. Con 2.000 es imposible: el techo de throughput de la cola es el techo de throughput de tu ingeniería, no importa qué tan rápido escriban tus agentes.

La respuesta de Anthropic fue dejar de serializar: los cambios entran en paralelo, las pruebas se mueven a después del merge y los conflictos se reparan automáticamente. En sus palabras, "los cambios concurrentes pueden conflictuar, pero Claude normalmente puede arreglar esos conflictos más rápido de lo que los humanos tardan en identificarlos".

No tienes que estar de acuerdo con ese trade-off. Sí tienes que saber dónde está tu techo, porque los agentes lo van a encontrar.

Qué hacer si no eres Anthropic

Casi con certeza no deberías construir un control de versiones. Deberías hacer el trabajo sin glamour que te compra el mismo margen:

1. Instrumenta throughput, no output. Mide merges por día, tiempo de espera en la cola, tiempo desde CI verde hasta producción y tasa de revert. Líneas de código escritas por un agente es una métrica de vanidad; cambios mergeados que sobreviven es la métrica real.
2. Encuentra tus locks globales. Una merge queue, un único entorno de staging, una aprobación manual de release, una persona que revisa todo. Cada uno es un punto de serialización que limita el throughput sin importar cuánto código se genere antes.
3. Haz el CI selectivo y cacheado. Análisis de impacto de pruebas, caché remota de build y checkout disperso ya son herramientas estándar. El 25% de CPU que Anthropic recuperó vino de dejar de hacer trabajo redundante, no de comprar máquinas.
4. Abarata el costo de equivocarse. Reverts rápidos y aburridos, feature flags y rollouts progresivos valen más que la certeza previa al merge cuando sube el volumen. Si deshacer un cambio malo es barato, puedes permitirte mergear con optimismo.
5. Gasta el review humano en el radio de daño. Fronteras de autenticación, migraciones de datos, rutas de pago, cualquier cosa que toque datos de clientes. Formato, nombres y refactors mecánicos son exactamente lo que deberían asumir los linters y las máquinas.

Ese es el trabajo que hacemos cuando llevamos software construido con IA a producción: encontrar los puntos de serialización, endurecer las rutas que de verdad pueden lastimarte y hacer que el pipeline sobreviva al volumen. Puedes ver cómo lo encaramos en nuestro trabajo.

El rol que no se automatizó

La parte del artículo de Anthropic que merece más atención no tiene nada que ver con control de versiones. Todos los ingenieros del equipo de Scion hoy dirían que Claude escribe mejor código que ellos. Y aun así fueron los humanos quienes aportaron el "entendimiento de los componentes de alto nivel entre sistemas y de los trade-offs de diseño", y su función principal, como dice el propio texto, pasó a ser decirle "no" a Claude cuando se violaba una restricción.

Fíjate también en lo que ese equipo no se salteó. En cinco meses, con siete personas, construyeron simulaciones herméticas de cada interacción no trivial de infraestructura y control de versiones, además de fuzzing y rate limiting sofisticado. La velocidad vino del rigor en las pruebas, no de renunciar a ellas. Es lo contrario de cómo se comportan la mayoría de los proyectos acelerados por IA, y es exactamente por eso que este llegó a buen puerto.

La generación se volvió abundante; lo escaso es el juicio — la misma reasignación que mapeamos en quién lleva a producción cuando prototipar es gratis, ahora visible en la infraestructura. La habilidad escasa es saber qué restricción importa y estar dispuesto a imponerla, y por eso construimos productos construyendo personas en lugar de alquilar horas.

Git es además apenas la primera idea zanjada en llegar a su fecha de caducidad en público. La versión más amplia de ese argumento — qué más seguimos tratando como ley y ya es solo una preferencia — está en las ideas zanjadas tienen fecha de caducidad.

Conclusiones clave

• Anthropic construyó Scion, un reemplazo de git centrado en el servidor, porque el código generado por agentes llevó su monorepo de 2.500 a más de 30.000 merges diarios entre mayo y septiembre de 2026.
• Scion no es open source ni sirve para uso general; la idea portable es que un servidor de git no tiene por qué funcionar como un cliente de git.
• El control de versiones era el síntoma. El problema estructural es que la merge queue, el CI y el review humano son puntos de serialización que limitan el throughput a escala de agente.
• Anthropic espera que equipos de escala mucho menor choquen con estos límites en seis a doce meses.
• El trabajo humano de mayor apalancamiento en el proyecto fue el juicio de diseño y decir "no", no escribir código.

Preguntas frecuentes

¿Qué es Scion?

Scion es el sistema de control de versiones interno de Anthropic, creado para reemplazar git en su monorepo principal. Está centrado en el servidor: el historial, el blame y los merges los sirve una API siempre accesible en lugar de reconstruirse desde un clon local completo, y los checkouts son dispersos y virtualizados.

¿Scion es open source o puedo usarlo?

No. Anthropic afirmó que no liberará el código y que Scion "no es, en absoluto, un reemplazo adecuado de git para uso general". Adoptarlo exigiría migrar todo el ciclo de desarrollo. Su sugerencia es que las forges de git adopten mejoras compatibles del lado del servidor.

¿Por qué git dejó de funcionar en Anthropic?

Volumen, no complejidad. Unos 100 GB de historial en la rama principal, una working copy de más de 25 GB y cerca de 25 millones de checkouts de CI al día. Servir eso sin optimizar habría significado más de 600 petabytes de tráfico diario, y en el pico Anthropic corría varios cientos de mirrors internos de git para sostenerlo.

¿Mi equipo debería reemplazar git?

Casi con certeza no. Por debajo de la escala de Anthropic, las ganancias están en CI selectivo, caché de build, checkout disperso, cambios más pequeños y en eliminar puntos de serialización como una única merge queue global. Reemplazar el control de versiones es el último recurso, no el primer paso.

¿Qué se rompe primero cuando los agentes escriben la mayor parte del código?

La merge queue y la capacidad de CI, seguidas por el ancho de banda del review humano. Los tres son procesos serializados justo después de una etapa de generación que acaba de volverse mucho más rápida.

¿Cuánto tiempo tienen los equipos?

Anthropic espera que estos problemas de escala se vuelvan comunes en seis a doce meses. La preparación barata es la medición: conoce tus merges por día, el tiempo de espera en la cola y la tasa de revert antes de que llegue el volumen.