Rediseñando el control de código fuente en Anthropic: Claude superó a Git
Anthropic reemplazó Git después de que Claude ayudara a llevar su monorepo de unas 2.500 fusiones diarias en mayo de 2026 a más de 30.000 en septiembre. Ese aumento convierte el rediseño del control de código fuente en Anthropic en algo más que una historia de migración de infraestructura. Muestra qué ocurre cuando la IA genera código más rápido de lo que los sistemas de desarrollo pueden absorber de forma segura.
La empresa construyó Scion, un sistema interno de control de código fuente diseñado en torno a agentes en línea, operaciones del lado del servidor y acceso disperso a un repositorio gigantesco. Siete ingenieros también crearon Antique, un nuevo sistema de revisión de código, además de varios servicios relacionados. Anthropic afirma que el equipo completó la migración en cinco meses.
El conflicto importante no es simplemente Scion frente a Git. Es la producción de código a escala de agentes frente a prácticas de desarrollo diseñadas en torno a la atención humana. Google y Meta ya han construido sistemas especializados para monorepositorios enormes. Anthropic llegó a un destino similar a través de una fuente de presión distinta: enjambres de agentes de software que nunca necesitan trabajar sin conexión.
El rediseño del control de código fuente en Anthropic comenzó con 30.000 fusiones diarias
Anthropic no abandonó Git porque a sus ingenieros no les gustara Git. Lo abandonó porque Claude cambió la forma y el volumen del tráfico del repositorio.
Según el relato de ingeniería de Anthropic, las fusiones diarias aumentaron más de diez veces entre mayo y septiembre de 2026. La empresa presenta ese crecimiento como una demanda sostenida, no como un pico de migración de corta duración.
La carga de trabajo resultante fue mucho más allá de la creación de commits. El historial de la rama principal de Anthropic se acercó a los 100 GB, mientras que una copia de trabajo comprimida superó los 25 GB. La integración continua, o CI, realizaba unos 25 millones de checkouts de código cada día antes de contabilizar los entornos de desarrollo, los sandboxes de agentes y los trabajos de investigación.
Anthropic calculó que obtener esos checkouts de forma ingenua generaría más de 600 petabytes de tráfico diario de Git. La empresa utilizó clones superficiales, checkouts dispersos, instantáneas de repositorios y varios cientos de mirrors internos de Git para controlar ese coste.
Esas medidas ganaron tiempo, pero el repositorio siguió cambiando con mayor rapidez. Las instantáneas quedaban obsoletas entre actualizaciones. Los clones parciales también complicaban operaciones como las búsquedas de historial, los diffs y blame, que identifica quién modificó por última vez una línea.
El problema de la empresa procedía de un desajuste entre las fortalezas de Git y los clientes predominantes de Anthropic. Git proporciona a cada clon suficiente información para funcionar como un repositorio autosuficiente. Ese diseño permite el desarrollo sin conexión, el historial local y la colaboración descentralizada.
Los agentes y trabajos automatizados de Anthropic ya estaban en línea. No necesitaban un historial local completo ni la capacidad de actuar como servidores independientes. Sin embargo, la infraestructura distribuía y mantenía repetidamente datos del repositorio como si cada cliente fuera un desarrollador humano usando un portátil.
Scion invierte esa premisa. Su servidor realiza consultas de historial, crea commits, calcula diffs y gestiona fusiones o rebases. Un cliente ligero mantiene una caché acotada y materializa únicamente los archivos necesarios para la tarea actual.
Esa diferencia importa cuando un trabajo de investigación necesita un directorio en lugar de todo el monorepo. También importa cuando un servicio de CI solo necesita un diff o el cálculo de una base de fusión. Scion puede responder a esas solicitudes mediante una API sin crear una copia de trabajo tradicional.
La nueva arquitectura ha producido importantes mejoras internas, según Anthropic. Al parecer, cada nivel de caché mantiene una tasa de aciertos superior al 99 por ciento. La infraestructura utiliza 200 veces menos CPU y memoria que la anterior flota de mirrors de Git.
Anthropic también afirma que los checkouts de CI e investigación pasaron de minutos a segundos. El cambio devolvió el 25 por ciento de la capacidad de CPU de CI a la flota informática más amplia.
Estas son mediciones comunicadas por la empresa desde un sistema interno. Investigadores externos no pueden reproducirlas sin acceso a las cargas de trabajo, repositorios e infraestructura de Anthropic. Aun así, las cifras explican por qué otra ronda de ajustes a Git ya no parecía suficiente.
El sistema debía admitir más que un repositorio grande. Debía admitir un repositorio cuyos principales escritores, lectores y consumidores automatizados operaban a velocidad de máquina.
Claude convirtió la infraestructura de software en el cuello de botella
La verdadera importancia de Scion es que la generación de código dejó de ser el recurso escaso de Anthropic. La capacidad de revisión, la infraestructura y el criterio se convirtieron en las limitaciones.
Los asistentes de programación con IA encajaban originalmente en un proceso de desarrollo conocido. Una persona solicitaba una función, inspeccionaba el resultado, ejecutaba pruebas y enviaba una pull request. El asistente aumentaba la velocidad de escritura de cada desarrollador sin cambiar el sistema circundante.
Anthropic describe un modelo operativo más avanzado. Según se informa, Claude itera a través de ciclos de investigación, optimiza programas complejos, crea servicios, supervisa componentes de producción y ayuda con grandes migraciones. Cada actividad puede producir nuevos cambios o requerir acceso nuevo al repositorio.
Ese patrón genera presión multiplicativa. Un agente puede iniciar otra tarea mientras un cambio anterior avanza por las pruebas. Los revisores automatizados pueden solicitar correcciones, que generan cambios adicionales. Después, los sistemas de CI crean checkouts e invocan más consultas al repositorio para cada candidato.
El gráfico destacado por Simon Willison muestra un fuerte aumento durante 2026. Willison relacionó la aceleración con las generaciones más recientes de modelos internos de Anthropic, distinguiendo cuidadosamente la disponibilidad interna de las fechas de lanzamiento público.
Anthropic establece una conexión más específica. Afirma que el desarrollo de Scion comenzó en torno al momento en que Claude Mythos Preview y Claude Tag estuvieron disponibles internamente. Según se informa, esos modelos incrementaron la necesidad de Scion al mismo tiempo que ayudaban al equipo a construirlo.
Un ejemplo involucró el pipeline que trasladaba datos de Git a Scion. Los ingenieros de Anthropic habían escrito a mano un prototipo inicial. Una versión interna temprana de Claude Mythos Preview reescribió después el pipeline con pocas indicaciones adicionales.
Según se informa, el reemplazo utilizó 20 veces menos memoria y funcionó cuatro veces más rápido. Anthropic afirma que preservó requisitos implícitos relacionados con el orden de ingesta y las estructuras de datos. La afirmación es llamativa, pero sigue siendo un resultado descrito por la empresa, no un benchmark independiente.
El ciclo de retroalimentación más amplio es más fácil de establecer. Una generación de código más rápida incrementó la actividad del repositorio. Esa actividad justificó nueva infraestructura. Claude ayudó entonces a construir la infraestructura, que eliminó otro límite a la generación de código.
Este ciclo presiona cada parte del ciclo de vida de desarrollo. Un servicio de compilación que gestiona cambios al ritmo humano puede encarecerse cuando los agentes crean miles de tareas simultáneas. Una cola de revisión resulta menos útil si el repositorio avanza mediante cientos de cambios mientras se ejecuta una suite de pruebas.
El acceso al conocimiento también se convierte en parte de la limitación. Los agentes necesitan especificaciones, decisiones arquitectónicas, historial de incidentes y contexto de propiedad, no solo archivos fuente. Los equipos que construyen flujos de trabajo similares necesitan una base de conocimiento de ingeniería con capacidad de búsqueda junto a una infraestructura de código más rápida.
Anthropic afirma que ahora utiliza monitores persistentes de Claude llamados “superfans” para componentes individuales de Scion. Estos agentes observan la telemetría y los logs mediante canales dedicados de Slack. Las alertas tradicionales se mantienen, mientras los agentes buscan patrones que los umbrales fijos podrían pasar por alto.
Ese modelo operativo eleva el trabajo de ingeniería. Las personas definen invariantes, eligen límites arquitectónicos, interpretan fallos y deciden qué debe llegar a producción. Los agentes generan implementaciones e investigan la telemetría dentro de esos límites.
El cambio no elimina al ingeniero. Cambia la habilidad escasa: de producir código a decidir qué código merece existir.
Scion reemplaza el modelo sin conexión de Git por un servicio a escala de agentes
Scion gana rendimiento al renunciar a la simetría definitoria de Git: un cliente ya no transporta toda la inteligencia del repositorio.
Los commits de Git contienen punteros a árboles completos de directorios. Los clientes intercambian colecciones comprimidas de objetos llamadas packfiles, lo que permite a los repositorios locales conservar el historial y operar de forma independiente. Este modelo sigue siendo apropiado para la mayoría de los proyectos de software.
Scion utiliza un changeset, una entrada en un registro de escritura anticipada que registra archivos modificados respecto a un elemento padre. Los contenidos de los archivos se comprimen, se direccionan por contenido y se almacenan por separado. El direccionamiento por contenido significa que la clave de almacenamiento se deriva de los datos, por lo que los objetos inmutables se pueden almacenar en caché de forma segura.
Los changesets se crean en el servidor y pasan a estar disponibles en todo el sistema. No requieren que un cliente construya y cargue un packfile grande. También evitan mover un puntero global de rama durante cada operación de commit.
Scion sigue admitiendo referencias, es decir, punteros como ramas y etiquetas. Sin embargo, Anthropic desaconseja la mayoría de las referencias más allá de la línea principal y las ramas de lanzamiento. El estado coordinado globalmente se vuelve cada vez más costoso a medida que aumentan las tasas de commits.
El sistema calcula la información de historial por separado como datos derivados. Construye índices dedicados para el historial de archivos, blame, copia y relaciones dentro del grafo de commits. Esos índices pueden generarse de inmediato o diferirse hasta que un consumidor los solicite.
Esta separación permite a Anthropic cambiar un índice sin cambiar cada cliente. También permite al servicio evitar calcular datos que ninguna tarea necesita.
El protocolo de checkout de Scion sigue el mismo principio. Los clientes solicitan árboles y objetos de archivo concretos en lugar de negociar una imagen completa de lo que ya poseen. Los servidores regionales de caché pueden satisfacer la mayoría de las solicitudes porque los objetos almacenados nunca cambian.
Un daemon en cada nodo de cómputo comparte objetos en caché entre trabajos locales. Los servicios regionales de caché se sitúan después entre esos daemons y los servidores Scion autoritativos. Anthropic aplica esta jerarquía para evitar que un fallo de la caché regional sobrecargue el servicio central.
Los checkouts dispersos solo solicitan directorios seleccionados. Los checkouts virtualizados crean archivos cuando un proceso los lee. Algunos trabajos omiten por completo el sistema de archivos y solicitan a la API un diff, un resultado de historial o una base de fusión.
Este diseño se asemeja a respuestas anteriores a la escala de los monorepositorios. Google describió Piper como parte de la infraestructura que admite una enorme base de código centralizada. Su análisis publicado sobre monorepositorios documentó las ventajas del código compartido, las dependencias unificadas y los cambios a nivel de toda la organización.
Meta tomó otra ruta con Sapling, un sistema que conserva conceptos familiares de control de código fuente distribuido mientras escala para su repositorio interno. Meta afirma que su servidor puede gestionar decenas de millones de archivos, commits y ramas. El diseño público de Sapling también admite repositorios Git y flujos de trabajo de desarrolladores locales.
Scion toma lecciones de ambas historias, pero su premisa principal es más limitada. El cliente dominante está siempre conectado, a menudo automatizado, y es poco probable que necesite un repositorio completo. Eso convierte al servidor en una base de datos de control de código fuente y un servicio de cómputo, en lugar de un socio de sincronización.
La contrapartida es la dependencia. Un cliente de Scion no puede reproducir el comportamiento offline completo de Git porque deliberadamente conserva menos datos y realiza menos operaciones localmente. Por tanto, un fallo de red o del servicio central tiene consecuencias distintas.
Los costes de migración también van más allá del cliente de línea de comandos. Anthropic tuvo que crear búsqueda de código, controles de identidad y acceso, integraciones de CI y Antique. Una empresa que adoptara el mismo diseño tendría que sustituir gran parte de su plataforma de desarrollo.
Eso explica por qué Scion no es una alternativa a Git de Anthropic para equipos convencionales. Es un sistema integrado verticalmente para una carga de trabajo excepcional.
Las fusiones más rápidas convierten la revisión de código en el problema más difícil
La cuestión sin resolver no es si Scion puede aceptar 30.000 cambios. Es si Anthropic puede preservar la rendición de cuentas a esa velocidad.
Anthropic afirma que cada cambio en Scion sigue recibiendo revisión humana. Ahora los revisores se centran en la intención de un cambio, en lugar de leer cada línea. Esa decisión responde al volumen, pero también desplaza la confianza hacia las pruebas, las explicaciones de los agentes y el análisis automatizado.
La revisión de intención pregunta si un cambio propuesto se ajusta a los objetivos y las reglas arquitectónicas del sistema. La revisión línea por línea pregunta si su implementación se comporta correctamente. Las comprobaciones automatizadas sólidas pueden conectar esos niveles, pero ninguna suite de pruebas captura todos los requisitos ocultos.
Anthropic reconoce que los ingenieros a menudo tuvieron que decirle «no» a Claude. Los agentes a veces seleccionaban patrones plausibles a nivel local que infringían restricciones de todo el sistema. Algunos componentes generados intentaban recorrer el registro de commits linealmente en lugar de consultar Antique para obtener un momento de fusión autoritativo.
La revisión adversarial creó otro modo de fallo. Claude podía responder a riesgos hipotéticos con validación y complejidad excesivas. Los ingenieros humanos tenían que decidir cuándo la programación defensiva dejaba de mejorar el sistema.
Estos ejemplos complican la afirmación simple de que mejores modelos producen directamente mejor software. Los agentes pueden encontrar optimizaciones valiosas y, al mismo tiempo, crear mecanismos innecesarios. Una alta producción amplifica ambos comportamientos.
Anthropic afirma que su equipo creó simulaciones, pruebas de fuzzing y límites de velocidad para Scion. El fuzzing proporciona entradas inesperadas para revelar defectos, mientras que las simulaciones herméticas reproducen el comportamiento de la infraestructura en entornos aislados. Estos controles aportan evidencia más sólida que los recuentos de fusiones por sí solos.
Aun así, el volumen de fusiones no es una métrica de calidad. Un cambio puede ser diminuto, experimental, generado, revertido o no estar relacionado con avances de cara al cliente. Treinta mil cambios diarios revelan una actividad extraordinaria, pero no demuestran de forma independiente fiabilidad ni valor empresarial.
Las reacciones públicas de desarrolladores se han centrado en esa distinción. En la discusión de Hacker News, algunos lectores cuestionaron si Anthropic debería replantearse su monorepo. Otros sostuvieron que la intención, la procedencia y la verificación continua importan más que las mecánicas tradicionales de los commits.
Un ingeniero de Anthropic que respondió en ese hilo defendió las herramientas coherentes y los cambios atómicos del monorepo. El mismo ingeniero aclaró que Scion bloquea los conflictos textuales, pero no puede eliminar los conflictos semánticos entre cambios simultáneos.
Un conflicto semántico ocurre cuando dos modificaciones válidas por separado producen un comportamiento incorrecto al combinarse. Un cambio podría modificar una función y actualizar sus llamadores, mientras otro añade simultáneamente un nuevo llamador. Los archivos pueden fusionarse limpiamente aunque el programa combinado sea incorrecto.
Las colas de fusión tradicionales reducen ese riesgo al probar un estado de repositorio propuesto antes de aceptar el siguiente lote. Anthropic afirma que un bloqueo global del repositorio se vuelve inviable cuando cientos o miles de cambios llegan durante la ejecución de una prueba.
La empresa ha trasladado su inversión hacia las pruebas posteriores a la fusión y previas al despliegue. Ese enfoque permite que el rendimiento del repositorio continúe mientras las comprobaciones determinan qué puede llegar a producción de forma segura.
Esta es la contrapartida central de rediseñar el control de código fuente en Anthropic. Scion elimina la serialización del control de código fuente, pero alguna forma de serialización sigue existiendo en el despliegue, la migración de datos o los puntos de decisión humana. El riesgo se desplaza en lugar de desaparecer.
Anthropic afirma que Claude puede resolver conflictos simultáneos más rápido de lo que las personas pueden identificarlos. Esa respuesta aborda la velocidad de reparación, no el coste de una interacción no detectada. La seguridad depende de cuán rápidamente la monitorización detecte un problema y de cuán eficazmente los sistemas lo aíslen o reviertan.
Los controles de acceso a nivel de directorio y las reglas de aprobación semántica ayudan. Según Anthropic, Antique puede distinguir un cambio que solo modifica comentarios de un cambio de lógica sensible. La atención humana puede entonces concentrarse en los cambios con mayores consecuencias.
La brecha de verificación restante es considerable. Anthropic no ha publicado tasas independientes de defectos, frecuencia de reversión, tendencias de incidentes ni la proporción de cambios escritos y revisados por agentes. Sin esas medidas, los observadores externos no pueden comparar las ganancias de rendimiento con el riesgo posterior.
La lección más útil para otros equipos no es perseguir el recuento de fusiones de Anthropic. Es medir todo el recorrido desde la especificación hasta el despliegue. Los indicadores útiles incluyen defectos que llegan a producción, latencia de revisión, cambios fallidos, reversiones, trabajo duplicado y tiempo dedicado a recuperar el contexto.
Un flujo de trabajo de IA personal puede ayudar a los ingenieros a preservar decisiones y procedencia a medida que los agentes generan más material. Sin embargo, el contexto almacenado solo ayuda cuando los equipos lo conectan con pruebas exigibles, propiedad y políticas de revisión.
Qué cambia a continuación el experimento de Anthropic con el control de código fuente
La siguiente fase pondrá a prueba si el desarrollo a escala de agentes se convierte en un modelo de ingeniería transferible o sigue siendo una costosa excepción de Anthropic.
La primera señal que conviene observar es la prometida explicación de Anthropic sobre Antique. El control de código fuente explica cómo se almacenan y recuperan los cambios, pero la revisión de código determina cómo la intención, la propiedad y la aprobación sobreviven a un volumen extremo.
Los detalles sobre el modelo de revisión de Antique reforzarían el argumento de Anthropic si muestran una procedencia clara y una intervención humana basada en el riesgo. El argumento se debilitaría si la revisión depende principalmente de resúmenes de modelos sin validación medible.
La segunda señal es la calidad del software a lo largo del tiempo. Las afirmaciones de Anthropic sobre infraestructura tendrán más peso si la empresa publica tasas de reversión, defectos que llegan a producción, incidentes de servicio u otras métricas de resultados junto con el rendimiento de las fusiones.
Una fiabilidad estable o en mejora respaldaría la idea de que los agentes pueden aumentar el volumen de cambios sin incrementar proporcionalmente el riesgo. Un aumento de regresiones o reparaciones de emergencia sugeriría que Scion aceleró la producción más rápido que la gobernanza.
La tercera señal es cómo responden las plataformas Git y las grandes organizaciones de ingeniería. La mayoría de las empresas no sustituirán Git, pero pueden adoptar API de metadatos del lado del servidor, espacios de trabajo virtualizados, revisión consciente del riesgo y mejor soporte para agentes paralelos.
Sapling de Meta ya demuestra una vía que mantiene la compatibilidad con flujos de trabajo conocidos. Scalar de Microsoft y las mejoras relacionadas con Git demuestran otra, al ampliar Git para grandes repositorios en lugar de sustituir su modelo de datos.
La propia Anthropic espera que estas presiones se extiendan en un plazo de seis a doce meses. Ese pronóstico es una valoración de la empresa, no una tendencia de mercado medida. Su relevancia depende de que otras organizaciones alcancen límites similares sin el acceso interno de Anthropic a tokens y la inusual concentración de uso de Claude.
Scion también introduce una dependencia estratégica que los competidores podrían evitar. Anthropic controla el modelo, el servicio de repositorio, la superficie de revisión, los agentes de observabilidad y el flujo de trabajo de despliegue. Esta integración acelera la iteración, pero hace que el entorno de desarrollo sea más difícil de reproducir o sustituir.
Para la mayoría de las organizaciones, Git seguirá siendo la opción sensata. Cuenta con amplia interoperabilidad, herramientas maduras, historial portable y resiliencia offline. La arquitectura de Scion solo se vuelve atractiva cuando el tráfico del repositorio ya ha desbordado esas ventajas.
El cambio más inmediato afecta a la gestión. Los líderes de ingeniería deben dejar de tratar el volumen de código generado como el objetivo. Una mayor producción solo crea valor cuando los equipos pueden revisarla, probarla, desplegarla, observarla y revertirla de forma segura.
Los desarrolladores también deberían esperar que su trabajo cambie. El relato de Anthropic da mayor peso al diseño de sistemas, las restricciones arquitectónicas, la evaluación y la negativa. El ingeniero define cada vez más el límite dentro del cual un agente puede avanzar rápidamente.
Por tanto, rediseñar el control de código fuente en Anthropic ofrece una advertencia junto a su historia de rendimiento. Cuando el código se vuelve barato, cada especificación débil, prueba ausente y límite de propiedad poco claro puede reproducirse a velocidad de máquina.
La pregunta útil no es si su equipo necesita Scion. Es si sus sistemas actuales de revisión, CI y conocimiento seguirían siendo fiables si los agentes produjeran diez veces más cambios el próximo trimestre. Mida esa capacidad ahora, identifique el primer control que falle y refuércelo antes de que llegue un mayor volumen de fusiones.
