En mayo de 2026 Anthropic integraba unos 2.500 cambios al día en su monorepo; en septiembre, más de 30.000. Según su post de ingeniería del 13 de octubre de 2026, el control de versiones pasó a ser el mayor cuello de botella, y lo resolvieron con Scion, un sistema propio con el que migraron desde git en cinco meses. Es un caso extremo, pero enseña qué se rompe primero cuando los clientes dejan de ser personas.
Qué cambia
El diagnóstico es que usaban git como sistema centralizado (una copia autoritativa), pero casi todos sus clientes son agentes y jobs de CI que están online por definición. Las propiedades que hacen a git bueno para trabajo distribuido y offline se volvían un lastre. Los números que dan: el historial de la rama principal ronda los 100 GB, la copia de trabajo comprimida supera los 25 GB y hacen del orden de 25 millones de checkouts al día solo para CI. Habían llegado a operar varios cientos de mirrors internos de git.
Los principios de Scion, según el post:
- Clientes siempre online. El servidor responde a historial, blame, commits, merges y rebases; el cliente solo mantiene una caché acotada de objetos y organiza los ficheros en disco.
- Commits baratos y sin bloqueos. Todo commit, rebase o merge ocurre en el servidor. La unidad es el changeset, una entrada de un write-ahead log con la lista de ficheros cambiados y punteros a contenido direccionado por hash. No hay packfiles ni refs que mover en cada commit; mover una ref es un compare-and-swap sobre una fila de Spanner.
- Copia de trabajo opcional y dispersa. Un job de CI que necesita el diff contra el merge base se lo pide al servidor por API, sin clonar. Si necesita ficheros, el protocolo gira en torno a checkouts dispersos o virtualizados.
- Datos derivados. Blame, historial por ruta o skip lists del grafo de commits se calculan con un mecanismo genérico y recursivo sobre los padres, de forma eager o diferida.
Para los checkouts hay tres niveles de caché (scion-daemon en el nodo, scion-cache regional y scion-server autoritativo sobre Spanner y almacenamiento cloud). Como todo es inmutable y direccionable por contenido, cualquier nivel puede cachear sin coordinarse. Cada nivel supera el 99 % de aciertos.
Resultados que cuentan: la infraestructura de Scion es 200 veces más pequeña (CPU y memoria) que la de los mirrors de git, los checkouts de CI e investigación son dos órdenes de magnitud más rápidos (segundos en vez de minutos) y solo CI ganó un 25 % de capacidad de CPU.
Por qué importa en producción
Casi nadie tiene 30.000 merges diarios, y el propio post lo reconoce. Lo útil es el patrón: cuando agentes y jobs consumen el repositorio, el coste lo dominan los checkouts y las consultas de historial, no el git push de una persona. Si ya mantienes mirrors, seeds en blob storage o clones parciales con blame lento, estás en la misma trayectoria a menor escala.
También hay lecciones de proceso. Un equipo de siete personas construyó Scion y la herramienta de revisión Antique mientras el volumen de código se multiplicaba por diez. Según el equipo, su papel era a menudo decir "no" a Claude: varios sistemas intentaban averiguar cuándo se había integrado un cambio leyendo el log linealmente en vez de preguntar a la herramienta de revisión, y las revisiones adversarias empujaban hacia sobreingeniería defensiva. Revisan cada change request, pero examinando la intención y no cada línea.
Una cautela mía: son datos del propio Anthropic sobre su sistema interno, sin código público ni benchmarks reproducibles. Scion no se puede adoptar; sirve para razonar.
Qué haría yo
- Medir cuántos checkouts completos hace tu CI al día y cuánto tarda cada uno. Es la línea base.
- Pasar a clones superficiales o dispersos (
--filter=blob:none, sparse checkout) en los jobs que solo necesitan un subárbol. - Sustituir clones por llamadas a la API de tu forge cuando el job solo pregunta por un diff, un merge base o un autor.
- Revisar qué consultas de historial hacen tus herramientas leyendo el log completo y moverlas a un índice.
- Poner un agente o alerta dedicada a cada componente crítico de la plataforma de desarrollo, como los "superfans" que describen.
Fuentes
- Redesigning source control at Anthropic, Anthropic Engineering, 13 de octubre de 2026.
- Comentario de Simon Willison, 13 de octubre de 2026.