Anthropic y Scion: el diseño que Meta ya usaba en 2018

El diseño de Scion ya existía en Meta

El 13 de octubre de 2026, Anthropic publicó cómo su nuevo sistema de control de versiones, Scion, usa un concepto llamado "derived data" para acelerar operaciones como el blame: saber quién editó por última vez una línea de código. Un día después, un ingeniero que ayudó a construir Mononoke, el servidor de control de versiones de Meta, señaló que él ya había descrito ese mismo concepto en 2022, para un sistema que su equipo diseñó entre 2017 y 2018.

Para un founder, la noticia no es quién copió a quién. Es que la arquitectura de software de frontera empieza a comportarse como un commodity que los modelos replican a escala, y eso cambia cómo se acredita, se publica y se protege el trabajo de ingeniería.

Qué es Scion y por qué Anthropic dejó Git

El detonante fue el volumen. Según la cobertura de OfficeChai, Anthropic fusionaba unas 2.500 cambios por día en su repositorio principal en mayo de 2026; para septiembre esa cifra superaba los 30.000 diarios, un salto de más de doce veces en cuatro meses. El mismo medio reporta que la historia de la rama principal ronda los 100 GB y que una copia de trabajo comprimida supera los 25 GB, con unos 25 millones de checkouts diarios solo para CI.

Git está diseñado para que cada clon sea una copia completa y autónoma del repositorio. Ese supuesto funciona con humanos que trabajan a veces desconectados; se rompe cuando los clientes son agentes y trabajos automatizados que están en línea por definición.

La respuesta de Anthropic fue invertir el modelo: en Scion los commits, rebases y merges ocurren en el servidor, no hay push, y el cliente solo pide los archivos que necesita. Los resultados que reporta la compañía, según OfficeChai, son una huella de infraestructura 200 veces menor en CPU y memoria, checkouts que pasan de minutos a segundos y un 25% de capacidad de CPU liberada en el CI.

Todo eso lo construyó un equipo de siete ingenieros en cinco meses, junto con Antique (revisión de código), un buscador de código y una capa de permisos.

La acusación: "derived data" y el crédito que falta

El punto de fricción es técnico y muy específico. En el post original, el ingeniero reproduce dos textos casi calcados. Anthropic explica que un changeset solo registra lo que cambió y que, para responder quién editó una línea, Scion construye estructuras adicionales —blame, historial por ruta, skip lists— y llama a todo eso "derived data", calculado de forma recursiva a partir de los padres.

Su propia descripción de Mononoke, escrita en 2022, dice que movieron la representación amigable para diffs a "derived data (es decir, un índice)", que se computa de forma asíncrona fuera de la sección crítica, y que con eso el blame pasó de recorrer todo el repositorio a recorrer solo los commits que tocan el archivo. Mononoke llegó a tener ocho índices separados construidos sobre ese mismo mecanismo.

El autor es explícito: cree que el nivel de imitación va más allá de haber llegado a ideas parecidas. Señala que Sapling recibió crédito solo por "lecciones ganadas con esfuerzo" y que Mononoke no se menciona en absoluto, y califica esa omisión como algo que "roza el plagio". Aclara también que Anthropic sí cita a Piper de Google y a Sapling de Meta como precedentes de monorepos masivos.

Conviene separar el reclamo del hecho. Lo verificable es que Anthropic publicó su diseño y que un ingeniero que participó en Mononoke afirma que el concepto central ya estaba documentado por su equipo casi una década antes. La calificación de plagio es su opinión, no un fallo judicial.

Y no pide que Anthropic deje de usar la idea. Al contrario: dice que no tiene problema con que copien el diseño de Mononoke, y que precisamente por eso lo publicaron como código abierto.

El problema real: los modelos indexan el diseño que ya existe

La parte incómoda del post no es la queja, es el diagnóstico. Mononoke es open source y está en el set de entrenamiento de todos los modelos. Si le preguntas a un modelo por el prior art de Scion, va a señalar a Mononoke: el autor documenta que al consultar Opus 5.5 y GPT-6 Astra sobre antecedentes, ambos apuntaron de inmediato a las similitudes con Mononoke.

Ahí está el cambio de fondo. Un equipo de siete personas puede reconstruir en cinco meses un sistema que a Google y a Meta les llevó años y decenas de ingenieros, porque el conocimiento ya está indexado. La cobertura de HackerNoon resume el efecto: el costo de construir un sistema de control de versiones propio cayó un orden de magnitud, y con eso se debilita la regla no escrita de que nadie construye su propio VCS.

El riesgo para quien innova es simétrico. Si tu ventaja competitiva es una decisión de arquitectura, esa decisión puede ser absorbida por el próximo modelo que la lea, sin atribución y sin licencia.

Qué significa esto para tu startup

1. Publica tu arquitectura con fecha y autoría. Si tu equipo resolvió un problema difícil, escríbelo: un post de ingeniería, un ADR (Architecture Decision Record) fechado, un changelog técnico. No es marketing, es prueba de prioridad. El equipo de Mononoke pudo demostrar su autoría porque había dejado el diseño documentado y el código abierto. Si tu trabajo vive solo en un repositorio privado, no tienes forma de reclamar nada después.

2. Pide el prior art antes de adoptar una arquitectura que te propone un modelo. Cuando un asistente te entregue un diseño "nuevo", pregúntale explícitamente qué sistemas existentes resuelven lo mismo y en qué se diferencia. El propio autor muestra que los modelos conocen esos antecedentes y los mencionan cuando se les pregunta de frente. Adoptar sin ese chequeo es comprar deuda técnica con envoltorio de novedad.

3. No migres de Git si no tienes el problema de Anthropic. Anthropic dice explícitamente que Scion no es un reemplazo general de Git y que solo tiene sentido en monorepos gigantes con decenas de miles de ingenieros o enjambres de agentes. Para casi cualquier startup, la ruta sensata es la que la propia Anthropic recomienda al ecosistema: mantener Git como protocolo y mover el cómputo al servidor mediante APIs, con checkouts dispersos y virtuales. HackerNoon ubica ese umbral en organizaciones de más de 2.000 ingenieros o que fusionan más de 5.000 cambios diarios.

4. Revisa cuánto de tu código lo escribe un agente. El indicador que anticipa el problema no es la cantidad de empleados, sino la proporción de checkouts hechos por clientes no humanos. Si esa proporción ya pasó la mitad, tu infraestructura está pagando el costo de un modelo de clonado completo que nadie aprovecha.

Conclusión

Scion es un caso de estudio sobre escala, no sobre originalidad. Anthropic resolvió un problema real —30.000 merges diarios con siete ingenieros— y lo publicó con detalle, algo que Google y Meta nunca hicieron con Piper ni con Mononoke. Ese gesto tiene valor.

Pero el episodio deja una lección que aplica a cualquier equipo: cuando el conocimiento técnico está indexado y disponible para cualquiera, la atribución deja de ser una cortesía y pasa a ser infraestructura de confianza. Documentar lo que construyes, con fecha y con nombre, es hoy tan importante como construirlo.

Fuentes

• Anthropic's Scion is heavily inspired by Mononoke (fuente original)
• Redesigning source control at Anthropic
• Anthropic Builds In-house Version Of Git Called Scion After Code Merges Rise 12x In 4 Months
• AI Agents Are Killing the Git Client, Not Git: What Anthropic's Scion and Cursor's Origin Show