El exfundador de GitHub recibió 17 millones de dólares de a16z, creando Git en la era de los Agentes

Escritor: Leo

¿Alguna vez has pensado que la programación podría cambiar por completo?
Los desarrolladores están pasando de simplemente usar herramientas de IA a ver la IA como una base completamente nueva para construir software.
Esto no es un pequeño ajuste, sino un cambio de paradigma radical.
Piensa en ello: esos conceptos centrales que siempre hemos dado por sentado—control de versiones, ramas, revisión de código, incluso la definición de “colaboración”—se están redefiniendo debido a los flujos de trabajo impulsados por agentes de IA.
Lo que más me sorprende es que Git, que usamos todos los días, en realidad fue diseñado para un flujo de trabajo de parches en listas de correo de hace 20 años, y ahora debe servir para escenarios donde humanos y múltiples agentes de IA trabajan simultáneamente.

Por eso, la noticia de que GitButler acaba de obtener 17 millones de dólares en una ronda de financiación Serie A me hizo detenerme a reflexionar seriamente.
Esta ronda fue liderada por a16z, con seguimiento de Fly Ventures y A Capital.
Lo más interesante es que Scott Chacon, CEO de GitButler, es uno de los cofundadores de GitHub y escribió ese libro casi obligatorio para todos los desarrolladores: “Pro Git”.
Una persona que ya logró un gran éxito en el campo del control de versiones, ¿por qué volver a la senda emprendedora y replantear un problema que parecía ya “resuelto”?
En el anuncio, lo dijo claramente: “No estamos construyendo un ‘mejor Git’, estamos construyendo la próxima generación de infraestructura para la construcción de software.”
Esta frase oculta una profunda visión sobre el futuro del desarrollo de software.

El estancamiento de Git en 20 años: una herramienta diseñada para listas de correo

Muchos no conocen bien el trasfondo histórico de Git.
Originalmente fue creado en 2005 por el equipo del núcleo de Linux, con una filosofía profundamente arraigada en la tradición Unix.
Scott mencionó en una entrevista un detalle interesante: el equipo central de Git nunca tuvo la intención de hacer una interfaz amigable para el usuario.
Siguen la filosofía Unix, construyendo una serie de “comandos de tubería” de bajo nivel, cada uno haciendo una cosa simple, y luego combinándolos con scripts en Perl para hacer lo que quieras.
Este diseño era muy razonable en su momento, asumiendo que solo expertos técnicos, como el comunidad del núcleo de Linux, usarían esta herramienta.

Luego, todos sabemos qué pasó.
Un desarrollador llamado Pasquy escribió algunos scripts en Perl que envolvían Git con una interfaz unificada, es decir, los comandos CLI que usamos ahora.
Estos scripts se volvieron cada vez más populares y, finalmente, se integraron en el núcleo de Git, formando lo que llamamos la “capa de porcelana” (porcelain).
Curiosamente, estos comandos no han cambiado mucho desde 2005-2006.
Originalmente escritos en Perl, luego reescritos en C, pero la lógica central y la interfaz de usuario permanecen casi iguales.
Scott dice que cuando escribió la primera edición de “Pro Git” en 2009, esas mismas órdenes todavía funcionaban tal cual.

Esa estabilidad tiene su lado positivo.
El equipo de Git valora mucho la compatibilidad hacia atrás y no quiere eliminar funciones existentes, por miedo a romper flujos de trabajo actuales.
Pero esto también trae un problema fundamental: las suposiciones originales con las que se diseñó Git ya están muy desfasadas respecto a las prácticas modernas de desarrollo de software.
Git fue pensado para enviar parches por listas de correo.
En esa época, los desarrolladores modificaban localmente, generaban un parche, lo enviaban por email, y el mantenedor revisaba y decidía si aceptarlo.
Todo ese proceso era asincrónico, basado en texto y de un solo hilo.

