Andy Garcia · dev freelance
FRENES
Volver al blog
IA y desarrollo

Anthropic pasó de 2.500 a 30.000 merges al día y sacó su monorepo de git. Los ingenieros que construyeron el reemplazo revisan la intención, no cada línea

19 de octubre de 2026 8 min de lectura

El martes 13 de octubre de 2026, Anthropic publicó un artículo de ingeniería titulado «Redesigning source control at Anthropic», actualizado el 15 de octubre. Sus primeras cifras son las que todo el mundo repitió: en mayo de 2026 la empresa fusionaba en promedio unos 2.500 cambios de código al día, y desde septiembre fusiona más de 30.000 al día. Para aguantar, construyó Scion, un sistema de control de versiones interno, y migró por completo su monorepo fuera de git en cinco meses. En el mismo periodo lanzó una herramienta de revisión de código llamada Antique, una herramienta de búsqueda de código y un sistema de control de acceso a las fuentes. Según el artículo, un equipo de siete personas construyó Scion y Antique.

La frase que enmarca todo viene antes de cualquier cifra. Escribir código, dice Anthropic, ya no es el cuello de botella: «El cuello de botella, ahora, es toda la infraestructura de desarrollo construida a escala humana: control de código fuente, builds y CI».

Soy CTO de una LegalTech construida sobre Claude y orquesto mi propio trabajo con Claude Code. Mis repositorios son un error de redondeo al lado de este. El sistema de control de versiones es la parte menos transferible del artículo. Lo que sí se transfiere es dónde apareció la presión y qué dejaron de hacer a mano los ingenieros.

Las cifras, y lo que suman

El historial de la rama principal pesa casi 100 GB. Una copia de trabajo comprimida supera los 25 GB. Anthropic hace del orden de 25 millones de checkouts al día solo para la CI, «sin contar los entornos de desarrollo, los sandboxes de agentes y los trabajos de investigación». Obtenidos de forma ingenua, dice el artículo, serían más de 600 PB de tráfico de git al día. La aritmética cuadra: 25 millones por una copia de trabajo de unos 25 GB son unos 625 PB.

Unas divisiones lo hacen legible. Pasar de 2.500 a 30.000 merges al día es un factor de 12 en unos cuatro meses. Repartidos en 24 horas, 30.000 merges son unos 21 por minuto. 25 millones de checkouts al día son unos 290 por segundo. Y si ambas cifras describen las mismas semanas, son más de 800 checkouts de CI por cada cambio que aterriza.

Git tiene herramientas para esto: clones superficiales, checkouts parciales, espejos internos, instantáneas en almacenamiento de objetos. Anthropic las usó todas y, en su punto máximo, operó varios cientos de espejos internos de git. Eso compró tiempo.

Tras la migración, el artículo informa de una huella de Scion 200 veces menor que la del antiguo sistema de espejos de git en CPU y memoria, checkouts para la CI y los trabajos de investigación que tardan segundos en lugar de minutos, una tasa de aciertos de caché superior al 99 % en cada nivel y una ganancia del 25 % de capacidad de CPU para la CI.

Por qué git dejó de encajar

Git es descentralizado: cada clon es un repositorio completo que funciona sin conexión. La observación de Anthropic es que, como la mayoría de las empresas, usaba git como un sistema centralizado con una única copia de referencia, mientras que casi todos sus clientes eran agentes y trabajos, conectados por definición.

Así que Scion asume que el cliente siempre está conectado. El servidor responde a las consultas de historial y de blame y ejecuta commits, merges y rebases. El cliente mantiene una caché acotada y solo obtiene lo que necesita. Las mismas consultas se exponen mediante una API, de modo que muchos trabajos de CI no necesitan ningún repositorio local. Preguntado en Hacker News por el soporte sin conexión, Nick G., uno de los autores del artículo, respondió, según lo recoge Simon Willison: «Como Claude es, con diferencia, el usuario más intensivo de Scion y necesariamente está conectado, simplemente no era importante hacerlo».

Buena parte de esto tiene precedentes, y el artículo citó desde el principio Piper de Google y Sapling de Meta como estado del arte previo. Ese reconocimiento fue cuestionado. El 14 de octubre, Rain, que ayudó a construir Mononoke, el componente de servidor de Sapling, en el equipo de control de código fuente de Meta, escribió que citar a Sapling solo por «lecciones duramente aprendidas», sin nombrar a Mononoke, «roza el plagio», y calificó a Scion de copia en una segunda entrada el 15 de octubre. Ese día Nick G. respondió en Hacker News que Anthropic había citado a Sapling porque así es como la propia Meta nombra todo el sistema, y el artículo ganó una nota al pie que dice que Mononoke «fue pionero de muchas de las técnicas que usamos en Scion», en particular su modelo de datos Bonsai. Rain escribió después que se había añadido una atribución suficiente, manteniendo sus dos entradas tal como estaban cuando se escribieron. Quien cuente la historia de las «siete personas, cinco meses» debería añadir que el modelo de datos en el núcleo del sistema es uno que Anthropic ahora atribuye a Meta.

La línea que subrayé trata de la revisión

Aquí está: «Los miembros de nuestro equipo siguen revisando cada solicitud de cambio del sistema, pero ahora examinan la intención del cambio en lugar de leer cada línea de código».

Fíjate en el alcance. Esa frase describe la base de código de Scion y su equipo, no una política para todo Anthropic. Pero la aritmética a escala de empresa muestra por qué no se quedará en un hábito de un solo equipo. A diez minutos de lectura cuidadosa por cambio, que es generoso para cualquier cosa no trivial, 30.000 cambios al día serían 5.000 horas de revisión, es decir, 625 personas leyendo ocho horas al día sin hacer nada más. Pasado cierto volumen, la revisión línea por línea deja de ser un proceso y se convierte en una cola.

