Anthropic publicó el 13 de octubre de 2026 cómo migró su repositorio principal de Git a Scion, un sistema de control de versiones construido para su uso interno. La novedad es la explicación de una migración realizada durante cinco meses, no la disponibilidad de un producto que otros equipos puedan instalar hoy.
El artículo de ingeniería de Anthropic describe un problema concreto: al aumentar los cambios generados con Claude, obtener y gestionar el código pasó a ser un cuello de botella. Para un responsable de desarrollo, la pregunta útil es qué medir cuando los agentes producen trabajo más deprisa de lo que la infraestructura puede procesarlo.
Una carga de trabajo excepcional
Según Anthropic, en mayo integraba alrededor de 2.500 cambios diarios y en septiembre superaba los 30.000. Son cifras de su operación interna, no una medida de productividad general ni una previsión para quienes contraten Claude. Su monorepo —un repositorio que reúne muchos proyectos— alimenta trabajos automáticos y entornos de agentes a una escala poco habitual.
Git permite trabajar con historial local y sin conexión. Anthropic explica que esa autonomía seguía siendo adecuada para la mayoría de repositorios, pero aportaba poco a sus clientes, casi siempre procesos conectados. Mantener copias y servir descargas del repositorio tenía un coste creciente. La empresa había utilizado clones parciales, copias de apoyo y otras técnicas antes de cambiar de diseño.
Qué lleva Scion al servidor
Scion asume clientes conectados. El servidor resuelve consultas de historial, calcula diferencias e integra cambios; el cliente conserva una caché limitada y obtiene los archivos que necesita. Algunos trabajos pueden consultar la interfaz de programación, o API, sin preparar una copia local del repositorio.
Por ejemplo, un proceso que solo necesita conocer qué archivos cambiaron puede pedir esa información al servicio. Si otro trabajo requiere archivos para ejecutar pruebas, sigue necesitando obtenerlos. La diferencia es evitar transferencias y mantenimiento que no corresponden a la tarea, no hacer desaparecer la dependencia del código.
El sistema comparte cachés por nodo y región y utiliza contenido inmutable para reutilizar datos. Anthropic también describe capas de servicio que aíslan fallos y evitan sobrecargar los servidores centrales. Publica mejoras de rendimiento propias; no las trasladamos a otros entornos ni las presentamos como mediciones de Puntoes.
Producir código no elimina la revisión
Scion se acompaña de Antique, una herramienta distinta para revisar código. La fuente describe permisos por directorio y restricciones de aprobación según el tipo de cambio. También cuenta que los ingenieros continuaron revisando cada solicitud y tuvieron que frenar decisiones de los agentes que vulneraban restricciones del sistema o añadían complejidad innecesaria.
Esto conecta con nuestro análisis de acciones no deseadas en agentes: terminar una tarea no acredita que se hayan respetado sus límites. La lección que extraemos es separar producción, permisos y autorización. Nuestro antecedente sobre aprobaciones vinculadas a una versión desarrolla ese último problema en otro contexto; no describe la implementación de Scion.
A su escala, Anthropic dice que reforzó las pruebas tras integrar cambios y antes del despliegue. Esa decisión no demuestra que un equipo habitual deba quitar sus comprobaciones previas. Cada flujo necesita definir qué errores puede detectar antes de publicar y cómo recuperarse después.
Un diagnóstico antes de pensar en migrar
Ejemplo hipotético, no ejecutado en Puntoes: veinte agentes trabajan en un repositorio y cada tarea obtiene una copia completa para calcular una diferencia pequeña. Primero separaríamos el tiempo de descarga, el de pruebas automáticas y la espera de revisión humana. Si las pruebas concentran la espera, cambiar el control de versiones no resolvería ese cuello de botella.
Si domina la preparación del código, examinaríamos cuánto necesita leer cada tarea y qué consultas pueden evitar una copia completa. Mantendríamos los permisos y las aprobaciones como condiciones del diseño. Son preguntas para un diagnóstico, no una receta probada ni resultados de un laboratorio.
La propia Anthropic limita la adopción: Scion diverge de Git y exigiría migrar también revisión, búsqueda e integración continua, es decir, las comprobaciones automáticas del desarrollo. Además, depender de un servidor conectado cambia el funcionamiento sin conexión y las necesidades operativas.
Descubrimos también el análisis de Simon Willison sobre Scion, y contrastamos los hechos con el original. El criterio que proponemos es medir primero dónde se atasca el trabajo. Scion ofrece un caso de ingeniería para cargas excepcionales; no una justificación automática para reemplazar Git.