¿Y ahora?
Tenemos integración continua, despliegue continuo, equipos distribuidos en tiempo real, herramientas de revisión de código, pipelines automatizados de pruebas y despliegues.
Y lo más importante: ahora hay agentes de IA escribiendo código a gran escala.
Scott hizo una observación que me impresionó:
“Estamos enseñando a un grupo de agentes de IA a usar una herramienta diseñada para parches en listas de correo.”
Esa disonancia es como poner un Tesla en una carretera diseñada para carruajes.

La filosofía Unix de Git trae otro problema: intenta servir a dos públicos, la máquina y el humano, con una misma interfaz.
Por ejemplo, si ejecutas “git branch”, por defecto solo obtienes una lista de ramas, sin interfaz de usuario.
Esto se debe a que Git necesita que la salida sea legible para humanos y también parseable por otros programas.
Este compromiso resulta en que Git no es muy amigable para humanos, ni muy optimizado para programas.
Aunque algunos comandos ofrecen la opción “–porcelain” para salida legible por máquinas, no es la norma y muchos comandos ni siquiera la tienen.

Nuevos desafíos en la era de agentes de IA: un directorio de trabajo ya no basta

Cuando la IA empieza a participar masivamente en la programación, las limitaciones de Git se vuelven aún más evidentes.
Yo mismo he estado probando trabajar con múltiples agentes de IA simultáneamente y he visto que el diseño básico de Git—un desarrollador, una rama, un flujo de trabajo lineal—ya no funciona.
Los desarrolladores modernos no trabajan de forma lineal.
Puedes tener varios agentes en paralelo: uno arreglando un bug en la interfaz, otro optimizando consultas en la base de datos, otro actualizando documentación.
Pero el sistema de índice de Git colapsa en estos escenarios paralelos, porque asume que tu copia local representa una modificación única y atómica del repositorio.

La solución tradicional es usar worktrees, crear múltiples copias del repositorio para tareas paralelas.
Pero eso trae nuevos problemas: si tienes cinco agentes trabajando, necesitas cinco copias completas del directorio.
Aunque Git ha optimizado el almacenamiento, esto implica mucha duplicación de archivos y uso de espacio en disco.
Más importante aún, estos agentes están completamente aislados, no ven lo que hacen los otros hasta que terminan y tratan de fusionar, momento en el que los conflictos pueden ser muy costosos de resolver.

GitButler propone una solución: ramas paralelas (parallel branches).
Una idea brillante.
Son como ramas normales, pero puedes tener varias abiertas al mismo tiempo.
Puedes aprovechar los beneficios de los worktrees (aislamiento lógico) sin copiar todos los archivos.
Todos los agentes operan en el mismo directorio de trabajo, pero sus cambios se asignan a diferentes “ramas virtuales”.
Scott describió en una entrevista un escenario que me impresionó:
Dos agentes trabajan simultáneamente, ambos quieren editar el mismo archivo, pero sus cambios son incompatibles.
¿Qué pasa?
Un agente automáticamente apila su rama sobre la otra y continúa trabajando, haciendo commits en su pila.
Este manejo inteligente de conflictos es casi imposible en un flujo de trabajo Git tradicional.

Me gustó mucho un experimento que hizo el equipo de GitButler, aunque finalmente no lo adoptaron.
Intentaron que los agentes tuvieran un canal de chat para comunicarse sobre lo que estaban haciendo.
Scott dijo que esa función parecía muy genial: podían ver las conversaciones entre agentes, y estaban muy entusiasmados en lanzarla.
Pero tras muchas pruebas, descubrieron que no ayudaba mucho.
Los agentes, al detectar que otros estaban modificando un archivo, automáticamente deducían la razón y ajustaban su estrategia.
No necesitaban comunicación explícita, porque esa comunicación añadía sobrecarga y ralentizaba el proceso.
Este hallazgo fue muy revelador: no podemos simplemente aplicar los modos de colaboración humana a los agentes.
Los agentes tienen su propia forma de trabajar.

Rediseñando la interfaz: para humanos, agentes y scripts

