El software se construye entre commits

• DeltaDB es un nuevo tipo de sistema de control de versiones que versiona en conjunto las conversaciones con agentes y los árboles de trabajo que los agentes editaron
• Git está organizado en torno a commits individuales y no fue diseñado para manejar, junto con los cambios de código, las conversaciones continuas que ocurren mientras el código sigue cambiando
• DeltaDB registra no solo los commits, sino todas las operaciones que ocurren durante el trabajo como un flujo detallado de deltas, y asigna a cada delta un identificador estable
• Los mensajes y las ediciones que esos mensajes produjeron se registran lado a lado, y varias personas y agentes pueden editar simultáneamente el mismo archivo desde distintas máquinas
• La colaboración puede darse de forma más directa dentro de la conversación y del árbol de trabajo mientras el código se está creando, en lugar de depender de un proceso de revisión posterior a los commits y al push

---

Contexto y planteamiento del problema

• El equipo de Zed no estaba acostumbrado al modelo de pull requests, y había construido confianza y entendimiento compartido trabajando juntos en el mismo árbol de trabajo y discutiendo mientras escribían código
• GitHub solo permite hablar sobre el código después de hacer commit y push, pero en el equipo de Zed las conversaciones importantes normalmente ya habían terminado antes de ese momento
• Zed comenzó en 2021 con la intención de superar las limitaciones del commit, creando primero un editor a la altura de los mejores desarrolladores del mundo y luego ofreciendo dentro de él una mejor forma de colaborar
• Un problema que llevaban mucho tiempo pensando en el contexto de la colaboración entre personas se volvió todavía más importante al colaborar con agentes
• La conversación que genera código se está convirtiendo cada vez más en la verdadera fuente del software, y esa conversación debe poder referenciar y ser referenciada por un código que evoluciona continuamente
• Git está organizado alrededor de commits individuales, por lo que no fue diseñado para sostener esta conexión entre conversaciones persistentes y cambios continuos en el código

DeltaDB y el siguiente paso

• No todos los commits, sino todas las operaciones

  • DeltaDB divide el trabajo en un flujo detallado de deltas y, a diferencia de Git, que guarda snapshots por commit, registra todas las operaciones entre commits
  • Como cada delta tiene un identificador estable, es posible señalar momentos específicos del proceso de evolución incluso mientras el código sigue cambiando
  • El árbol de trabajo se versiona como el propio proceso de cambio, junto con la conversación que impulsa esas transformaciones
  • Los mensajes y las ediciones que generan se registran lado a lado y no quedan separados
  • DeltaDB incorpora árboles de trabajo replicados sin conflictos, de modo que varias personas y agentes pueden editar al mismo tiempo el mismo archivo desde distintas máquinas
  • Los archivos son archivos reales; los agentes trabajan en ellos a través de la terminal y los usuarios pueden montar todo el árbol de trabajo en disco cuando necesiten usar sus propias herramientas

• El código fuente ahora es conversación fuente

  • Como las referencias quedan fijadas a deltas y no a números de línea, se mantienen incluso si el código se desplaza más abajo
  • Desde cualquier línea de una conversación pasada se puede saltar al código en su estado actual o al código tal como lo había escrito el agente en ese momento
  • Desde cualquier línea de código se puede encontrar la conversación que creó ese código y todas las conversaciones posteriores que lo tocaron
  • Los agentes también pueden usar esta información para recuperar el contexto de fondo del código que están modificando
  • Un agente puede incluso invocar al agente que trabajó antes sobre ese código para preguntarle por qué fue escrito de esa manera

• No debería hacer falta hacer commit para colaborar

  • El objetivo es que la conversación con agentes sea la única conversación necesaria para colaborar
  • Los miembros del equipo pueden sumarse mientras el trabajo aún está en curso, hablar con el agente que realizó la tarea y dejar comentarios durante el proceso
  • No hace falta esperar primero a que alguien haga commit y push para poder participar
  • Los pull requests, los hilos de revisión y los comentarios en línea eran procedimientos para volver a adjuntar la discusión al código después, porque el código y la discusión estaban en lugares distintos
  • Si el código y la discusión están en el mismo lugar, esos procedimientos desaparecen
  • Git y CI se quedan con el papel de ejecutar verificaciones y conectarse con el mundo exterior, sin convertirse en el lugar donde la colaboración ocurre por obligación

