El reemplazo de Git de Anthropic: cuando el volumen de código supera la revisión humana

Cuando la herramienta pensada para el ritmo humano se encuentra con el ritmo de la máquina

Según informaciones que se remontan al relato de este cambio hecho por Simon Willison, Anthropic ha construido su propio reemplazo de Git. El detonante no fue un error ni un incidente de seguridad. Fue el volumen. La tasa de cambios que llegaban a la base de código de la empresa subió con fuerza, y para mayo de 2026 promediaba unas 2.500 peticiones por periodo, una carga para la que el control de versiones convencional no estaba diseñado.

Es fácil archivar esto entre las herramientas internas y seguir adelante. Sería un error. Git es una de las piezas de software más trascendentales jamás escritas, y está construido sobre un conjunto de suposiciones acerca de cómo cambia el código que ahora se están incumpliendo en la práctica.

Las suposiciones sobre las que se construyó Git

El diseño de Git codifica una creencia sobre el comportamiento humano. Los cambios llegan a un ritmo que una persona puede mirar. Una rama representa una intención que dura lo suficiente para ser nombrada. La historia es valiosa, así que no se tira nada. Un mantenedor puede leer un diff y formarse una opinión antes de fusionarlo.

Cada una de esas suposiciones se debilita cuando los agentes escriben código.

Los agentes no se cansan, así que producen cambios de forma continua en lugar de en lotes del tamaño de una jornada. No sostienen una intención durante días, así que las ramas se vuelven tan efímeras que nombrarlas es una sobrecarga. Generan muchísimos más diffs de los que un revisor humano puede leer de forma significativa, lo que hace que el paso de revisión, en torno al cual está organizado todo el flujo de trabajo de Git, se convierta en un cuello de botella en lugar de una salvaguarda.

El resultado es un sistema que opera muy fuera de su envolvente de diseño mientras todos insisten en que nada ha cambiado. El repositorio sigue funcionando. El proceso que lo rodea deja de significar lo que significaba.

Qué se rompe de verdad primero

La preocupación ingenua es el almacenamiento. Resulta ser lo de menos. El disco es barato y Git comprime bien.

La primera víctima real es la revisión. Una pull request cuyo diff de 4.000 líneas generó un agente es técnicamente revisable y en la práctica no lo es. Los revisores hacen lo que los humanos siempre hacen bajo sobrecarga: hojean, confían en el resumen, aprueban. La revisión sobrevive como ceremonia mientras pierde su función, lo que es peor que eliminarla, porque la ceremonia crea una confianza falsa.

La segunda víctima es la identidad. La historia de Git es un registro de quién decidió qué y cuándo. Cuando la mayoría de los commits los redacta un modelo que actúa sobre un prompt, la historia sigue teniendo nombres, pero los nombres ya no responden a la pregunta para la que existe la historia. No puedes preguntarle a un agente por qué eligió un enfoque hace seis semanas, porque no lo recuerda, y el mensaje del commit lo generó el mismo sistema que tomó la decisión.

La tercera víctima es la propia rama. Crear ramas es barato en Git y caro en atención humana. Si las ramas se multiplican más rápido de lo que nadie puede atenderlas, obtienes una acumulación de intenciones que nadie sostiene, lo cual es un fallo distinto de un conflicto de fusión y más difícil de ver.

Por qué un reemplazo es más que un Git más rápido

Si el problema fuera el rendimiento, la solución sería un servidor más rápido. Que Anthropic construya algo nuevo sugiere que el problema es estructural.

Un sistema de control de versiones optimizado para cambios al ritmo de la máquina se vería distinto en aspectos concretos. Supondría que la mayoría de los cambios son efímeros y deberían ser baratos de crear y de descartar. Trataría el diff como un resumen y no como el artefacto, y adjuntaría a cada cambio una intención legible por máquina para que un agente pueda encontrarla después sin leer el código. Estaría construido para la recuperación, no para la arqueología.

También tendría que responder a una pregunta que Git nunca tuvo que responder. Git supone que el artefacto interesante es el estado final del código. En un flujo de trabajo impulsado por agentes, el artefacto interesante suele ser el razonamiento que produjo un cambio y las comprobaciones que lo validaron. Si eso vive fuera del control de versiones, entonces el control de versiones solo registra la mitad de la historia.

El registro en el que nadie piensa hasta que lo necesita

El control de versiones no es solo un sistema de archivo. Es el sustrato de la facturación, el cumplimiento y la respuesta a incidentes. Los auditores quieren saber quién cambió qué y cuándo. Las industrias reguladas quieren un registro defendible que resista una revisión. Los equipos de seguridad reconstruyen líneas de tiempo a partir de los commits.

Si la respuesta honesta a esas preguntas pasa a ser "lo hizo un agente, en una rama que ya no existe, y el razonamiento vivía en una ventana de contexto ya descartada", entonces el registro tiene un agujero. Los agujeros en los registros son precisamente lo que las auditorías están hechas para encontrar, y una herramienta que los produzca sin que nadie lo note sería un problema serio mucho antes de convertirse en un escándalo.

La señal más amplia

Anthropic no es la única que siente esta presión, y las versiones reducidas de la misma historia ya son visibles en otros lugares. GitHub rediseñó hace poco su API de historial de estrellas de repositorio para que los datos de tendencia vuelvan en 24 peticiones en lugar de unas 2.500, sin exigir un trabajo de base de datos ilimitado ni exponer a usuarios individuales que dieron estrella. GitHub también lanzó un clasificador de detección de secretos consciente del contexto que elevó la tasa de aceptación de hallazgos reales en un 11,5 por ciento y recortó el tiempo medio de escaneo en un 86 por ciento.

Ambos son respuestas a la misma condición de fondo: el volumen de código en el mundo va en aumento, y las herramientas construidas cuando los humanos eran los únicos autores empiezan a mostrar su edad. La detección de secretos es un buen ejemplo. El riesgo de una credencial filtrada escala con la cantidad de código que se escribe, así que un sistema que bastaba con tasas de producción humanas deja de bastar con tasas de producción de agentes, aunque nada de su diseño haya cambiado.

La parte que nadie quiere decir en voz alta

Hay una versión de esta historia en la que la IA hace que los equipos de software sean mucho más productivos, las herramientas se ponen a la altura y todo el mundo está bien.

Hay otra versión en la que el volumen de código generado supera la capacidad humana de entenderlo, y la industria acaba con repositorios que ninguna persona sola comprende, sostenidos por pruebas que nadie escribió y revisiones que nadie realizó. El indicio de esa versión no es un colapso. Es una deriva lenta en la que la base de código sigue funcionando y el número de personas que entienden por qué no deja de bajar.

Reemplazar Git es, en esa luz, un síntoma que merece atención. Significa que una de las empresas más cuidadosas del sector decidió que la herramienta estándar se había vuelto un lastre justo en la capa donde se rastrea la corrección. No es una admisión pequeña. Es una señal de que a la infraestructura del software se le pide cambiar más rápido de lo que sus suposiciones pueden seguir.

La respuesta práctica para todos los demás no tiene nada de romántico. Mide cuánto de tu código lo escribió una máquina. Observa si tu paso de revisión sigue cambiando algo. Fíjate en si tu historia todavía puede responder al porqué. Son preguntas baratas, y las respuestas te dirán si necesitas una herramienta nueva o solo un hábito nuevo.