Anthropic deja git por Scion: con 30.000 merges al día, el atasco es tragarse el código

Anthropic ha hecho algo que en casi cualquier empresa te gana una mirada rara en la reunión de los lunes: sacar su monorepo de git. En mayo de 2026 fusionaba de media unos 2.500 cambios al día. En septiembre, más de 30.000.

La cifra se multiplicó por doce entre mayo y septiembre. Repartida en las 24 horas, sale a un cambio cada menos de tres segundos de media.

Y ahí la historia rima, aunque sea de oído. Tres segundos fue el listón que se marcó Linus Torvalds en abril de 2005, cuando empezó a escribir git: aplicar un parche no podía tardar más. Una cosa es lo que tarda un parche y otra cada cuánto entra un merge. La rima, aun así, retrata el cambio de época. Git se diseñó para las ráfagas de unos mantenedores humanos y se ha encontrado una manguera abierta día y noche.

La versión oficial es un problema de escala, y lo es. Pero el fondo tiene más miga. El repo de Anthropic lo usan sobre todo agentes y jobs, que están conectados por definición. Para ellos, la gran virtud de git se ha vuelto un lastre. Esa virtud era tener la copia entera y poder trabajar sin red. La solución de vanguardia se parece sospechosamente al pasado: un servidor central que lo sabe todo. La lección para el resto no es cambiar de git. Es asumir que, con agentes, el atasco se muda de escribir código a tragárselo.

Un caracol con 100 GB de concha

Git es un caracol. Cada clon lleva la casa entera a cuestas, con todo su historial, para poder dormir donde le pille. Saca diffs, lee el historial y el blame, y hace checkout de cualquier versión sin conexión. La propia Anthropic admite que, para la inmensa mayoría de los repos, ese es el diseño correcto y buena parte de por qué git se convirtió en el estándar. Torvalds lo quería distribuido, al estilo de BitKeeper. Usó CVS como manual de lo que no había que hacer: ante la duda, justo lo contrario.

El problema es lo que pesa la concha. El historial de la rama main de Anthropic roza los 100 GB, y una copia de trabajo comprimida pasa de 25 GB. Es ir a Hacienda a preguntar una duda y presentarte con todas las facturas desde que empezaste a cotizar. El mostrador está abierto. Tú, por si acaso, te has traído el trastero.

Y no la carga un caracol: la cargan millones. Solo la CI hace del orden de 25 millones de checkouts al día, sin contar entornos de desarrollo, sandboxes de agentes ni trabajos de investigación. Bajados a pelo, serían más de 600 PB de tráfico git diario.

Anthropic tiró de todos los apaños de manual: clones superficiales, sparse checkouts, promisor remotes, mirrors internos y snapshots del repo guardados en blob storage. En el pico llegó a mantener varios cientos de mirrors de git. Le compraron tiempo, pero cada vez costaba más sostenerlos. Los snapshots se quedaban atrás respecto a la punta de main. Que el diff y el blame siguieran funcionando sobre clones parciales pedía cada vez más mimo. Hasta que el control de versiones se convirtió en su mayor cuello de botella de desarrollo. Hostia en la mesa: el atasco ya no era escribir. Era cargar con la casa.

Un hotel con servicio de habitaciones

La pregunta que se hicieron fue sencilla. Si diseñas el control de versiones sabiendo desde el principio que los agentes siempre están conectados, ¿cómo queda?. Queda como un hotel con servicio de habitaciones. En el cuarto tienes un minibar, no una cocina, y lo demás te lo sube recepción.

En Scion, el servidor contesta quién tocó cada línea y la historia de cada fichero, crea los commits y hace los merges y los rebases. El cliente guarda una caché local con tope, coloca los ficheros en disco y vigila los cambios. Por su cuenta calcula muy poco. A cambio, necesita muchos menos datos en local.

El orden de la obra es lo más copiable del caso. Al principio de la migración, antes de tener cliente, formato o protocolo propios, Scion solo contestaba preguntas de metadatos, como el blame o el parentesco entre commits. Primero le quitaron a la CI la necesidad de clonar el repo entero para preguntar algo. Es el vecino que llama al portero para saber si el ascensor funciona, en vez de fotocopiarse los estatutos de la comunidad. Hoy, un job que necesita el diff entre un commit y su merge base se lo pide al servidor, y muchas escrituras van enteras por API, sin checkout.

Cuando sí hacen falta ficheros en disco, el protocolo gira en torno a checkouts parciales y virtualizados, que materializan cada fichero cuando alguien lo lee. El cliente solo paga lo que usa. Por debajo, la unidad de trabajo es el changeset, una entrada en un write-ahead log. Guarda la lista de ficheros cambiados respecto a su primer padre y punteros a su contenido comprimido. Se crean en el servidor, sin packfiles que aceptar, sin bloqueos y sin refs que mover, y por eso entran a un ritmo altísimo. Es la comanda del bar: no subes el barril a la mesa. Apuntas qué ha cambiado y te traen el vaso.