• Siguiente paso

  • El software ahora toma forma no en los commits, sino en la conversación
  • DeltaDB es un sistema de control de versiones para eso, y estará disponible para usuarios iniciales en unas semanas
  • Si quieres probarlo antes, puedes anotarte en la lista de espera

[GN⁺]

Comentarios de Hacker News

• El trabajo entre commits es una sopa desordenada, así que aunque lo mires no le sirve a nadie. Reescribe el historial con git rebase para que cada commit sea pequeño y atómico, y para que la historia que cuentan los commits explique por qué quedó con su forma actual
  No importa realmente en qué orden cronológico ocurrió. Estoy de acuerdo en que revisar pull requests llega demasiado tarde, pero el problema es que los pull requests están diseñados para revisar de una vez el resultado completo de la rama, así que es difícil hacer revisión de commits individuales. La solución no debería ser compartir todo el ruido, sino fomentar commits pequeños y atómicos para poder revisar el trabajo inicial antes de que se termine una función o corrección

  • Viendo los comentarios aquí y mi red profesional, la gente suele dividirse en dos bandos. Uno usa Git como una especie de guardado automático tosco y luego aplasta todo al fusionar; el otro prefiere commits atómicos totalmente funcionales y bien ordenados
    En mi experiencia, el 1 es más común, quizá porque GitHub naturalmente apoya mejor esa forma de trabajo y porque los commits acumulativos pueden resolver parte de los problemas del 2. Si tuviera que elegir, creo que el 1 tiene mucho más sentido
  • ¿No es eso un problema de GitHub y no de herramientas como Phabricator o Gerrit?
  • Sea una sopa desordenada o no, mientras el disco o el costo no sean problema, me parece bien que alguien—probablemente un agente—pueda ver lo que hice
    No tengo una postura tan firme, pero creo que los agentes prefieren información adicional, aunque para algunas personas sea ruido
  • Ya esperaba este tipo de respuesta. Al leer el artículo recordé la decepción que siempre me da ver la misma actitud cada vez que se habla de control de versiones
    Demasiada gente descarta el historial con demasiada facilidad para que se vea “limpio”. No tiene sentido, pero curiosamente encaja con cierta lógica típica de algunos programadores
    Mi forma de trabajar es hacer commits frecuentes, decenas de veces al día. Un commit es un registro de lo que pasó, y quiero que quede la mayor cantidad posible de ese registro. Varias veces git bisect me señaló un commit pequeño, de una sola línea, que parecía no tener nada malo, y así encontró un bug sutil que solo se descubrió mucho después
    Para mí, el control de código fuente está precisamente para encontrar ese tipo de cosas. Si hubiera tenido que revisar cada línea de un commit grande, esos problemas habrían sido mucho más dolorosos
    Por eso de verdad no entiendo cuando la gente junta a propósito todos los commits del tamaño de un PR y desecha la única parte de verdad útil del control de versiones. Como hay muchos en el mismo bando que el comentario padre, el plan del autor de llevar un registro más detallado parece que tendrá una lucha difícil
  • La forma en que usas los commits suena parecida a cómo yo uso PRs apilados en el trabajo
    Es difícil imponer una buena higiene de commits a nivel de equipo, pero curiosamente a nivel de PR la gente sí suele cooperar bastante para escribir buenas explicaciones y mantener limpios los grupos de cambios

• Esto suena como autocommits frecuentes con menos confianza en Git. Git puede manejar autocommits frecuentes perfectamente
  Si quieres conservar la “conversación” de esos autocommits en distintos momentos mientras los enrollas en commits superiores más “limpios”, basta con usar de vez en cuando git merge --no-ff y luego enfocarte en los commits superiores con herramientas como --first-parent en vez de en los commits de “conversación”
  El backend de Git ya tiene mucha optimización de base de datos delta en Git pack y otras herramientas; de hecho, lo que quizá necesite algo de trabajo es el frontend de Git—principalmente --first-parent—y la enorme cantidad de interfaces de Git “primero/solo mapa de metro”. Mucha gente siente que ese diagrama es feo, confuso y desagradable, así que debería haber más interfaces con drill-down que correspondan a --first-parent

  • Yo también hago eso. Normalmente no veo los commits de la rama, pero ahí siguen si los necesito. git blame también se puede configurar para usar --first-parent