El CLI de GitButler, lanzado recientemente, me llamó mucho la atención.
No es solo un envoltorio de Git, sino una reconsideración profunda de cómo deben diseñarse las herramientas de línea de comandos.
Scott mencionó un dato interesante: aproximadamente el 80% de los desarrolladores todavía usan la línea de comandos para Git, aunque existen muchas interfaces gráficas.
La razón es simple: la mayoría de las GUIs solo envuelven los comandos de Git en una interfaz gráfica, sin agregar funcionalidad, y en muchos casos hacen que la operación sea más lenta.
Si sabes qué comando necesitas, escribirlo directamente suele ser más rápido.

Pero el CLI de GitButler es diferente.
Ofrece diferentes formatos de salida para distintos escenarios.
Si ejecutas un comando normal, te da una salida optimizada, legible para humanos, con sugerencias y avisos.
Si añades “–json”, te entrega datos estructurados en JSON, fáciles de analizar con scripts.
Están considerando agregar “–markdown” para optimizar la salida para agentes, ya que el formato markdown es más fácil de inyectar en su contexto.

Lo más interesante es que basan el diseño en la observación del comportamiento de los agentes.
Descubrieron que, aunque ofrecen “–json”, los agentes prefieren usar la salida legible y luego canalizarla a jq o scripts en Python.
Otra cosa que notaron: después de ejecutar comandos que modifican el estado, los agentes casi siempre hacen un “git status” inmediatamente.
Por eso, en GitButler agregaron la opción “–status-after” a todos los comandos de modificación, para mostrar el estado automáticamente tras la operación.
Este enfoque, que va en contra de la filosofía Unix clásica y no es muy adecuado para scripts, funciona perfectamente para los agentes.

También están explorando cómo incluir más contexto en la salida para los agentes.
Por ejemplo, en los mensajes de salida, incluir instrucciones como “si quieres hacer esto, ejecuta este comando”.
No es para humanos, que lo encontrarían redundante, sino para los agentes, que así pueden decidir más rápido qué hacer.
Scott dijo que esto plantea una cuestión de UX muy interesante: tratar a los agentes como una “nueva categoría de usuario”, con necesidades y comportamientos muy diferentes a los humanos.

El cambio fundamental en el desarrollo de software: de escribir código a escribir especificaciones

En la entrevista, Scott compartió una idea que me hizo reflexionar:
Los mejores ingenieros de software en el futuro quizás no sean los que escriben el código más limpio, sino los que mejor comunican, escriben y describen.
Suena contraintuitivo, porque muchos elegimos programar para evitar tratar con personas, y en cambio interactuar con máquinas.
Pero, pensándolo bien, esta tendencia tiene mucho sentido.

Cuando los agentes de IA pueden generar código eficientemente, el cuello de botella ya no es la implementación, sino la capacidad de describir claramente lo que quieres.
Scott comparte su flujo de trabajo: ahora pasa la mayor parte del tiempo escribiendo especificaciones detalladas de cómo debe funcionar una función.
Cada vez que necesita tomar una decisión de diseño, le pide a la IA que implemente según la especificación, prueba el resultado, y si hay problemas, ajusta la especificación y vuelve a pedirle a la IA que reimplante.
Este ciclo puede ser muy rápido, porque no tiene que escribir todo el código él mismo.

Lo hermoso de este método es que permite hacer “mostrar y contar” (show and tell).
Tradicionalmente, si quieres validar una idea, tienes que escribir un documento técnico detallado y convencer a tu equipo de que lo lea y dé feedback.
Pero, por muy detallado que sea, un prototipo funcional es mucho más claro.
Ahora puedes generar rápidamente un prototipo, que el equipo puede experimentar, y luego iterar basado en su feedback.
Esto acelera mucho el ciclo de idea a validación.