Lo que la rodea se detalla en otra parte del artículo, y no es «confía en el modelo». Scion admite permisos sobre directorios individuales, para proteger el código más sensible. La herramienta de revisión puede expresar restricciones semánticas sobre las aprobaciones, de modo que un cambio que solo toca comentarios se trata distinto de un cambio sensible de lógica y los humanos se concentran en los que importan. El equipo construyó simulaciones herméticas y fuzzing. Usa revisión adversarial, que el artículo califica de eficaz pero «miope»: una revisión desconfiaba tanto de otro servicio interno que Claude añadió validación excesiva y complejidad.

Y esto: «Muy a menudo descubrimos que el papel de los ingenieros era decirle "no" a Claude». El ejemplo es concreto. Varios sistemas intentaban averiguar cuándo se había fusionado un cambio en main leyendo el registro de commits de forma lineal, en lugar de preguntar a la herramienta de revisión de código, que ya lo sabía. Cada ingeniero del proyecto, dice el artículo, valoraría ahora a Claude como mejor que ellos escribiendo código. Lo que seguían aportando era la comprensión a nivel de sistema y las decisiones de diseño.

El mismo artículo trae una anécdota del otro lado. Al pedirle que reescribiera el pipeline de ingesta de git a Scion, una instantánea interna temprana de Claude Mythos Preview produjo, sin más instrucciones, una versión que usaba 20 veces menos memoria y era 4 veces más rápida, preservando los invariantes sobre el orden de ingesta. Escribir el código no era lo difícil. Lo difícil era saber lo que nunca debe hacer. Esa vez el modelo respetó los invariantes; en el caso del registro de commits, los agentes no.

La cola de merge a la que renunciaron

Segunda sorpresa: «Una cola de merge propiamente dicha, por ejemplo, no tiene mucho sentido a escala de agentes». Anthropic no pudo replicar el habitual bloqueo global del repositorio en la cola de merge, así que invirtió en pruebas automáticas posteriores al merge y previas al despliegue. El artículo acepta la consecuencia. Los cambios concurrentes pueden entrar en conflicto, y Claude suele poder resolver esos conflictos más rápido de lo que los humanos pueden identificarlos. En Hacker News, Nick G. precisó que los conflictos textuales nunca se permiten; los que pasan son semánticos, por ejemplo una nueva llamada a una función que aterriza mientras otra persona cambia la lógica de esa función y actualiza a sus llamadores existentes.

Un cambio ahora puede aterrizar antes de que terminen todas las pruebas que lo cubren, y la barrera que importa pasa a ser la previa al despliegue. Es un compromiso razonable a 30.000 merges al día. En un software que guarda los expedientes jurídicos de clientes, querría saber exactamente dónde está esa última barrera antes de tomar prestada la idea.

Lo que Anthropic dice que no se copie

El artículo es inusualmente directo. «Scion no es en absoluto un reemplazo adecuado de git para uso general». Los conceptos solo tienen sentido para «monorepos verdaderamente enormes, con decenas de miles de ingenieros o enjambres de agentes escribiendo código de forma prolífica». Y: «Anthropic es única en que nuestra capacidad de gastar tokens para uso interno supera con creces lo que cualquier otra empresa querría gastar de forma realista».

No es un producto. Lo que Anthropic ofrece en su lugar es una previsión y una lista de deseos. Espera que «esta clase de problemas» se vuelva más común «en los próximos seis a 12 meses», y sugiere que las plataformas de git ofrezcan APIs del lado del servidor como las de Scion, quizá estandarizadas entre proveedores, y que las funciones parciales y superficiales de git se combinen bien. Nombra a GitHub, GitLab y la comunidad de código abierto como los socios que quiere.

Lo que yo comprobaría, a escala normal

Nadie necesita un nuevo sistema de control de versiones. Lo útil es la lista de lo que se tensó: los checkouts y la CI, la revisión, la cola de merge.

Sigue los merges por día y los minutos de CI por cambio fusionado, mes a mes. Si los agentes duplican la primera cifra, la segunda decide la factura.

Mira qué obtiene cada trabajo de CI. Si clona todo el historial para probar la punta, las opciones superficiales y parciales que Anthropic dejó atrás siguen siendo el tamaño adecuado para la mayoría de los equipos.

Escribe qué rutas lee un humano línea por línea. En GitHub, un archivo CODEOWNERS más la opción «Require review from Code Owners» en la protección de ramas hace obligatoria la aprobación de un propietario del código antes de que un cambio en esas rutas pueda fusionarse (para repositorios privados, en un plan de pago). Todo lo demás recibe una revisión de intención: para qué sirve el cambio y qué restricción podría romper.

Pon tu «no» por escrito para el agente. El ejemplo del registro de commits de Anthropic es el patrón: el agente recalcula lo que un sistema de registro ya sabe. Una regla como «pregunta, no recalcules» pertenece a las instrucciones que el agente lee al comienzo de cada sesión, no solo a la cabeza de un revisor.

Si compras software a un proveedor cuyos agentes escriben la mayor parte del código, haz dos preguntas: qué sigue leyendo un humano línea por línea y dónde está la última barrera de pruebas antes de producción.

Anthropic no sacó su monorepo de git porque los agentes escriban mal código. Lo hizo porque escriben mucho, y todo lo que está aguas abajo estaba dimensionado para personas. En un equipo pequeño, lo primero dimensionado para personas es el revisor.

Fuentes

¿Un proyecto del mismo estilo?

Diseño y despliego productos como este. Hablemos.

Hablemos