El reparto va por pisos. Cada máquina tiene un daemon que comparte objetos entre todos sus jobs. Por encima hay cachés regionales que sirven desde memoria y, arriba del todo, servidores autoritativos que leen de Spanner o de cloud storage. Cada piso acierta más del 99% de las veces, así que casi nunca hay que bajar al almacén. El camarero ya se sabe el pedido. La nevera de detrás de la barra cubre el resto. El polígono, para las grandes ocasiones.

La cuenta la firma el que vende la manguera

Los resultados, medidos por Anthropic: la infraestructura de Scion pide 200 veces menos CPU y memoria que los mirrors de git a los que sustituye. Los checkouts de CI e investigación han pasado de minutos a segundos, y solo la CI ha recuperado un 25% de capacidad de CPU. La ingeniería tiene mérito, y el post la explica con un detalle que ya quisieran muchos papers.

Luego viene el escaparate. Anthropic empezó a construir Scion cuando Claude Mythos Preview y Claude Tag llegaron a uso interno. Y cuenta que esos lanzamientos dispararon a la vez la necesidad del sistema y la velocidad para construirlo. El ejemplo estrella es el pipeline de ingesta de git a Scion. Lo habían escrito casi a mano como prototipo y se lo dieron a una versión interna temprana de Mythos Preview. Sin más instrucciones, volvió con 20 veces menos memoria y cuatro veces más rápido, respetando los invariantes implícitos de la ingesta.

La plantilla también va al escaparate. Siete personas construyeron Scion, Antique (su herramienta de revisión de código) y varios sistemas más, y migraron a todo ello en cinco meses. Todos los ingenieros que trabajaron en el sistema dicen hoy que Claude programa mejor que ellos.

Claude es el pirómano y el bombero de esta historia: la misma máquina que inunda el repo levanta el dique. Que lo cuente quien vende la máquina no lo convierte en mentira, pero sí en anuncio, y todas estas cifras son de Anthropic, sin medición independiente que las respalde. Simon Willison hizo lo que haría cualquiera ante el gráfico de un fabricante: le pidió a Claude que le añadiera los lanzamientos públicos de cada modelo de Anthropic en 2026. Su apuesta es que la llegada de los modelos tipo Fable/Mythos es un factor clave del salto, aunque avisa de que son fechas públicas, no las de uso interno.

Volver con el ex (y pagarle el gimnasio)

Willison lo resume sin anestesia: Scion le suena a reinventar el control de versiones centralizado, en la línea de Subversion. Subversion es justo eso, un sistema centralizado, y git le pasó por encima. En 2022, casi el 95% de los desarrolladores tenía git como sistema principal. Ahora una de las empresas que fabrican los agentes vuelve con el ex. Eso sí, pagándole el gimnasio: cachés por pisos, API para todo y Spanner debajo.

Anthropic no esconde a quién le ha mirado los apuntes: cita como precedentes el Piper de Google y el Sapling de Meta. Los grandes que se dieron antes contra este muro tiraron hacia el centro o hacia la virtualización:

Quién	De dónde venía	Qué hizo	Escala
Google	Más de 10 años con una sola instancia de Perforce	Piper, centralizado sobre Bigtable y luego Spanner, con CitC: backend en la nube y un sistema de ficheros FUSE en local	Datos de 2016: 25.000 desarrolladores, 16.000 cambios al día y otros 24.000 commits de bots
Meta	Mercurial, del que Sapling nació como extensión	Sapling: cliente open source desde noviembre de 2022, con el servidor Mononoke y EdenFS, un sistema de ficheros virtual que rellena los ficheros bajo demanda	,
Microsoft	Source Depot, repartido en más de 40 depots	Pasó Windows a git y lo virtualizó con GVFS, que solo descarga lo que se usa	En 2017: unos 3,5 millones de ficheros y un repo de unos 300 GB
Anthropic	git	Scion: clientes siempre conectados y servidores que leen de Spanner o cloud storage	Septiembre de 2026: más de 30.000 cambios fusionados al día, con un historial de main de casi 100 GB

Dos detalles de la tabla rematan el giro. Scion lee de Spanner, la base de datos de Google sobre la que acabó corriendo Piper: Anthropic se ha montado un Piper para agentes con una pieza del Piper original. Y Microsoft metió en git un repo de Windows de unos 300 GB a base de virtualizarlo. Anthropic, en cambio, se va de git con un historial de main que ronda los 100 GB. No son la misma medida, pero basta para ver que el peso de la concha no lo explica todo. Lo que la vuelve insoportable es cuánta gente la carga y cuántas veces al día.

¿Y el modo offline, la joya de la corona? En Hacker News se lo preguntaron a Nick G, ingeniero de Scion. Su respuesta: como Claude es con diferencia quien más usa Scion y está necesariamente conectado, no era importante. El caracol lleva la concha porque nunca sabe dónde va a dormir. Los agentes de Anthropic duermen siempre en el mismo sitio.

