¿Por qué seguimos asumiendo que el sistema de control de versiones que usamos hoy sirve para el flujo de trabajo que viene? Llevamos 20 años con Git como estándar absoluto y cada vez que alguien propone algo diferente lo miramos con escepticismo. Entendible. Pero hay algo que me empezó a picar en la cabeza desde que los agentes de IA empezaron a escribir código en serio: Git fue diseñado para que los humanos puedan leer diffs. ¿Y si ese supuesto fundamental ya no aplica?
El sucesor de Git y el control de versiones en la era de los agentes
La semana pasada se anunció una ronda de $17M para construir "lo que viene después de Git". El pitch no es nuevo en su forma — cada dos o tres años aparece alguien con esta promesa. Pijul, Jujutsu, Fossil, Mercurial en su momento. Los conozco todos. Y siempre reaccioné igual: interesante técnicamente, pero Git ya ganó, no hay forma de moverlo.
Esta vez paré en seco.
No porque la tecnología subyacente sea necesariamente revolucionaria. Sino porque el timing me parece diferente. Estamos justo en el momento donde los agentes de código — Copilot, Cursor, Claude con herramientas, lo que sea que estés usando — están empezando a hacer commits reales en repositorios reales. No snippets, no sugerencias: commits firmados, PRs abiertas, código que llega a producción sin que un humano lo haya tipado letra por letra.
Y ahí es donde Git, tal como existe hoy, empieza a mostrar sus límites. No por limitaciones técnicas en el sentido clásico. Sino porque cada abstracción de Git — el diff, el commit message, el blame, el log — asume que hay un humano al otro lado queriendo entender qué pasó.
¿Qué pasa cuando nadie quiere leer ese diff porque lo escribió una máquina en 200ms?
El problema real: Git como interfaz humano-a-humano
Cuando metí el historial completo del kernel de Linux en una base de datos, una de las cosas que más me llamó la atención fue la consistencia narrativa de los commits. Linus, los maintainers, la comunidad — hay una cultura de explicar el porqué en cada commit. Es casi una tradición oral digital. Cada mensaje es una conversación con el futuro.
Esa cultura existe porque Git fue construido alrededor de una suposición básica: los humanos van a leer esto. El diff es para que yo entienda qué cambió. El commit message es para que vos, en seis meses, entiendas por qué lo cambié. El git blame es para que alguien pueda rastrear decisiones.
Ahora pensá en un agente de IA que en una hora puede hacer 400 commits de refactoring. ¿Quién lee esos 400 diffs? ¿Quién verifica que cada uno tiene sentido? ¿El git blame de un archivo refactoreado por un agente te dice algo útil?
El problema no es que los agentes escriban mal código. El problema es que Git como sistema de auditabilidad y colaboración fue pensado para la velocidad humana de producción de cambios. Y esa velocidad se está multiplicando por órdenes de magnitud.
Ya tuve que pensar en esto cuando trabajé con algunos proyectos donde la IA genera código que después es difícil de auditar. La supply chain de software se complica cuando no podés rastrear la intención detrás de cada cambio. Git te da qué cambió. No necesariamente por qué, y mucho menos si era correcto hacerlo.
Lo que proponen y por qué tiene sentido (aunque me cueste admitirlo)
El pitch de esta ronda de $17M gira alrededor de algunas ideas concretas:
Control de versiones semántico, no textual. En lugar de trackear cambios línea por línea, trackear cambios en la estructura del programa — AST-aware version control. El sistema entiende que moviste una función, no que borraste 40 líneas y agregaste 40 líneas similares en otro lugar.
Historial verificable por agentes. Si un agente hace un cambio, el sistema puede responder preguntas como "¿este cambio afecta la invariante X?" sin que un humano tenga que leer el diff completo.
Merge sin conflictos en la mayoría de los casos. Esto ya lo intenta Jujutsu y Pijul con sus enfoques de patches commutables. La idea es que si entendés la semántica del cambio, podés resolver muchos conflictos automáticamente.
// Git tradicional ve esto como conflicto:
// <<<<<<< HEAD
// function calcularTotal(items: Item[]): number {
// return items.reduce((acc, item) => acc + item.precio, 0);
// }
// =======
// function calcularTotal(productos: Producto[]): number {
// return productos.reduce((total, p) => total + p.costo, 0);
// }
// >>>>>>> feature/refactor-naming
// Un sistema semántico podría entender:
// - Ambos cambiaron el nombre del parámetro
// - Ambos cambiaron el nombre de la variable acumuladora
// - La lógica es idéntica
// - Resolución automática: elegir una convención de naming
// Resultado: merge sin intervención humana
Grafos de intención, no solo de cambios. Cada modificación viene acompañada de metadata que el agente (o el humano) puede generar: ¿por qué se hizo este cambio? ¿qué test lo valida? ¿qué issue lo motiva? No como texto libre en un commit message, sino como datos estructurados consultables.
Esto último me parece lo más interesante. No es solo "mejor Git", es pensar el control de versiones como una base de datos de decisiones de ingeniería, no como un log de cambios de archivos.
Los errores que veo venir igual
Todo esto suena bien en el pitch deck. Pero conozco este juego.
El primer problema es la adopción. Git no ganó porque sea técnicamente superior a todo lo que existía. Ganó porque GitHub lo adoptó, porque Linux lo usaba, porque el network effect se volvió imposible de ignorar. Tener mejor tecnología no alcanza. Igual que con el tooling de Linux, a veces el ecosistema tarda una década en ponerse de acuerdo en algo que técnicamente debería ser obvio.
El segundo problema es la complejidad operacional. Git es complejo, sí. Pero es predecible. Cualquiera que haya trabajado con sistemas de merge semántico sabe que cuando fallan, fallan de maneras muy difíciles de debuggear. Un conflicto de texto es feo pero entendible. Un conflicto semántico mal resuelto puede introducir un bug silencioso que Git textual hubiera detectado como conflicto explícito.
El tercero, y este me preocupa más: ¿quién audita al auditor? Si el sistema de control de versiones está diseñado para agentes que toman decisiones automáticas, ¿cómo sé que el propio sistema de versionado no está siendo influenciado o comprometido? Ya es difícil auditar dependencias de software hoy. Agregar una capa de inteligencia en el VCS me genera el mismo escozor que cuando analizo dependencias de APIs de IA críticas sin fallback real.
La confianza en infraestructura no se construye con un pitch deck y $17M. Se construye con años de que la cosa no explote en producción.
Lo que sí creo que va a cambiar (sí o sí)
Acá me pongo más directo: Git en su forma actual va a cambiar. No necesariamente va a morir ni a ser reemplazado por completo. Pero la interfaz principal de interacción con el historial de código va a dejar de ser git log y git diff leídos por humanos.
Ya está pasando. Los IDEs con IA no te muestran el diff, te explican el diff. Los code review tools están empezando a usar LLMs para resumir PRs. El git blame lo está reemplazando la pregunta directa al chat de tu IDE.
Lo que viene probablemente no sea "matar Git" sino construir una capa encima — o al lado — que hable el lenguaje de los agentes. Metadata estructurada de intención. Queries semánticas sobre el historial. Verificación automática de invariantes en cada commit.
# El git log del futuro probablemente no sea esto:
git log --oneline --graph
# Sino algo más parecido a una query estructurada:
# ¿Qué cambios tocaron la lógica de autenticación en los últimos 30 días?
# ¿Cuáles fueron generados por agentes? ¿Cuáles revisados por humanos?
# ¿Alguno cambió el comportamiento sin un test que lo valide?
# La respuesta no sería una lista de commits
# sino un análisis de intenciones y riesgos
Ahora, ¿eso justifica $17M y un reemplazo total de Git? No estoy seguro. Me parece que hay un camino donde Git evoluciona con extensiones (los sparse indexes, el partial clone, el commit-graph ya muestran que puede adaptarse) y otro donde algo nuevo lo flanquea en los casos de uso de alta velocidad de agentes.
Cuál gana depende menos de la tecnología y más de quién construye el primer caso de uso irresistible. Igual que pasó con entrenar modelos grandes — no fue la teoría lo que convenció a la gente, fue el momento en que algo que parecía imposible funcionó en hardware que ya tenías.
FAQ: Preguntas frecuentes sobre el sucesor de Git y el control de versiones
¿Git va a desaparecer en los próximos años?
No en el corto plazo. Git tiene 20 años de adoption, tooling, cultura y network effect. Lo más probable es una coexistencia: Git para flujos humanos tradicionales y nuevas herramientas para flujos de agentes intensivos. La migración masiva, si ocurre, lleva una década mínimo.
¿Qué es el control de versiones semántico y en qué se diferencia de Git?
Git trackea cambios a nivel de texto — líneas agregadas y eliminadas. El control de versiones semántico entiende la estructura del programa: sabe que moviste una función, renombraste una variable o cambiaste la firma de un método, independientemente de cómo se vea el diff textual. Esto permite merges más inteligentes y búsquedas por intención en lugar de por contenido de archivo.
¿Jujutsu (jj) es el sucesor de Git que ya está disponible?
Jujutsu es la apuesta más madura y usable hoy. Desarrollado por Google, corre sobre el backend de Git (compatible con repos existentes) pero ofrece una interfaz y modelo mental diferente, con first-class support para cambios de trabajo en progreso y un sistema de merge más predecible. No es "el sucesor" definitivo pero es la opción más pragmática para explorar hoy sin romper tu flujo de trabajo.
¿Por qué los agentes de IA hacen que Git sea problemático?
Git fue diseñado para la velocidad humana de producción de código. Un desarrollador hace algunos commits por día; un agente puede hacer cientos por hora. El modelo de review, el significado del commit message, la utilidad del git blame — todo asume que hay un humano que produce y otro que lee. Cuando ambos roles los toma una máquina a alta velocidad, las abstracciones de Git dejan de tener el mismo valor.
¿Vale la pena migrar mi equipo a una alternativa a Git ahora mismo?
En la mayoría de los casos, no. A menos que tengas un pain point muy específico (repositorios monorepo gigantes donde Git escala mal, o un flujo de trabajo con muchos merges paralelos donde los conflictos son un problema real), el costo de migración supera los beneficios actuales. Lo que sí tiene sentido es experimentar con Jujutsu en proyectos personales o secundarios para entender hacia dónde va el ecosistema.
¿El anuncio de $17M significa que esta empresa va a ganar el mercado?
Difícilmente. La historia del control de versiones está llena de alternativas técnicamente superiores que no lograron masa crítica. $17M es suficiente para construir algo real y conseguir early adopters, pero no alcanza para cambiar el comportamiento de millones de developers. Lo que puede cambiar el juego es que alguna plataforma grande (GitHub, GitLab, un IDE dominante) adopte el enfoque. Sin eso, es una herramienta de nicho interesante.
Git no va a morir. Pero va a tener que crecer.
La verdad es que después de 30 años mirando tecnología, aprendí a desconfiar tanto de los que dicen "esto nunca va a cambiar" como de los que dicen "esto va a cambiarlo todo". La realidad suele ser más lenta y más rara que cualquiera de las dos predicciones.
Lo que me parece cierto es esto: el flujo de trabajo de desarrollo de software está cambiando más rápido ahora que en cualquier otro momento desde que apareció el open source. Los agentes no son una feature de los IDEs — son un cambio en quién produce el código. Y si cambia quién produce, tiene sentido que cambien las herramientas de coordinación.
Git puede adaptarse. Ya lo hizo antes. O puede aparecer algo que lo flanquee en los casos de uso nuevos sin necesitar reemplazarlo en los viejos. Lo que me cuesta imaginar es que en cinco años el flujo de trabajo con agentes intensivos use exactamente las mismas abstracciones que Git usa hoy.
Y eso me parece una pregunta más interesante que si esta empresa en particular va a ganar o no con sus $17M.
¿Vos ya estás pensando en cómo va a cambiar tu flujo de control de versiones cuando los agentes sean parte fija del equipo? Me interesa saber cómo lo están manejando otros. Dejame un mensaje.
Este artículo fue publicado originalmente en juanchi.dev
Top comments (0)