Anthropic, la empresa que desarrolla Claude, contó el 13 de octubre en su blog de ingeniería que ha dejado de usar Git en su repositorio principal. Lo ha sustituido por Scion, un sistema de control de versiones propio. El motivo: desde que Claude escribe buena parte del código, las fusiones de cambios en ese repositorio pasaron de unas 2,500 al día en mayo a más de 30,000 en septiembre, y la infraestructura montada sobre Git no daba abasto. Siete personas hicieron la migración en cinco meses, con Claude escribiendo la mayor parte del código.
Como muchas grandes empresas, Anthropic guarda casi todo su código en un único repositorio gigante, un monorepo. Su historial ya ronda los 100 GB y una copia de trabajo comprimida pasa de 25 GB. Cada día, los sistemas de integración continua descargan el código unos 25 millones de veces: si cada descarga fuera completa, serían más de 600 petabytes diarios. Para aguantarlo, el equipo recurrió a todos los trucos conocidos de Git, como los clones superficiales, dispersos y parciales o las instantáneas precargadas, y llegó a mantener varios cientos de espejos internos del repositorio. Con cada salto en el ritmo de fusiones, esos espejos eran más difíciles de operar.
El problema de fondo, según Anthropic, es de diseño. Git nació para trabajar de forma distribuida y sin conexión: cada desarrollador tiene una copia completa y sincroniza cuando quiere. En Anthropic casi todos los clientes son agentes o tareas automáticas que están siempre conectados, así que usaban Git como un sistema centralizado, justo para lo que no fue pensado.
Claves de Scion
- El servidor hace el trabajo pesado. Los clientes están siempre conectados y el servidor calcula el historial, quién cambió cada línea (blame), los commits, las fusiones y los rebases. El cliente, llamado
scn, solo guarda una caché limitada y coloca los archivos en el disco. Como todo se consulta por API, muchas tareas ni siquiera necesitan una copia local del repositorio. - Cambios en lugar de árboles. La unidad de trabajo es el changeset, una entrada en un registro de escritura anticipada. En vez de apuntar al árbol completo de archivos, como hace un commit de Git, lista solo los archivos que cambian respecto a su padre. Los commits se hacen en el servidor, así que no hay nada que subir con push, y mover una rama es una operación atómica sobre una sola fila de la base de datos Spanner de Google.
- Tres niveles de servicio. Un proceso en cada máquina (
scion-daemon), una caché regional en memoria (scion-cache) y el servidor de referencia (scion-server). Las descargas se pueden reanudar y no hay grandes paquetes de objetos ni mantenimiento del repositorio. - Los resultados. Según Anthropic, Scion consume unas 200 veces menos CPU y memoria que los espejos de Git a los que sustituye, las descargas de código para CI y para investigación tardan segundos en lugar de minutos, la integración continua ganó un 25 % de capacidad de CPU y cada nivel de caché acierta más del 99 % de las veces.
- No llegó solo. En los mismos cinco meses, el equipo construyó Antique, una herramienta de revisión de código cuyas reglas distinguen, por ejemplo, un cambio que solo toca comentarios de uno que toca lógica delicada. También hizo un buscador de código, permisos por carpeta y procesos automáticos para localizar y revertir el cambio que rompe algo.
- Claude como programador principal. Los ingenieros pusieron la arquitectura y los objetivos de escala, y Claude escribió la mayor parte del código. El equipo reconoce que a menudo tuvo que decirle «no» cuando complicaba de más una pieza o se saltaba una restricción del sistema. Claude reescribió la herramienta que importa el historial de Git a Scion, que ahora usa 20 veces menos memoria y es 4 veces más rápida.
Por qué importa
Git lleva más de veinte años como la herramienta común de todo el que programa, y rara vez se cuestiona. Que una empresa lo abandone no es nuevo: Google y Meta tienen sistemas propios desde hace tiempo. Lo llamativo es la causa. Aquí no fue el número de ingenieros, sino el volumen de código que producen los agentes de IA: multiplicar por doce las fusiones diarias en cuatro meses es algo que ningún equipo humano consigue contratando gente.
Es un adelanto de lo que puede pasarles a otros equipos a medida que los agentes escriben más código. Los cuellos de botella se desplazan a la revisión, a la integración continua y al propio control de versiones. Anthropic deja claro que su caso es extremo, con un presupuesto de uso de Claude muy por encima del de cualquier empresa normal. Aun así, la idea de un servidor que hace el trabajo y clientes ligeros siempre conectados puede acabar llegando a herramientas como GitHub o GitLab. Y el propio proyecto es un ejemplo de lo que ya pueden hacer equipos pequeños con agentes: siete personas reemplazaron una pieza central de su infraestructura en cinco meses.
Datos tomados del artículo de Anthropic. Cobertura: The Register y Slashdot. Portada: código en un monitor, foto de Markus Spiske, Wikimedia Commons, CC0 (recortada, con degradado).
Fuente: Anthropic, «Redesigning source control at Anthropic»