Anthropic deja git en su monorepo: así es Scion, un control de versiones pensado para agentes

Ayer escribía sobre un estudio de Harvard que muestra cómo los agentes de IA escriben mucho más código, pero la ganancia se pierde en la revisión. Hoy Anthropic ha publicado Redesigning source control at Anthropic, que cuenta la otra cara de la misma historia: qué pasa cuando una empresa empuja los agentes hasta el límite y lo que se rompe ya no es la revisión, sino git.

El artículo empieza con una frase que resume todo lo demás: “En Anthropic, escribir código ya no es el cuello de botella”. Ahora el problema es toda la infraestructura pensada para equipos de personas: el control de versiones, los builds y la integración continua.

Los números

Multiplicar por doce los cambios diarios en cuatro meses es una barbaridad. Y Anthropic dice que no espera que el ritmo baje: cada cuello de botella que quitan hace que se produzca todavía más código.

Por qué git no aguanta

Git es un sistema distribuido: cada clon es un repositorio completo que puede calcular diferencias, leer el historial o hacer blame sin conexión. Para casi todos los repositorios es justo lo que se quiere, y es una de las razones por las que git ganó.

Pero en la práctica casi todas las empresas usan git de forma centralizada, con una copia de referencia en GitHub o GitLab. Y en el caso de Anthropic, casi todos los clientes de ese repositorio no son personas, sino agentes y trabajos de CI que siempre están conectados. Para ellos, que cada clon sea un repositorio completo no aporta nada y cuesta muchísimo.

Antes de construir nada propio, probaron todo lo que se suele hacer con monorepos grandes: clones superficiales (shallow), sparse checkouts, promisor remotes, espejos internos de git y snapshots del repositorio guardados en almacenamiento de objetos. En el peor momento llegaron a tener varios cientos de espejos de git. Les dio tiempo, pero cada vez costaba más mantenerlo.

Así que se hicieron una pregunta muy buena: si diseñaras un control de versiones sabiendo desde el principio que los clientes son agentes siempre conectados, ¿cómo sería?

Los principios de Scion

La respuesta es Scion, un sistema propio que se inspira en Piper, el de Google, y en Sapling, el de Meta. Sus principios son casi lo contrario de los de git:

• Los clientes siempre están conectados. El cliente no tiene una copia completa: pide los datos al servidor cuando los necesita.
• El servidor hace el trabajo. El historial, el blame, los commits, los merges y los rebases se hacen en el servidor. El cliente sólo mantiene una caché local limitada, coloca los ficheros en disco y vigila los cambios.
• Todo está disponible por API. Un trabajo de CI que necesita saber quién cambió una línea o la diferencia entre dos commits se lo pregunta al servidor, sin clonar nada. Herramientas suyas como el bisect o los reverts automáticos no serían viables de otra forma.
• Todo escala en horizontal. No existe una copia completa del repositorio en ningún sitio, ni siquiera en el servidor. Tampoco hay packfiles, así que no hace falta mantenimiento del repositorio.
• Commits baratos y sin bloqueos. Crear un commit cuesta en función del tamaño del cambio, no del tamaño del repositorio. Y desaconsejan las ramas y etiquetas, salvo la principal y las de release, porque cualquier estado global que todos los servidores tengan que compartir acaba siendo un problema de escala.
• La copia de trabajo es opcional. Muchos trabajos de lectura y escritura funcionan sólo con la API. Cuando sí hace falta tener ficheros en disco, el checkout es parcial o virtualizado: los ficheros se descargan cuando se leen.

Cómo funciona por dentro

La unidad básica es el changeset, una entrada en un registro de escritura (write-ahead log). A diferencia de un commit de git, que apunta al árbol completo, un changeset guarda sólo la lista de ficheros que han cambiado respecto a su padre, con punteros a su contenido en almacenamiento de objetos. Las ramas, cuando existen, se mueven con una operación atómica sobre una fila de Spanner.

Como un changeset sólo sabe qué ha cambiado, el resto (el blame, el historial de cada fichero, el grafo de commits) se calcula aparte como datos derivados, con un mecanismo genérico. Cada tipo se puede calcular en el momento o más tarde, y como el cliente nunca ve esas estructuras, se pueden optimizar sin tocarlo.

La parte de los checkouts es la que más me ha gustado. El cliente no le dice al servidor lo que ya tiene, como en git, sino que pide uno a uno los árboles y ficheros que le faltan. Como todo está direccionado por contenido y nunca cambia, cualquier caché puede responder, y la arquitectura queda como una CDN de toda la vida:

flowchart LR
    A["Trabajo o agente · cliente scn"] --> B["scion-daemon · caché del nodo"]
    B --> C["scion-cache · caché regional"]
    C --> D["scion-server · fuente de verdad"]
    D --> E[("Spanner · almacenamiento de objetos")]

Las tres capas responden a las mismas llamadas, así que el cliente no necesita saber qué hay detrás. Cada capa tiene una tasa de acierto de caché de más del 99%. El resultado:

Siete personas y cinco meses

Lo que más llama la atención es quién lo hizo y en cuánto tiempo: un equipo de siete personas construyó Scion, Antique (su herramienta de revisión de código) y media docena de sistemas más, y migró todo el monorepo desde git en cinco meses. Mientras tanto, el volumen de código integrado cada día se multiplicaba por diez.

Cuentan que el primer prototipo de la importación desde git lo escribieron a mano, y que cuando le pidieron a una versión interna de Claude Mythos Preview que lo reescribiera, sin más instrucciones, el resultado usaba 20 veces menos memoria y era 4 veces más rápido.

Pero lo que me parece más interesante del artículo es cómo describen el trabajo de los ingenieros:

• Su papel muchas veces era decirle “no” a Claude. Los agentes a veces se saltan restricciones básicas del sistema para seguir un patrón que nunca debió permitirse, como recorrer el historial de commits uno a uno en lugar de preguntar a la herramienta de revisión.
• Las revisiones adversarias también se pasan de frenada. Usan mucho la revisión entre agentes, pero a veces se obsesiona con problemas hipotéticos y acaba añadiendo validaciones y complejidad que sobran.
• Siguen revisando cada cambio, pero revisan la intención, no cada línea de código.

Esa última frase es la respuesta de Anthropic al cuello de botella del estudio de ayer. Y es un cambio importante: revisar la intención y confiar en tests, simulaciones y fuzzing para el resto. Ellos dicen que Scion es de los códigos mejor probados en los que han trabajado, y es creíble, porque escribir tests exhaustivos ya no cuesta casi nada. Pero no es una receta que pueda aplicar cualquier equipo de un día para otro.

Hay más ideas curiosas. Tienen canales de Slack con un Claude dedicado a vigilar la salud de un solo componente, que llaman “superfans”: uno para el daemon, otro para la caché, otro para la cola de merges. Y reconocen que una cola de merges con un bloqueo global no tiene sentido cuando se integran cientos de cambios mientras corren los tests, así que han pasado a hacer pruebas después del merge y antes del despliegue. Los conflictos entre cambios simultáneos los arregla Claude.

Lo que no es

Anthropic es muy clara con esto: Scion no sustituye a git para un uso general. Sólo tiene sentido en monorepos enormes, con decenas de miles de ingenieros o enjambres de agentes, y exige su propia revisión de código, búsqueda y CI. Tampoco piensan publicarlo, porque está demasiado hecho a su medida. Además, reconocen que gastan en tokens para uso interno mucho más de lo que cualquier otra empresa querría gastar.

También conviene leerlo con cierta distancia: es un artículo de Anthropic sobre lo bien que funciona Claude dentro de Anthropic. Las cifras son suyas y no hay forma de comprobarlas desde fuera.

Lo que sí proponen es llevar algunas ideas a git sin cambiar su modelo: servidores que no funcionen igual que los clientes, APIs en el servidor para consultar el repositorio, quizá estandarizadas entre forjas, y que el sparse checkout y los clones superficiales funcionen bien juntos. Creen que este tipo de problemas será habitual en 6 a 12 meses, y quieren trabajar con GitHub, GitLab y la comunidad de git.

Lo que me llevo

Hace un par de semanas hablaba de Git 3.0 y el cambio a SHA-256, un cambio que costará años a todo el ecosistema. Y ahora una empresa construye y migra a su propio control de versiones en cinco meses con siete personas. Las dos noticias juntas dicen mucho de lo rápido que está cambiando todo.

Pocos equipos van a tener 30.000 merges al día, pero la idea de fondo nos afecta a todos: las herramientas que usamos se diseñaron para el ritmo de las personas. Cuando los agentes escriben el código, los cuellos de botella se mueven a la revisión, a la CI, al control de versiones… y cada empresa los irá encontrando a su escala. El artículo es una buena guía de por dónde van a aparecer.

Fuente: Redesigning source control at Anthropic, Anthropic Engineering.