• Estoy de acuerdo con “el software se construye entre commits”, pero no con que “DeltaDB capture todo el trabajo entre cada commit”
  Para empezar, se siente intrusivo. Tampoco quiero un grabador de pantalla funcionando 24 horas mientras trabajo. No es que esté mal que mis errores queden expuestos, pero si estoy haciendo bien mi trabajo, el valor que produzco queda en los commits, y eso se siente mucho menos intrusivo
  Segundo, uso varias herramientas y no quiero integrar todo eso en una base de datos rara. Si en algún punto todo termina en “un proceso externo hizo algo”, ¿qué sentido tiene capturarlo todo? Está bien que Zed pueda integrar muchas cosas, pero eso no significa que yo quiera usar todo lo que Zed integra. La última vez que revisé, si usabas Claude Code en Zed con ACP, ni siquiera podías rebobinar y editar mensajes anteriores
  Por último, personalmente creo que ya hemos perdido la esencia de los commits. La mayoría crea un conjunto arbitrario e ilimitado de cambios, luego ejecuta git commit, ese paquete de cambios se revisa como un gran bloque y después los commits se aplastan. No es el fin del mundo, pero un commit bien trabajado a mano es realmente excelente. Si ejecutas git blame en un proyecto que obliga esta forma de trabajar, vas a entender enseguida a qué me refiero
  Cosas como DeltaDB solo refuerzan y consolidan la costumbre de agrupar commits sin mucho cuidado. Si quieres saber qué pasó, ahora se supone que debes reproducir de forma voyeurista la conversación que el usuario tuvo con un LLM
  El último punto es interesante, pero también irritante. No logré convencer a compañeros de documentar cambios y motivaciones solo porque fuera una buena práctica de ingeniería útil para el equipo, pero todos sí están dispuestos a explicárselo a un LLM. En gran parte es porque el LLM lo necesita para hacer el trabajo, pero me parece interesante cuánto hacen ahora para satisfacer al LLM cosas que antes no habrían hecho. De pronto, cosas que extrañamente no estaban documentadas terminan documentadas en CLAUDE.md