Pero también trae nuevos desafíos.
El cuello de botella en la colaboración pasa de “¿puedo implementar esto?” a “¿podemos ponernos de acuerdo en qué queremos?”.
Scott dice que muchos desarrolladores, especialmente los que creen que son muy inteligentes, piensan que no necesitan explicar lo que hacen, que el código es la mejor documentación.
Pero en la era de la IA, esa actitud ya no funciona.
Debes poder expresar claramente tu intención, escribir especificaciones que tanto humanos como IA puedan entender.
La escritura se vuelve una habilidad superpoder.

Eso me lleva a pensar en el futuro de la revisión de código.
Scott planteó una pregunta aguda: si le preguntas a la mayoría de los ingenieros, ¿realmente leen todo un PR?
¿Analizan línea por línea?
¿Lo prueban localmente?
La mayoría solo lo revisa superficialmente, confirma que no hay errores obvios, y aprueba.
No es por irresponsabilidad, sino porque una revisión exhaustiva cuesta mucho y a menudo no vale la pena.
Pero los agentes de IA podrían cambiar las reglas del juego.
Son muy buenos revisando cada línea, ejecutando tests, detectando problemas potenciales.
No se cansan, no se aburren, mantienen estándares consistentes.
Así, los humanos pueden centrarse en aspectos de alto nivel: ¿esto cumple con la visión del producto? ¿resuelve necesidades reales? ¿la arquitectura es adecuada?
Los detalles de implementación, errores sutiles y bugs potenciales, pueden ser revisados por IA.

PR y Issues: la colaboración que lleva 20 años sin evolucionar, necesita un cambio

El sistema de Pull Requests de GitHub se ha convertido en el estándar para colaboración en código abierto, pero Scott cree que tiene problemas fundamentales.
PR está basado en ramas, no en parches.
Esto genera una gran cantidad de “spam” en los commits: “arreglé un bug pequeño”, “olvidé agregar este archivo”, etc.
En el modo PR, lo importante es toda la rama, no cada commit individual.
Por eso, la calidad de los mensajes de commit no se cuida mucho, y la descripción del PR es clave, pero generalmente se pierde tras el merge.

En la era de listas de correo, esto no era problema.
Cada parche tenía un mensaje cuidadosamente escrito, que servía como la descripción del PR.
La revisión era basada en parches, y la calidad del parche y del mensaje estaban relacionadas.
Pero en GitHub, perdimos esa restricción.
Scott piensa que la revisión debería volver a un modelo basado en parches, pero aprovechando las herramientas modernas.
La revisión debería ser local, permitiendo ejecutar código y hacer pruebas.
Los agentes pueden ayudar a correr tests, marcar problemas potenciales, y tú solo te enfocas en lo que realmente requiere juicio humano.

Otra idea interesante es la comunicación en equipo.
Scott dice que uno de los mayores problemas en desarrollo de software es la comunicación en tiempo real.
Si tú modificas un archivo y yo también, generalmente solo nos damos cuenta al fusionar, y uno de los dos debe hacer la mayor parte del trabajo de merge.
¿Y si pudiéramos saber en tiempo real qué está haciendo el otro?
Para humanos, esa comunicación en tiempo real puede ser demasiado costosa y molesta.
Pero para los agentes, no.
Pueden usar su tiempo libre para comunicarse entre ellos, entender qué están haciendo, detectar conflictos potenciales, o ajustar su estrategia para evitarlos.

El sistema de metadatos que explora GitButler también es muy interesante.
Quieren poder adjuntar registros de conversaciones, procesos de pensamiento de los agentes, y contexto relevante a commits o ramas.
Actualmente, Git tiene muy poca capacidad para soportar estos metadatos.
Pero esa información puede ser muy valiosa para entender decisiones, procesos mentales, etc.
El problema es el volumen de datos.
Scott mencionó que, incluso solo almacenando texto, estos metadatos pueden crecer rápidamente.
Por eso, están usando técnicas de grandes repositorios, como los que usan equipos como Chrome o Microsoft Office, para gestionar esa escala de datos.