Lo más gracioso es que la mayoría de empresas ya vivía así. Anthropic reconoce que, como casi todas, usaba git como un sistema centralizado con una única copia que manda. Es lo habitual: colgar el repo de un servidor central que guarda la copia integrada. Distribuido en el papel, centralizado en la práctica. Anthropic solo ha dejado de pagar el peaje de disimular.

El oficio de decirle que no a Claude

Ahora, lo que no sale en la foto. Para el equipo de Scion, 30.000 merges al día es la métrica correcta, porque es la carga que tiene que aguantar. El problema es leerla como productividad. Eso es juzgar un restaurante por los platos que salen del lavavajillas: te dice cuánto se mueve la cocina, no si se come bien. Anthropic añade que la demanda latente de fusionar código es "prácticamente infinita" y que cada atasco que quitan dispara todavía más código. Puede ser verdad. También es exactamente lo que diría quien vende la manguera.

La propia Anthropic deja las pistas. The Register recoge del post que muy a menudo el papel de los ingenieros era decirle a Claude que no. Y la razón: los agentes a veces se saltan restricciones básicas del sistema para encajar un patrón que nunca debió permitirse. A veces, directamente, la están cagando con mucha convicción. Willison rescata otra línea: la revisión adversarial funciona muy bien, pero puede ser miope. Hacían falta ingenieros con oficio para apartar a Claude de la sobreingeniería ante problemas hipotéticos.

Crypto Briefing recoge que siguen revisando cada cambio de Scion, aunque ahora miran la intención más que cada línea. En el hilo de Hacker News, un usuario explica en crudo por qué eso da miedo: cada vez que deja de revisar el código de Claude, acaba encontrando chapuzas. Es un testimonio, no un dato, pero señala justo el sitio donde mirar la intención puede salir caro.

El búfalo se lo ha encontrado montando software con agentes. Sometió a una revisión ciega y adversarial unos cambios estructurales que habían hecho agentes en un sistema en producción. Al reproducir las pegas del revisor salieron pruebas que pasaban sin comprobar nada, porque se fabricaban ellas mismas la situación que presumían verificar. Por eso su norma va en la línea de Anthropic. El agente puede sugerir piezas o capas nuevas, pero no meterlas por su cuenta. Antes de añadir nada, tiene que explicar por qué no le vale con retocar o enchufar lo que ya hay.

El ritmo también se ha cargado la cola de merge de toda la vida. Con cientos o miles de cambios fusionándose mientras corren los tests, Anthropic ha pasado a probar después del merge y antes del deploy. Es la churrería con cola hasta la esquina: ya no da tiempo a catar cada churro, así que se cata la bandeja antes de sacarla al mostrador.

Y las condiciones no vienen en la caja. The Register lo despacha con sorna: cuando el dinero sobra gracias al capital riesgo, ese gasto en tokens tiene todo el sentido. Anthropic dice, además, que su sistema no sirve para uso general y que no habrá versión open source.

Tu repo no es el de Anthropic (todavía)

Así que no, no cambies de git. Scion no se publica, Anthropic no lo vende como sustituto general y prefiere compartir el enfoque con GitHub, GitLab y la comunidad open source. Montarte tu propio Scion con un repo normal es comprarte una grúa para colgar un cuadro.

Pero el marrón no es solo suyo. GitHub arrancó en octubre de 2025 un plan para multiplicar por 10 su capacidad. En febrero de 2026 concluyó que tenía que diseñar para 30 veces la escala de entonces. El motivo principal, en palabras de GitHub: desde la segunda quincena de diciembre de 2025, los flujos de desarrollo con agentes se han acelerado bruscamente. En open source ya lo vimos con Godot y las contribuciones de agentes.

Lo que sí puedes copiar mañana:

• Cuenta los clones. Antes de tocar tu control de versiones, mira cuántas veces clonas el repo entero para contestar una pregunta que tu forja quizá ya responde por API. La primera versión de Scion solo contestaba preguntas.
• Trata a los agentes como lo que son. Clientes que nunca se desconectan: que cada job pida lo que necesita en vez de cargar con la concha entera.
• Sella el examen antes de que escriban. El cuello de botella humano no se arregla leyendo más deprisa. El búfalo solo da una fase por buena con pruebas de aceptación que se ejecutan, pactadas antes de arrancar y congeladas para que el agente no las retoque. Y el visto bueno nunca lo pone el mismo agente que ha escrito el código.

Crypto Briefing recoge que Anthropic espera presiones parecidas en otras organizaciones en los próximos 6 a 12 meses. Es la previsión de quien vende los agentes, aunque GitHub ya ha hecho números para 30 veces su escala. La pregunta que te deja el caso cabe en una servilleta: ¿cuántos cambios por hora se traga tu CI antes de atragantarse?