• El código que escribes entre commits es tu proceso de pensamiento. Escribes código, lo borras y lo vuelves a escribir mientras piensas
  El código que termina en un commit está escrito para que otras personas lo entiendan, y es el resultado del proceso de escribir para pensar. No quiero que mis pensamientos queden serializados, versionados y accesibles públicamente
  https://www.nature.com/articles/s44222-025-00323-4

  • Había el mismo problema incluso con JJ. No quiero que todo lo que pasa entre commits quede bajo control de versiones
    Tampoco estoy seguro de que todos los estados intermedios entre commits sean relevantes o útiles. Pero siento que soy minoría
  • Por eso uso rebase antes del PR, y no me gusta squash. Dentro de 2 años no vas a recordar por qué escribiste ese código de esa forma, y para entender un bug e identificar una situación de la cerca de Chesterton, lo único que queda son el delta y el historial de commits
    Si haces squash, lo único que queda como contexto es un bloque de 400 líneas que escribiste “de una sola vez” y la solicitud de funcionalidad a la que fue asignado ese código. No ayuda en nada
    La peor persona que conocí escribía un módulo nuevo y no hacía check-in de nada hasta que medio funcionaba. Creo que también estaba relacionado con una autoestima frágil que lo llevaba a corregir a escondidas los bugs de su propio código sin decir primero que estaban ahí. Escribía código críptico que dejaba a la vista la ley de Kernighan, y para hacer eso le faltaban como 10 años más de experiencia. Presumía que su código era “poderoso”, y eso no era un halago sino una señal de alerta. Encontré bugs varias veces en el código de commits iniciales. De verdad dan ganas de decirle: por favor deja algo de rastro
    No necesitas confesar que probaste cualquier cosa hasta encontrar el problema. Después de descubrir que sí se puede llegar al punto B, basta con construir la historia deseada de A a B. Puedes reordenar los commits de la forma en que los habrías escrito si hubieras sabido desde el principio exactamente qué había que hacer. Puedes descartar el 90% del código que escribiste y borraste enseguida, o cualquier cosa que no sostenga esa narrativa
    En la aplicación de la ley existe algo llamado construcción paralela. Puedes saber que un sospechoso es culpable por hechos que no serían admisibles en juicio, pero tienes que redescubrir esos mismos hechos siguiendo el procedimiento. Como asegurar la basura el día de recolección, entrevistar a los vecinos, reunir suficiente evidencia circunstancial para obtener una orden de cateo y luego volver a encontrar esa evidencia
  • Parece que estaban pensando sobre todo en agentes de IA. Es una idea interesante que ya había visto antes, y es curioso cómo todo el mundo quiere reinventar algo para la IA
    Pero soy escéptico porque siento que bastaría con crear un archivo de texto y poner referencias a commits. Tampoco entiendo por qué no usar Fossil. Como es una base de datos SQLite, ya puedes empaquetar ahí lo que quieras, y trae integradas todo tipo de funciones para referenciar commits
  • Soy escéptico con la parte colaborativa, pero entiendo la intención porque suena a una función para clientes empresariales
  • Estoy completamente de acuerdo. La sensación de vigilancia es muy desagradable. Sobre todo la parte de “DeltaDB divide el trabajo en un flujo de deltas granulares. Mientras que Git captura el snapshot de cada commit, DeltaDB captura todo el trabajo entre medio y le da a cada parte un identificador estable”
    Había pensado probar Zed ahora que dicen que tiene keymap de emacs, pero ya no. Esto es una función demasiado invasiva, y no quiero para nada que un colega revise, pulsación por pulsación, todas las ediciones intermedias que hice antes de llegar a un commit público para revisión
    Antes de abrir un PR, a veces pulo un poco el historial de commits en magit para que quede más lineal y fácil de digerir. Corrijo descripciones o junto commits adyacentes. Pero esta función básicamente tira por la borda todo ese aspecto del trabajo y dice: “colega, trágate esta manguera contra incendios de deltas y disfrútala”
    ¿Qué se supone que significa la frase “Lo que realmente queremos es simple. Que la conversación con el agente sea la única conversación que necesites”? No, está mal

• Me da una mala espina pensar que es inevitable que Anthropic u OpenAI adquieran Zed. La idea es demasiado buena y el software también es demasiado bueno

  • El harness de programación de Zed es mucho mejor que Claude Code, pero como usa directamente la API de Claude, sale mucho más caro. Si entra al mismo portafolio de productos, podría llegar a definir toda la categoría
  • ¿Y por qué detenerse en Zed? El billón de dólares en inversión que juntaron las empresas de IA era nominalmente para centros de datos, pero si los costos suben y los plazos de finalización se salen del rango normal de un plan de negocios, resulta más eficiente usar ese dinero en otra cosa. Con 1 billón de dólares puedes comprar lo que quieras
  • Parece que adonde quieren llegar Anthropic y OpenAI ya no hay editores. En lo personal, preferiría mejores herramientas de código en modo solo lectura, o incluso el regreso de UML

• En este momento hay muchísimas startups tempranas compitiendo en este espacio. En las últimas semanas, mientras hacía entrevistas, hablé con al menos dos
  Para que estas herramientas logren consolidarse y tener éxito a gran escala, la competencia va a ser feroz. Aun así, no puedo quitarme la idea de que todo esto parece habilitar un nivel de vigilancia de desarrolladores que me resulta muy incómodo

  • Si un gerente se pasa el tiempo observando absolutamente todas las pulsaciones de teclas de todos los desarrolladores a su cargo, entonces es que no tiene trabajo real ni problemas de negocio importantes a los que prestar atención