Mis reflexiones sobre esta transformación

Tras escuchar la historia de GitButler y la entrevista con Scott, tengo varias ideas profundas.
El desarrollo de software está atravesando un cambio de paradigma radical, y la infraestructura básica, como los sistemas de control de versiones, debe evolucionar.
La filosofía de Git, que fue avanzada hace 20 años, ahora se ha convertido en una limitación.
No necesitamos un “mejor Git”, sino una infraestructura rediseñada para los flujos de trabajo modernos y la era de la IA.

Lo que más me resonó fue la reflexión de Scott sobre “el punto lógico final”.
Dice que, en emprendimientos de aprendizaje de idiomas, muchos ven la traducción en tiempo real como el fin del aprendizaje del idioma.
Pero él argumenta que, incluso con un traductor perfecto, aún necesitas usar un traductor, y esa experiencia no es tan buena como comunicarse en el mismo idioma.
En Japón, pasó una semana usando traductores, y aunque eran excelentes, la experiencia seguía siendo pobre.
No quieres construir relaciones profundas o colaborar en proyectos complejos usando traductores.
Lo mismo aplica para la programación.
Por muy poderosa que sea la IA, no puede reemplazar completamente el juicio, la creatividad y la comunicación humanas.

Sobre el futuro de GitHub, la opinión de Scott me parece muy sensata.
La mayor fortaleza de GitHub es su base de usuarios, y su mayor debilidad es que, como gran corporación, le cuesta adaptarse rápidamente.
El sector entero busca el “próximo GitHub”, pero Scott dice que esa pregunta quizás está mal formulada.
GitHub no es “el próximo” de nada; creó un nuevo modo de colaboración.
Y en el futuro, seguramente aparecerá un modo de colaboración completamente diferente, que aún no podemos imaginar.

Creo que el valor de GitButler no solo está en sus funciones concretas, sino en su forma de pensar.
Cuestionan esas suposiciones que damos por sentadas:
¿Por qué solo se puede trabajar en una rama a la vez?
¿Por qué los commits deben ser lineales?
¿Por qué agentes y humanos usan la misma interfaz?
¿Por qué la colaboración pasa por PR y issues?
Este pensamiento desde los primeros principios es justo lo que necesitamos en esta era de cambios rápidos.

También me doy cuenta de que, como desarrolladores, debemos adquirir nuevas habilidades.
Escribir especificaciones claras, comunicar ideas efectivamente, entender cómo trabajan los agentes de IA—esto puede ser más importante que solo programar.
Para muchos, será un reto, especialmente para quienes eligieron programar para evitar tratar con personas.
Pero también es una oportunidad para liberarnos de los detalles técnicos y enfocarnos en tareas más creativas: definir problemas, diseñar soluciones, hacer decisiones de peso.

La financiación de 17 millones de dólares de GitButler es solo el comienzo.
Estoy seguro de que en los próximos años veremos más intentos de repensar la infraestructura del desarrollo de software.
Control de versiones, revisión de código, gestión de proyectos, pruebas, despliegues—todas estas herramientas fueron diseñadas en una era anterior a la IA y necesitan ser reevaluadas.
Los desarrolladores y equipos que adopten primero estos nuevos paradigmas tendrán una ventaja enorme en esta transformación.

Al final, el desarrollo de software será más sobre comunicación, colaboración y toma de decisiones, y menos sobre sintaxis y detalles de implementación.
Puede que esto incomode a algunos programadores tradicionales, pero creo que es algo positivo.
Hace que programar sea más cercano a resolver problemas, en lugar de estar atrapados en detalles técnicos.
Cuando ya no tengamos que recordar comandos complejos de Git, ni resolver conflictos manualmente, ni dedicar horas a código repetitivo, podremos concentrarnos en lo que realmente importa: entender las necesidades del usuario, diseñar soluciones elegantes y crear productos valiosos.
Eso es el núcleo del desarrollo de software, y en esa dirección GitButler busca ayudarnos a volver.