Actualizado el 15 de octubre para incluir más detalle sobre los proyectos que fueron pioneros de muchas de las técnicas que usamos en Scion.
En Anthropic, programar ya no es el cuello de botella para construir sistemas ni para hacer investigación. Claude es capaz de iterar de forma autónoma en bucles de investigación, microoptimizar programas complejos y construir nuevos servicios desde cero a una velocidad y escala que no habíamos visto antes. El cuello de botella, ahora, es toda la infraestructura de desarrollo construida para escala humana: control de código fuente, compilaciones y CI.
En mayo de 2026, Anthropic promediaba alrededor de 2,500 cambios de código fusionados por día; a partir de septiembre, fusionábamos más de 30,000 por día. No esperamos que esta tasa de crecimiento se desacelere pronto; la demanda latente de fusionar código es prácticamente infinita, y cada cuello de botella que eliminamos conduce inmediatamente a un nuevo aumento en la cantidad de código que producimos.
Para soportar este crecimiento, construimos Scion, un sistema de control de versiones propio, y migramos completamente nuestro monorepo desde git en cinco meses. También construimos y lanzamos una superficie de revisión de código (llamada Antique), búsqueda de código, un sistema de IAM de control de código fuente completo, formas novedosas de gestionar e integrar grandes cantidades de código revisado, y más, todo en ese mismo período. En esta publicación, nos centraremos en cómo construimos Scion específicamente. Es un caso de estudio interesante: la capacidad de Claude para escribir código fue tanto lo que nos puso en esta situación en primer lugar como lo que nos permitió construir rápidamente un sistema de alta calidad y escalable para lidiar con ella.
Haciendo crecer nuestro monorepo
Antes de explorar lo que construimos, debemos reconocer cuán inusual es nuestra carga de trabajo. No es de sorprender que Anthropic use Claude para escribir software mucho más que casi cualquier otra empresa, por lo que a menudo somos los primeros en ver dónde comienzan a tensarse las herramientas construidas para escala humana. El control de código fuente es solo un ejemplo de esto. Si bien no esperamos que muchas organizaciones tengan estos problemas en el corto plazo, sospechamos que no pasará mucho tiempo antes de que otros que usan herramientas de programación con IA experimenten estos mismos puntos de presión, razón por la cual quisimos compartir lo que construimos y lo que aprendimos.
Git es un sistema descentralizado: cada clon es un repositorio completo y autónomo que puede calcular diffs, leer el historial y blame, y extraer cualquier revisión estando completamente fuera de línea. Para la gran mayoría de los repositorios, este es el diseño correcto, y es una gran parte de la razón por la que git se convirtió en el estándar.
A medida que nuestro monorepo crece, cada vez encaja menos en ese espacio de diseño. Solo el historial de nuestra rama principal es de casi 100 GB, y una comprimida copia de trabajo supera los 25 GB. Realizamos del orden de 25 millones de extracciones de código por día para CI, sin contar entornos de desarrolladores, sandboxes de agentes y trabajos de investigación. Si se obtuviera de forma ingenua, eso sería más de 600 PB de tráfico de git por día.
Git ofrece herramientas para trabajar con una porción de un repositorio, como clones superficiales (shallow clones), checkouts dispersos (sparse checkouts) y promisor remotes. Más allá de estas, existen soluciones estándar para monorepos grandes, como espejos internos de git e instantáneas de repositorios (seeds) guardadas en almacenamiento de blobs. Las hemos usado todas; en nuestro punto máximo, operábamos varios cientos de espejos internos de git para hacer frente a la carga. Esto nos compró tiempo, pero se volvieron más difíciles de operar a medida que aumentaba nuestra tasa de fusiones. Las seeds quedaban más atrás de la punta de main entre actualizaciones, y requería cada vez más cuidado mantener operativas, en clones parciales, las operaciones que dependen del historial, como diff y blame.
Dando un paso atrás, notamos que, como la mayoría de las empresas, estábamos usando git como un sistema centralizado con una copia autoritativa, pero casi todos nuestros clientes eran agentes y trabajos que están en línea por definición. Las propiedades que hacen que git sea excelente para el trabajo distribuido y fuera de línea estaban socavando activamente nuestra capacidad de escalar a medida que el repositorio crecía. Así que nos preguntamos: si diseñáramos el control de código fuente teniendo en cuenta desde el principio que los agentes están siempre en línea, ¿cómo sería?
Principios para un control de código fuente a escala de agentes
Con la programación agéntica, muchas suposiciones comunes sobre cómo se desarrolla el software están evolucionando. Abrazamos estos cambios al construir Scion, lo que nos permitió adoptar un enfoque fundamentalmente diferente al de git en varios principios centrales. El control de código fuente para monorepos enormes tiene precedentes, notablemente Piper de Google y Sapling,2 de Meta, por lo que pudimos construir Scion teniendo en cuenta sus lecciones duramente aprendidas. Nuestros principios son:
Los clientes están siempre en línea. Git asume que los clientes trabajan fuera de línea y necesitan una copia completa del repositorio. Dado que casi todos nuestros clientes son agentes y trabajos, diseñamos el cliente y los protocolos de Scion en torno a un servidor que siempre es alcanzable, y hacemos que los clientes obtengan los datos cuando los necesiten.
Asimetría cliente-servidor. En git, cada cliente es capaz de ser un servidor completo. En Scion, el servidor responde preguntas sobre el historial de archivos y blame, crea commits, realiza fusiones y rebases, y así sucesivamente. El cliente mantiene una caché local de objetos acotada, organiza los archivos de la copia de trabajo en el disco, monitorea los cambios del sistema de archivos y brinda a los usuarios una forma ergonómica de trabajar con el servidor. Puede calcular muy poco por sí mismo, pero, a cambio, requiere muchos menos datos localmente.
Un servicio de control de código fuente integral puede impulsar muchas aplicaciones novedosas. Con git, un trabajo de CI o una herramienta que necesita hacer una pregunta sobre el repositorio, como quién cambió por última vez una línea o cómo se relacionan dos commits, tiene que mantener una copia local del repositorio o esperar que las API específicas del proveedor proporcionen la respuesta. Con Scion, todas las consultas de control de código fuente que usa el cliente también se exponen a través de una API, de modo que en muchos casos los trabajos no necesitan un repositorio local en absoluto. Muchas herramientas internas, como nuestras canalizaciones automatizadas de bisect y revert, no serían prácticas a gran escala sin este acceso programático y barato al control de código fuente.
Todo debe ser escalable horizontalmente. En nuestro punto máximo, ejecutábamos varios cientos de réplicas git, lo que tensaba significativamente la capacidad y ya no escalaba una vez que el repositorio superaba los límites de disco o memoria de las réplicas. En Scion, los datos del repositorio están distribuidos y cada componente se escala de forma independiente; no existe ninguna copia completamente materializada del repositorio en ningún lugar, ni siquiera en el servidor. No hay un equivalente de los packfiles (los paquetes comprimidos de objetos de git), por lo que no se necesita mantenimiento del repositorio.
Los commits deben ser baratos, incrementales y sin bloqueos. En git, haces commit localmente y luego haces push para compartir tu trabajo. En Scion, cada commit, rebase o merge ocurre en el servidor, por lo que no hay nada que hacer push, pero cada una de esas operaciones necesita ser rápida. El costo de crear un commit y actualizar sus estructuras de datos aguas abajo tiene que escalar con el tamaño del cambio, no con el tamaño general del repositorio, o el servidor no puede mantener el ritmo. El ciclo de vida de desarrollo en Scion desaconseja las refs (punteros a commits, como ramas y etiquetas), excepto para la ref principal o las ramas de release, porque global es un estado en el que cada servidor debe estar de acuerdo y que representa un inminente problema de escalabilidad.
La copia de trabajo es opcional y dispersa por diseño. Debido a que nuestro monorepo es tan grande, y porque hacemos checkout de código decenas de millones de veces al día para CI, queríamos evitar los checkouts siempre que pudiéramos. Con Scion, por ejemplo, un trabajo de CI que necesita el diff entre un commit y su base de merge puede pedírselo al servidor. Lo mismo aplica para las escrituras: muchas cargas de trabajo de escritura también pueden omitir el checkout y funcionar completamente a través de la API. El protocolo de Scion se centra en los checkouts dispersos, que solo contienen los directorios que el cliente solicita, y los checkouts virtualizados, que materializan archivos a demanda, de modo que cuando un trabajo sí necesita archivos en disco, el cliente solo paga por lo que realmente lee.
Cómo funciona Scion
Es útil entender cómo estos principios se unieron en la práctica al construir Scion. Estas ideas pueden aplicarse a otros sistemas de control de código fuente o, más ampliamente, a otras etapas del ciclo de vida del desarrollo de software.
Estructuras de datos
En Scion, la unidad de trabajo es un “changeset”, una entrada en un registro de escritura anticipada (write-ahead log). Un changeset almacena la mayor parte de lo que se esperaría de un commit en git. Pero donde un commit de git almacena un puntero al árbol, un changeset almacena una lista de los archivos que cambiaron respecto a su primer padre,1 junto con punteros direccionados por contenido a los contenidos comprimidos de los archivos en almacenamiento de blobs. Los changesets se crean en el servidor y están disponibles en todas partes, al instante.
Esta estructura nos permite aceptar changesets con un rendimiento muy alto porque no hay packfiles que aceptar, no hay bloqueos ni coordinación entre servidores, y no hay refs que mover. Scion técnicamente sí admite refs, pero dado que ni crear ni recuperar commits las involucra, mover una es una operación de comparar e intercambiar en una única fila de Spanner que ocurre por separado de la creación de changesets.
Un changeset registra solo lo que ha cambiado, por lo que por sí solo no puede responder rápidamente preguntas como quién editó por última vez una línea o qué commits afectaron a un archivo. Para responder a esas preguntas, Scion construye estructuras de datos adicionales a partir de los changesets, incluyendo estructuras dedicadas para file blame e historial de rutas, y skip lists para el grafo de commits. Llamamos “datos derivados” a todo lo que no es directamente parte del changeset, y lo calculamos todo a través de un mecanismo genérico. Cada tipo de dato derivado se define recursivamente, de modo que su valor para un changeset se calcula a partir de sus valores para los padres de ese changeset.
Este mecanismo tiene tres beneficios. Primero, podemos agregar fácilmente un nuevo tipo de dato derivado cuando una nueva estructura de datos haría más rápida alguna operación. Segundo, para cada tipo, podemos elegir si calcularlo de forma ansiosa o diferir el trabajo, así evitamos materializar datos que no necesitamos. Y tercero, como el cliente nunca ve el interior de estas estructuras de datos, podemos optimizarlas sin cambiar el cliente. Hemos agregado nuevos tipos de datos derivados muchas veces a medida que el sistema ha crecido, como nuevos índices para realizar detección de copias o búsqueda de archivos basada en rutas.
Escalando Scion
Una pequeña flota de servidores Scion proporciona API de control de código fuente para cualquier operación que un cliente necesite, como obtener changesets, calcular diffs, encontrar bases de merge y recuperar blobs. Todos los datos de control de código fuente están direccionados por contenido, por lo que un dato nunca cambia una vez almacenado, y cualquier servidor puede almacenarlo en caché sin consultar a los demás. Como resultado, los servidores son escalables horizontalmente y requieren poca coordinación. Son esencialmente grandes cachés que también pueden calcular datos derivados sobre la marcha y escribir los resultados de vuelta en Spanner.
Los muchos consumidores de Scion ya no necesitan mantener repositorios locales propios. Obtener y mantener el repositorio solía ser una carga de mantenimiento significativa para los trabajos de CI o las herramientas que necesitaban hacer preguntas al control de código fuente, en particular sobre la ascendencia de commits y el blame. Al principio de la migración, antes de que tuviéramos nuestro propio cliente, formato de repositorio o protocolos, Scion solo respondía estas consultas de “metadatos”. Obtener contenidos de archivos y materializar copias de trabajo son operaciones mucho más intensivas en datos, y necesitaban un diseño propio.
El cliente scn de Scion se desvía de los protocolos de fetch de git en varios aspectos importantes y, como resultado, se presta a una arquitectura altamente escalable que requiere significativamente menos CPU que los servidores de git. La negociación de Scion no le dice al servidor lo que el cliente ya tiene; en cambio, opera exclusivamente sobre los árboles y blobs que el cliente quiere. Partiendo de un árbol raíz, el cliente busca en su almacén local los árboles faltantes y los solicita de forma recursiva, y luego repite el proceso con los blobs. Cada solicitud es de un objeto específico que nunca cambia, de modo que cualquier caché puede responderla, y la arquitectura se asemeja mucho a las cachés tradicionales por niveles. El proceso también es eficiente y reanudable, porque no hay una única respuesta de packfile de varios gigabytes. Los checkouts dispersos e incluso virtualizados no necesitan soporte especial, porque el cliente simplemente no solicita los árboles que no quiere.
En el clúster, el cliente se comunica a través de un socket con un daemon, scion-daemon, que almacena objetos para todo el nodo. La mayoría de nuestros nodos necesitan acceso al monorepo, y los trabajos en el mismo nodo reutilizan la mayoría de los mismos objetos. Cada daemon parte de una instantánea actualizada periódicamente y luego se comunica solo con los servidores de caché de árboles y blobs de su región, llamados scion-cache. Estos servidores de caché transmiten objetos directamente desde la memoria, en el formato de disco que el daemon consumirá, por lo que no necesitan dedicar tiempo a calcular los objetos faltantes del cliente ni a realizar compresión delta. Cuando a una caché le falta un objeto, se lo pide a los scion-servers autoritativos, que leen de Spanner o del almacenamiento en la nube según sea necesario.
El scion-daemon, el scion-cache y el scion-server responden a RPC idénticos para este protocolo, por lo que el cliente no necesita conocer la topología de caché. En teoría, cualquier nivel podría comunicarse con cualquier otro, pero aplicamos estrictamente la estratificación para aislar los dominios de fallo. Queremos evitar una situación en la que un fallo en un scion-cache regional abrume a los scion-servers ascendentes y tire todo el sistema.
Cada nivel de este sistema mantiene una tasa de acierto de caché superior al 99% y no requiere estado de larga duración, por lo que es fácil escalar si es necesario. Nuestra infraestructura de Scion es ahora 200 veces más pequeña que nuestra infraestructura anterior de espejos de git en términos de requisitos de CPU y memoria. Los trabajos de CI e investigación obtienen el código dos órdenes de magnitud más rápido (en segundos en lugar de minutos), lo que libera una cantidad considerable de capacidad en todo el clúster; solo el CI obtuvo una mejora del 25% en capacidad de CPU. Ni los clientes ni las cachés necesitan realizar mantenimiento del repositorio, lo que simplifica la gestión del ciclo de vida de nuestros trabajos.
Lo que aprendimos construyendo Scion
Empezamos a construir Scion más o menos al mismo tiempo que Claude Mythos Preview y Claude Tag estuvieron disponibles internamente. Ambos lanzamientos simultáneamente amplificaron la necesidad de Scion y aceleraron significativamente la velocidad con la que pudimos construirlo.
Este es un ejemplo particularmente llamativo. A principios de año, habíamos escrito a mano en gran parte la primera versión del pipeline de ingesta de git a Scion como prototipo. Pensábamos que era bueno, hasta que tuvimos en nuestras manos una instantánea interna temprana de Claude Mythos Preview. Le pedimos que reescribiera todo, y sin más instrucciones, produjo una versión que consumía 20 veces menos memoria y era 4 veces más rápida, conservando todos los invariantes implícitos en torno al orden de ingesta y las estructuras de datos.
Lo que aprendimos al construir y operar Scion ofrece algunas lecciones interesantes sobre cómo podría ser construir software a escala de agentes.
El desarrollo rápido con un equipo pequeño se volverá más común. Un equipo de siete personas construyó tanto Scion como Antique (nuestra herramienta de revisión de código, sobre la que podríamos escribir fácilmente toda otra entrada de blog), sin mencionar media docena de sistemas relacionados, y migró completamente a ellos en cinco meses. Hicimos todo esto mientras el volumen de código fusionado por día aumentaba 10 veces. En el pasado, desarrollar y desplegar un sistema de control de código fuente como este habría tomado a una empresa años de migración iterativa, con muchos más ingenieros. Creemos que este tipo de migración rápida y ágil se volverá más común en el futuro.
Los ingenieros siguen siendo igual de valiosos, pero su trabajo está cambiando. Todos los ingenieros que trabajaron en este sistema ahora calificarían a Claude como mejor que escribiendo código que ellos mismos. Pero nuestros ingenieros siguen aportando la inestimable comprensión de los componentes inter-sistemas de alto nivel y de los compromisos a nivel de diseño, tomando decisiones informadas sobre los problemas que queríamos resolver y la escala que sabíamos que necesitábamos alcanzar. Muy a menudo, descubrimos que el papel de los ingenieros era decirle a Claude “no”. Los agentes a veces violan restricciones fundamentales del sistema para satisfacer un patrón que nunca debió permitirse en primer lugar. Esto fue particularmente común en nuestra migración. Por ejemplo, hubo varios sistemas que intentaron resolver por fuerza bruta cuándo se fusionó un cambio en main leyendo linealmente el registro de commits en lugar de preguntar a nuestra herramienta de revisión de código. Anthropic también hace un uso extensivo de la revisión adversarial y, aunque esto es increíblemente eficaz de muchas maneras, también puede ser miope, por lo que ingenieros expertos tuvieron que alejar a Claude de la sobreingeniería de partes del sistema en respuesta a preocupaciones hipotéticas. Por ejemplo, una de esas revisiones fue excesivamente defensiva al confiar en otro servicio interno, lo que resultó en que Claude añadiera validación y complejidad excesivas. 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.
Pudimos mejorar sustancialmente la optimización y la calidad. Gracias a la capacidad de Claude para escribir cantidades inmensas de código mucho más rápido de lo que nosotros podríamos, Scion se encuentra entre las bases de código mejor probadas y mejor defendidas en las que hemos trabajado. Incluso con nuestro apretado cronograma, pudimos construir simulaciones herméticas de cada interacción no trivial de infraestructura y control de fuentes que hemos encontrado, así como fuzzing y limitación de tasas sofisticada. Claude también encontró casualmente optimizaciones significativas, por ejemplo, una optimización algorítmica para consultas de ascendencia que había pasado por alto uno de nuestros índices, que le habría tomado a un experto días o semanas de análisis y ajuste… y luego lo hizo todo de nuevo al día siguiente.
Sentamos las bases para nuevas formas de seguridad en monorepos. Gestionar la seguridad, la protección y el cumplimiento en un monorepo masivo es tan importante como gestionar el tamaño y la escala. Construimos Scion con esto en mente desde el principio. Soporta un control de acceso rico en repositorios, así como la capacidad de aplicar permisos a directorios individuales para proteger el código más sensible sin perder los beneficios de un monorepo. Además, las herramientas de revisión de código que construimos pueden expresar restricciones semánticas complejas sobre las aprobaciones, lo que nos permite diferenciar cosas simples como cambios de solo comentarios de cambios lógicos sensibles, de modo que los revisores humanos puedan centrarse en los cambios más trascendentales.
Es posible un nuevo nivel de excelencia operativa. Nuestro equipo usa Claude Tag intensivamente, lo que nos ha ayudado a monitorear cada componente del sistema. Por ejemplo, creamos canales de Slack donde encargamos a Claude que se centrara obsesivamente en la salud de un solo componente. Llamamos a estos Claudes “superfans”. Tenemos un superfan de scion-daemon, un superfan de scion-cache, un superfan de la cola de fusión Antique, y así sucesivamente. Tienen acceso a nuestra telemetría y registros, y actúan como un ingeniero experimentado que no tiene nada mejor que hacer que actualizar gráficos y buscar cualquier cosa extraña. También tenemos alertas tradicionales para todos nuestros sistemas, pero nuestros superfans pueden detectar problemas sutiles y novedosos que hacen que estas alertas parezcan unidimensionales en comparación.
Estamos repensando completamente nuestras premisas. Este proyecto nos llevó a examinar muy de cerca otros flujos de trabajo diseñados a escala humana. Una cola de fusión adecuada, por ejemplo, no tiene mucho sentido a escala de agentes. ¿Qué significa siquiera CI cuando cientos o incluso miles de cambios pueden fusionarse mientras se ejecutan las pruebas? No hemos podido replicar eficazmente el estándar de la industria de un bloqueo global del repositorio en la cola de fusión, así que en cambio, hemos invertido en pruebas automatizadas posteriores a la fusión y previas al despliegue. Esto sí significa que los cambios concurrentes pueden entrar en conflicto, pero Claude normalmente puede corregir estos conflictos más rápido de lo que los humanos pueden siquiera identificarlos.
Contribuir al ecosistema más amplio
Vemos a Scion como solo una parte de la respuesta a las preocupaciones de escalabilidad que los agentes de IA cada vez más capaces han planteado. Compartimos estos detalles como un ejemplo de cómo los equipos pueden abordar desafíos similares, aunque no esperamos que nuestra solución, o nuestras consideraciones, se adapten a todos los casos.
Scion no es de ninguna manera un reemplazo adecuado de git para uso general. Los conceptos que hemos descrito aquí realmente solo tienen sentido para monorepos verdaderamente enormes, con decenas de miles de ingenieros o enjambres de agentes escribiendo código de manera prolífica. Además, Anthropic es única en que nuestra capacidad de gastar tokens para uso interno excede con creces lo que cualquier otro negocio querría gastar de manera realista. Hacemos esto tanto para atender nuestras propias necesidades de desarrollo de software como para probar las capacidades de Claude.
En términos prácticos, es difícil ofrecer Scion en una forma que sea ampliamente útil para otras organizaciones. Se desvía significativamente de git, lo que significa que las empresas tendrían que migrar cada pieza del ciclo de vida de desarrollo, y requiere su propia revisión de código, búsqueda de código y CI. Nuestras versiones internas de estos componentes son altamente a medida, por lo que sería difícil para otras organizaciones adoptarlas, y nos preocupa que intentar construir una versión pública que intente complacer a todos no sería realmente muy útil.
Sin embargo, anticipamos que esta clase de problemas se volverá más común durante los próximos seis a 12 meses, y sería un uso ineficiente de los recursos de ingeniería que cada empresa que usa git enfrente desafíos similares por su cuenta. Dado eso, creemos que lo más impactante que podemos hacer es compartir nuestro razonamiento, para que otros desarrolladores puedan aplicar algunas de las partes más exitosas de Scion a git sin abandonar el modelo general. Un servidor git no tiene que funcionar de la misma manera que un cliente git; existen arquitecturas de servidor novedosas que ofrecen mejoras significativas de escalabilidad. Las plataformas git pueden proporcionar RPC completos del lado del servidor como Scion, quizás incluso de manera estandarizada entre forjas con las que el cliente git pueda aprender a comunicarse. El protocolo de negociación tampoco tiene que verse exactamente como hoy, y las diversas funciones dispersas y superficiales de git pueden hacerse funcionar bien juntas.
Por último, queremos reconocer que la comunidad de git ha pasado casi dos décadas escalando la plataforma para millones de desarrolladores. Nuestra contribución es mucho más limitada: compartir nuestra visión temprana de cómo el desarrollo de software agéntico interactúa con estos sistemas, de modo que podamos asociarnos con GitHub, GitLab y la comunidad OSS para apoyar las necesidades cambiantes de los desarrolladores. Todos estamos juntos en esto cuando el ciclo de vida del desarrollo de software se cruza con la exponencial de la IA.
Notas al pie
01Almacenar los archivos modificados en relación con el primer padre de una fusión es una decisión de estilo; en la práctica, hemos encontrado que la gente solo se interesa por el historial o el blame de las confirmaciones en la línea principal en el desarrollo basado en tronco dentro de un monorepo.
02Específicamente, el componente de servidor de Sapling, Mononoke. Fue pionero en muchas de las técnicas que usamos en Scion, en particular el Bonsai modelo de datos.
Autores y agradecimientos
Agradecimientos
Escrito por Nick G. y el equipo de control de código fuente: S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P. Estamos agradecidos con Vilas J. y Sergiu D. por apoyar al equipo de control de código fuente en este ambicioso viaje, y con Amir O. por sus contribuciones tempranas a Antique.