• Los commits son útiles precisamente porque ya fueron depurados. Lo que pasa entre medio es prueba y error, intentar algo y borrar callejones sin salida, y la mayor parte debería descartarse
  Si guardas todos los cambios y mensajes del agente, lo único que haces es dejar esa basura ahí para siempre

• Google probablemente lleva haciendo esto como desde hace 10 años con citc. No sé cuándo Gemini va a aprovecharlo de verdad, pero Google tiene de facto un registro casi completo de casi todos sus desarrolladores, prácticamente a nivel de Ctrl-S, desde hace al menos 10 años
  Si Gemini se ve tonto ahora, es solo porque están ahorrando en asignación de recursos de cómputo
  0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

• Aquí no entiendo cuál es la propuesta de valor. He visto a varias empresas proponer más o menos este tipo de función, pero ninguna ha presentado una razón convincente de por qué esta tecnología debería existir.

  • Me parece interesante que tu experiencia y tu flujo de trabajo sean tan distintos a los míos. Esta es una función que afirma resolver un problema real que vivo todos los días.
    Nuestra empresa es completamente remota y la mayoría de mis colegas no vive cerca de mí. Nos vemos por videollamada unas cuantas veces al día, pero nos comunicamos principalmente por Slack.
    También vamos bastante adelantados en la curva de adopción de agentes LLM para escribir buen código. Gracias a modelos buenos y a barandillas de seguridad muy buenas en cierto harness de programación, hoy en día los LLM escriben la mayor parte de nuestro código.
    Normalmente, en un día tomo un ticket, se lo paso al LLM y empezamos a resolver el problema juntos. Tomamos decisiones de arquitectura, hacemos un plan y lo ejecutamos. La función que desplegué más recientemente tuvo un costo de tokens de 19 dólares, y en su mejor momento el LLM siguió trabajando unos 30 minutos sin intervención mía.
    Solo cuando no estoy seguro de qué dirección es mejor publico una pregunta en el chat del equipo para pedir la opinión de mis colegas. Pero muchos tickets se terminan de forma completamente autónoma.
    Después abro un PR y publico el enlace del PR en Slack para pedir revisión, y es en ese momento cuando mis colegas ven la implementación por primera vez. A veces mis colegas hacen preguntas. Como los comentarios de GitHub no sirven muy bien para conversaciones rápidas en tiempo real, muchas veces ponen sus preguntas en un hilo de Slack en vez de en los comentarios del PR.
    Las respuestas a esas preguntas están en el registro de chat con el LLM que tengo en mi laptop, pero no hay una forma fácil de mostrárselas a mis colegas. Así que termino jugando al teléfono descompuesto: copio la pregunta de mi colega desde Slack al chat con el LLM, y luego vuelvo a pegar la respuesta.
    La idea de que mi colega, el LLM y yo podamos participar más fácilmente en la misma conversación me resulta muy atractiva.
    Eso no significa que el equipo de Zed vaya en la dirección correcta, y también podría ser mejor que nuestro equipo trabajara de otra manera. Pero el enfoque actual es demasiado “exitoso” como para que haya mucha presión organizacional por cambiarlo.

• El trabajo de un equipo de software es aprender en colaboración modelos que funcionen de manera efectiva en algún dominio. Expresamos esos modelos y ese aprendizaje en código, pruebas y documentación relacionada.
  Por eso, por un lado estoy completamente de acuerdo en que los pull requests y la revisión de código dañan fatalmente este proceso, pero al mismo tiempo me incomoda la idea de crear de inmediato otro procedimiento y otro conjunto de entregables secundarios que nos distraigan. Todo eso debería hacerse visible en la codebase.
  No en algo separado. No en mensajes de commit ni en un montón de ADR. Si la codebase no puede explicar por sí sola, de forma completa, el qué y el porqué tanto a humanos como a IA, entonces ha fracasado, y pasaremos la vida creando más procesos para gestionar ese fracaso.

  • El branching barato para funciones y experimentos, la capacidad de revertir rápidamente commits específicos y leer el mensaje del commit de la última vez que cambió una línea de código son cosas enormemente importantes, y son cosas que los sistemas de control de versiones distribuidos hicieron posibles.
    El estado actual del código por sí solo no es suficiente para el desarrollo moderno de software.