Rediseñando el control de स्रोत en Anthropic
Anthropic ha construido “Scion”, un sistema personalizado y centralizado de control de código fuente para reemplazar git en su monorepo de rápido crecimiento y en sus flotas de agentes de programación, que ahora generan decenas de miles de merges y decenas de millones de checkouts de código al día. Los comentaristas comparan el diseño con Perforce o Subversion y debaten si el problema real es la escalabilidad de git, las decisiones de monorepo y flujo de trabajo de Anthropic, o el puro volumen de churn generado por IA. El hilo plantea preguntas más amplias sobre el desarrollo impulsado por agentes: cómo revisar la intención en lugar de cada línea de código, si tal velocidad es sostenible o prudente, y por qué Anthropic no está abriendo el código de una herramienta que fue entrenada con tanto código externo.
Por qué Anthropic construyó Scion
- Git empezó a fallar a la escala de Anthropic: ~100 GB de historial de la rama principal, ~25 GB de copia de trabajo, ~25M checkouts/día para CI y agentes.
- Clonar ingenuamente por trabajo implicaría ~600 PB/día de tráfico; incluso con caché y repacking, la gente informa que el mantenimiento de repos de git se vuelve frágil.
- El monorepo es intencional: permite cambios atómicos transversales, herramientas consistentes y fácil acceso para agentes, pero amplifica los problemas de escala.
Diseño y comparaciones
- Scion es centralizado y siempre en línea: todos los commits/merges/rebases ocurren en el servidor; los clientes obtienen solo los blobs necesarios bajo demanda.
- El historial y el contenido de los archivos son objetos inmutables, direccionados por contenido, almacenados en un log + almacén de objetos, con datos derivados calculados asíncronamente.
- Muchos comentaristas dicen que esto “suena como” Subversion, Perforce, ClearCase o Piper de Google / Sapling de Meta, es decir, servidor central + árboles de trabajo virtualizados.
- Otros señalan ideas similares en EdenFS, sistemas de archivos basados en artefactos y herramientas basadas en jj; algunos lo ven como un patrón inevitable para monorepos enormes.
Escala, agentes y cambios de flujo de trabajo
- Los merges pasaron de ~2.5k/día a >30k/día, impulsados en gran medida por agentes. Algunos lo ven como “descenso de gradiente con código” o exploración a la fuerza bruta.
- La semántica de CI/merge queue cambia: no puedes bloquear globalmente el repo, así que más cosas se hacen después del merge y antes del despliegue; los conflictos semánticos concurrentes se esperan y los corrigen agentes.
- El papel de los ingenieros humanos se describe como elegir problemas, hacer concesiones arquitectónicas y decirles a menudo “no” a los agentes, luego revisar la intención más que cada línea.
Preocupaciones de calidad, seguridad y mantenibilidad
- Muchos están incómodos con 30k merges/día y una alta rotación: temen código espagueti, jank y “AI slop” acumulándose más rápido de lo que puede entenderse.
- Varios señalan que incluso hoy deben revisar de cerca código generado por IA para evitar bugs sutiles; dudan de que Anthropic pueda supervisarlo todo realmente a esta velocidad.
- Un VCS centralizado y solo en línea genera preocupaciones sobre caídas, seguridad y pérdida de flujos de trabajo offline; otros responden que las grandes organizaciones ya viven en entornos siempre en línea y orientados a API.
Código abierto, generalidad e implicaciones más amplias
- Anthropic dice que Scion es demasiado hecho a medida y demasiado divergente de git como para abrirse de forma útil; muchos lectores se frustran por una entrada de blog detallada sin código.
- Algunos sostienen que la mayoría de las organizaciones deberían seguir con git o comprar sistemas tipo Perforce; solo los laboratorios de frontera con enormes flotas de agentes y presupuestos de tokens necesitan herramientas al estilo Scion.
- Debate más amplio: los LLM hacen barato reinventar infraestructura (VCS, CI, despliegue, paneles), pero no está claro cuánto de eso produce valor duradero frente a rotación y deuda técnica.