Les logiciels se fabriquent entre les commits

• DeltaDB est une nouvelle forme de système de gestion de versions qui versionne à la fois les conversations avec les agents et les worktrees qu’ils ont modifiés
• Git est structuré autour des commits individuels et n’a pas été conçu pour traiter ensemble la conversation continue et les changements de code pendant que celui-ci évolue
• DeltaDB enregistre non seulement les commits, mais aussi toutes les opérations effectuées pendant le travail sous forme d’un flux détaillé de deltas, et attribue à chaque delta un identifiant stable
• Les messages et les modifications produites par ces messages sont enregistrés côte à côte, et plusieurs personnes comme plusieurs agents peuvent éditer simultanément le même fichier depuis des machines différentes
• La collaboration peut se faire plus directement dans la conversation et dans le worktree pendant que le code se construit, plutôt qu’au travers d’un processus de revue après commit et push

---

Contexte et constat

• L’équipe de Zed n’était pas à l’aise avec le modèle des pull requests et a construit la confiance ainsi qu’une compréhension partagée en travaillant ensemble dans le même worktree, en discutant pendant l’écriture du code
• GitHub ne permet de parler du code qu’après commit et push, mais chez Zed les conversations importantes étaient généralement déjà terminées avant ce moment
• Zed a démarré en 2021 pour dépasser les limites du commit, avec l’idée de créer d’abord un éditeur à la hauteur des meilleurs développeurs du monde, puis d’y proposer une meilleure manière de collaborer
• Un problème mûrement réfléchi dans le contexte de la collaboration entre humains est devenu encore plus important avec la collaboration avec des agents
• La conversation qui génère le code devient de plus en plus la véritable source du logiciel, et cette conversation doit pouvoir se référer en permanence à un code qui évolue lui aussi continuellement
• Git étant structuré autour de commits individuels, il n’a pas été conçu pour relier cette conversation continue aux changements du code

DeltaDB et la suite

• Pas seulement tous les commits, mais toutes les opérations

  • DeltaDB découpe le travail en un flux détaillé de deltas et, contrairement à Git qui stocke des instantanés à chaque commit, enregistre toutes les opérations entre les commits
  • Chaque delta possède un identifiant stable, ce qui permet de désigner un moment précis de l’évolution même pendant que le code continue à changer
  • Le worktree est versionné dans son processus de transformation lui-même, avec la conversation qui guide ces changements
  • Les messages et les modifications qu’ils produisent sont enregistrés côte à côte sans être séparés
  • DeltaDB intègre des worktrees répliqués sans conflit, permettant à plusieurs personnes et agents d’éditer simultanément le même fichier depuis des machines différentes
  • Les fichiers restent de vrais fichiers, les agents travaillent dessus via le terminal, et l’utilisateur peut monter l’ensemble du worktree sur disque pour utiliser ses propres outils quand nécessaire

• Le code source devient désormais la conversation source

  • Comme les références sont ancrées aux deltas plutôt qu’aux numéros de ligne, elles restent valides même si le code se déplace plus bas
  • Depuis n’importe quelle ligne d’une conversation passée, on peut accéder soit au code dans son état actuel, soit au code tel qu’il était quand l’agent l’avait écrit
  • Depuis n’importe quelle ligne de code, on peut retrouver la conversation qui l’a produite ainsi que toutes les conversations qui l’ont ensuite modifié
  • Les agents peuvent eux aussi exploiter ces informations pour récupérer le contexte de fond du code qu’ils touchent
  • Un agent peut rappeler l’agent qui a précédemment travaillé sur ce code et lui demander pourquoi il a été écrit de cette manière

• Il ne devrait pas être nécessaire de commit pour collaborer

  • L’objectif est que la conversation avec les agents devienne la seule conversation nécessaire à la collaboration
  • Les membres de l’équipe peuvent intervenir alors que le travail est encore en cours, discuter avec l’agent qui l’a effectué et annoter le travail pendant son exécution
  • Ils n’ont pas besoin d’attendre d’abord un commit et un push pour participer
  • Les pull requests, review threads et commentaires inline étaient des procédures destinées à rattacher après coup la discussion au code, parce que code et discussion se trouvaient à des endroits différents
  • Quand code et discussion sont au même endroit, ces procédures disparaissent
  • Git et la CI restent cantonnés à l’exécution des vérifications et à la connexion avec le monde extérieur, sans devenir l’endroit où la collaboration est imposée

• La suite

  • Les logiciels prennent désormais forme non plus dans les commits, mais dans la conversation
  • DeltaDB est le système de gestion de versions conçu pour cela, et sera proposé aux premiers utilisateurs d’ici quelques semaines
  • Si vous voulez l’essayer en avant-première, vous pouvez vous inscrire sur la liste d’attente

[GN⁺]

Commentaires sur Hacker News

• Le travail entre les commits est une soupe désordonnée, donc même si on l’examine, ce n’est utile à personne. Avec git rebase, on réécrit l’historique pour que chaque commit soit petit et atomique, et pour que l’histoire racontée par les commits explique pourquoi on en est arrivé à la forme actuelle
  La chronologie exacte de ce qui s’est réellement passé n’a pas d’importance. Je suis d’accord pour dire que la revue de pull request arrive trop tard, mais le problème est que les pull requests sont conçues pour relire d’un coup le résultat de toute la branche, ce qui rend la revue de commits individuels difficile. La solution ne devrait pas être de partager tout le bruit, mais plutôt d’encourager des commits petits et atomiques afin de pouvoir relire le travail initial avant qu’une fonctionnalité ou un correctif soit terminé

  • À voir les commentaires ici et mon réseau pro, les gens se divisent grosso modo en deux camps. L’un utilise Git comme une sorte de sauvegarde automatique rugueuse, puis regroupe au moment de la fusion ; l’autre préfère des commits atomiques parfaitement fonctionnels et proprement préparés
    D’après mon expérience, le premier cas est plus courant, peut-être parce que GitHub le prend plus naturellement en charge et parce que les commits accumulés peuvent résoudre une partie des problèmes du second. S’il faut choisir, je trouve que la première approche a bien plus de sens
  • Ce n’est pas un problème d’outil comme Phabricator ou Gerrit, c’est juste un problème GitHub, non ?
  • Que ce soit une soupe désordonnée ou non, tant que le disque ou le coût ne posent pas problème, ça me va que quelqu’un — probablement un agent — puisse voir ce que j’ai fait
    Je n’en suis pas absolument certain, mais j’ai l’impression que les agents préfèrent plus d’informations, même si pour certaines personnes cela ressemble à du bruit
  • Je me doutais que ce genre de réaction arriverait. En lisant l’article, ça m’a rappelé ma déception chaque fois que je vois le même sentiment revenir dans les discussions sur le contrôle de version
    Beaucoup trop de gens jettent trop facilement l’historique pour qu’il paraisse « propre ». Ça n’a aucun sens, mais étonnamment, cela semble cohérent dans une certaine logique de programmeur assez répandue
    Ma façon de faire, c’est de commit très souvent, des dizaines de fois par jour. Un commit est l’enregistrement de ce qui s’est passé, et je veux qu’il en reste autant que possible. Plusieurs fois, git bisect m’a pointé vers un tout petit commit d’une seule ligne qui avait l’air parfaitement innocent, et m’a permis de retrouver un bug subtil découvert bien plus tard
    À mon avis, la gestion du code source est justement faite pour trouver ce genre de choses. Si j’avais dû fouiller chaque ligne de gros commits, ces problèmes auraient été bien plus pénibles
    Donc, voir des gens regrouper volontairement tous les commits d’une PR en un seul bloc et abandonner ce que je considère comme la seule partie vraiment utile du contrôle de version, ça me dépasse complètement. Comme il y a beaucoup de gens dans le camp du commentaire parent, le projet de l’auteur pour un historique plus détaillé risque d’être un combat difficile
  • La façon dont vous utilisez les commits ressemble à la manière dont j’utilise les PR empilées au travail
    Une bonne hygiène de commit est difficile à imposer à l’échelle d’une équipe, mais curieusement, au niveau des PR, les gens coopèrent assez volontiers pour écrire de bonnes explications et garder des ensembles de changements propres

• Ça ressemble à des auto-commits fréquents avec moins de confiance envers Git. Git gère très bien les auto-commits fréquents
  Si vous voulez enrouler ces auto-commits fréquents dans des commits de niveau supérieur plus « propres » tout en conservant la « conversation » des auto-commits point par point, il suffit d’utiliser parfois git merge --no-ff et de se concentrer sur les commits de niveau supérieur avec des outils comme --first-parent plutôt que sur les commits de « conversation »
  Le backend de Git intègre déjà beaucoup d’optimisations de base de données delta dans Git pack et d’autres outils ; l’endroit qui mériterait en réalité quelques retouches, c’est le frontend Git — surtout --first-parent — ainsi que les innombrables interfaces Git « plan de métro d’abord/exclusivement ». Beaucoup de gens trouvent ces plans de lignes laids, confus et désagréables, donc il faudrait davantage d’interfaces de drill-down correspondant à --first-parent

  • C’est aussi ce que je fais. En temps normal, je ne regarde pas les commits d’une branche, mais ils restent là si j’en ai besoin. On peut aussi configurer git blame pour utiliser --first-parent

• Je suis d’accord avec « le logiciel se construit entre les commits », mais pas avec « DeltaDB capture tout le travail entre chaque commit »
  D’abord, cela me semble intrusif. Je ne veux pas non plus d’un enregistreur d’écran qui tourne en continu pendant que je travaille. Ce n’est peut-être pas un mal que mes erreurs apparaissent, mais si je fais correctement mon travail, la valeur que j’ai produite se retrouve dans les commits, et cela me paraît bien moins intrusif
  Ensuite, j’utilise plusieurs outils, et je n’ai pas envie d’intégrer tout cela dans une base de données bizarre. Si, à un certain moment, on finit de toute façon par « un processus externe a fait quelque chose », à quoi bon tout capturer ? C’est bien que Zed puisse intégrer beaucoup de choses, mais ça ne veut pas dire que je vais utiliser tout ce qui est intégré à Zed. La dernière fois que j’ai vérifié, en utilisant Claude Code dans Zed via ACP, on ne pouvait même pas remonter et modifier les anciens messages
  Enfin, personnellement, je pense qu’on a déjà perdu l’essence même du commit. La plupart des gens fabriquent un paquet arbitraire et potentiellement illimité de changements, puis lancent git commit ; ce paquet de changements est ensuite relu comme un énorme bloc, puis les commits sont fusionnés. Ce n’est pas la fin du monde, mais un commit soigneusement façonné à la main, c’est vraiment excellent. Il suffit de lancer git blame sur un projet qui impose cette manière de faire pour comprendre tout de suite ce que je veux dire
  Des choses comme DeltaDB ne font que renforcer et figer l’habitude de regrouper les commits à la va-vite. Si vous voulez savoir ce qui s’est passé, il suffira désormais de rejouer de manière un peu voyeuriste la conversation entre l’utilisateur et le LLM
  Ce dernier point est intéressant, mais aussi agaçant. On n’arrivait pas à convaincre les gens de documenter leurs changements et leurs motivations au nom de bonnes pratiques d’ingénierie utiles à l’équipe, mais tout le monde est prêt à l’expliquer à un LLM. C’est en grande partie parce que le LLM en a besoin pour faire le travail, mais il est fascinant de voir combien de choses les gens font désormais pour satisfaire le LLM alors qu’ils ne les faisaient pas auparavant. Soudain, des choses étrangement non documentées se retrouvent documentées dans CLAUDE.md

• Le code écrit entre deux commits reflète mon processus de pensée. J’écris du code, je l’efface, puis je le réécris pour réfléchir
  Le code expédié dans un commit est rédigé pour être compris par les autres, et constitue le résultat du processus d’écriture utilisé pour penser. Je ne veux pas que mes pensées soient sérialisées, versionnées et rendues accessibles publiquement
  https://www.nature.com/articles/s44222-025-00323-4

  • Il y avait le même problème avec JJ. Je ne veux pas que tout ce qui se passe entre deux commits soit versionné
    Je ne suis même pas certain que tous les états intermédiaires entre deux commits soient pertinents ou utiles. Mais j’ai l’impression d’être minoritaire sur ce point
  • C’est pour ça que j’utilise rebase avant une PR, et que je n’aime pas squash. Dans deux ans, on ne se souviendra plus pourquoi ce code a été écrit ainsi, et pour comprendre un bug et identifier une situation de clôture de Chesterton, il ne reste que le delta et l’historique des commits
    Si on squash, il ne reste comme contexte que les 400 lignes de code que vous avez écrites « d’un coup » et la feature request à laquelle ce code a été attribué. Ça n’aide en rien
    La pire personne que j’aie vue écrivait un nouveau module sans rien check-in tant qu’il ne fonctionnait pas à peu près. Je pense que cela allait aussi avec un ego fragile qui corrigeait discrètement les bugs de son propre code sans jamais les reconnaître d’abord. Il écrivait du code ésotérique illustrant la loi de Kernighan, alors qu’il avait au moins dix ans de carrière de trop pour faire ce genre de chose. Il se vantait que son code soit « puissant », ce qui n’est pas un compliment mais un mauvais présage. J’ai trouvé des bugs à plusieurs reprises dans le code de ses premiers commits. Franchement, laissez au moins quelque chose
    Il n’est pas nécessaire d’avouer que vous avez tout essayé jusqu’à trouver le problème. Une fois que vous savez qu’il est possible d’aller au point B, il suffit de construire le récit souhaité entre A et B. Réorganisez les commits de la manière dont vous les auriez écrits si vous aviez su dès le départ exactement quoi faire. Vous pouvez jeter les 90 % de code que vous avez écrits puis immédiatement supprimés, ou tout ce qui ne soutient pas ce récit
    Dans l’application de la loi, il existe ce qu’on appelle la construction parallèle. On peut savoir qu’un suspect est coupable grâce à des faits irrecevables devant un tribunal, mais il faut redécouvrir ces mêmes faits en suivant la procédure. On récupère les déchets le jour du ramassage, on interroge les voisins, on rassemble assez d’indices circonstanciels pour obtenir un mandat de perquisition, puis on retrouve à nouveau ces preuves
  • Cela semble surtout pensé pour des agents IA. C’est une idée intéressante que j’avais déjà vue, et c’est amusant de voir tout le monde tenter de réinventer quelque chose pour l’IA
    Mais je reste sceptique, parce qu’on pourrait simplement créer un fichier texte et y mettre des références de commit. Je ne vois pas non plus pourquoi il ne suffirait pas d’utiliser Fossil. C’est une base de données SQLite, donc on peut déjà y regrouper ce qu’on veut, et elle intègre toutes sortes de fonctions permettant de référencer des commits
  • Je suis sceptique sur l’aspect collaboratif, mais je comprends l’intention, car cela ressemble à une fonctionnalité pour des clients entreprises
  • Tout à fait d’accord. L’aspect surveillance est extrêmement désagréable. Surtout le passage : « DeltaDB découpe le travail en un flux de deltas granulaires. Là où Git capture l’instantané de chaque commit, DeltaDB capture tout le travail entre les commits et attribue à chacun un identifiant stable »
    J’avais entendu dire que Zed avait désormais un keymap emacs, donc j’envisageais de l’essayer, mais plus maintenant. C’est une fonctionnalité bien trop intrusive, et je n’ai absolument aucune envie que des collègues examinent, frappe par frappe, toutes les éditions intermédiaires qui ont mené au commit que j’ai rendu public pour revue
    Avant d’ouvrir une PR, il m’arrive d’ajuster un peu l’historique des commits dans magit pour le rendre plus linéaire et plus digeste. Par exemple en corrigeant des descriptions ou en fusionnant des commits adjacents. Mais cette fonctionnalité jette purement et simplement tout un aspect de ce travail par la fenêtre et revient à dire : « Collègue, aspire ce tuyau d’incendie de deltas et régale-toi »
    La phrase « Ce que nous voulons vraiment est simple. Faire de la conversation avec les agents la seule conversation dont vous avez besoin » — qu’est-ce que cela veut dire exactement ? Non, c’est faux

• L’idée qu’Anthropic ou OpenAI rachète Zed me donne mal au ventre, car cela semble inévitable. L’idée est trop bonne et le logiciel est trop bon

  • Le harnais de codage de Zed est bien meilleur que Claude Code, mais comme il utilise directement l’API Claude, c’est aussi bien plus cher. Si cela entrait dans la même gamme de produits, cela pourrait devenir un produit qui définit toute une catégorie
  • Pourquoi s’arrêter à Zed ? Les 1 000 milliards de dollars d’investissements accumulés par les entreprises d’IA étaient théoriquement destinés aux datacenters, mais si les coûts augmentent et que les calendriers d’achèvement dépassent l’horizon normal d’un business plan, il est plus efficace d’utiliser cet argent ailleurs. Avec 1 000 milliards de dollars, on peut acheter à peu près n’importe quoi
  • Là où Anthropic ou OpenAI veulent aller, il semble qu’il n’y ait déjà plus d’éditeur. Personnellement, j’aimerais plutôt de meilleurs outils de lecture seule du code, ou bien le retour d’UML

• Il y a énormément de startups en phase de démarrage qui se battent sur ce créneau en ce moment. Rien qu’au cours des dernières semaines, en passant des entretiens, j’ai parlé avec au moins deux d’entre elles
  Pour que ces outils trouvent réellement leur place au point de réussir à grande échelle, la concurrence va être féroce. Mais je n’arrive pas à me débarrasser de l’idée que tout cela semble rendre possible un niveau de surveillance des développeurs qui me met très mal à l’aise

  • Si un manager passe tout son temps à observer toutes les frappes de tous les développeurs sous sa responsabilité, c’est qu’il n’a vraiment aucun vrai travail ni aucun vrai problème métier à traiter

• Les commits sont utiles précisément parce qu’ils ont déjà été nettoyés. Les tâtonnements entre les deux servent à tenter des choses et à effacer des impasses, et la plupart doivent être jetés
  Si l’on sauvegarde tous les changements et tous les messages des agents, il ne reste que ces déchets en permanence

• Google fait probablement cela avec citc depuis une dizaine d’années. Je ne sais pas quand Gemini s’en servira réellement, mais Google possède déjà, depuis au moins dix ans, l’historique de presque tous les développeurs pratiquement au Ctrl-S près
  Si Gemini a l’air idiot aujourd’hui, c’est seulement parce qu’ils économisent sur l’allocation de ressources de calcul
  0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

• Je ne vois pas bien quelle est la proposition de valeur ici. J’ai vu plusieurs entreprises proposer plus ou moins ce genre de fonctionnalité, mais aucune n’a présenté de raison vraiment convaincante pour justifier l’existence de cette technologie.

  • Je trouve intéressant à quel point ton expérience et ton flux de travail diffèrent des miens. C’est une fonctionnalité qui prétend résoudre un problème bien réel que je rencontre tous les jours
    Notre entreprise est entièrement en télétravail, et la plupart de mes collègues n’habitent pas près de chez moi. On se voit en visioconférence quelques fois par jour, mais on communique surtout via Slack
    Nous sommes aussi assez en avance dans la courbe d’adoption des agents LLM pour écrire du bon code. Grâce à de bons modèles et à d’excellentes sécurités propres à certains harnais de codage, les LLM écrivent aujourd’hui la majeure partie de notre code
    En général, ma journée consiste à prendre un ticket, à l’indiquer au LLM, puis à commencer à résoudre le problème avec lui. Je prends des décisions d’architecture, j’établis un plan et je l’exécute. La dernière fonctionnalité que j’ai déployée a coûté 19 dollars en tokens, et au plus fort du travail le LLM a continué à avancer pendant environ 30 minutes sans intervention de ma part
    Ce n’est que lorsque je ne suis pas sûr de la meilleure direction à prendre que je poste une question dans le chat d’équipe pour demander l’avis de mes collègues. Mais beaucoup de tickets sont terminés de manière entièrement autonome
    Ensuite, j’ouvre une PR et je poste le lien vers la PR dans Slack pour demander une revue ; c’est à ce moment-là que mes collègues voient l’implémentation pour la première fois. Il arrive qu’ils aient des questions. Les commentaires GitHub ne se prêtent pas très bien aux échanges rapides en temps réel, donc ils posent souvent leurs questions dans un fil Slack plutôt qu’en commentaire de PR
    Les réponses à ces questions existent dans mes journaux de discussion avec le LLM sur mon laptop, mais je n’ai aucun moyen simple de les montrer à mes collègues. Du coup, je me retrouve à faire du téléphone arabe en copiant les questions des collègues depuis Slack vers la discussion avec le LLM, puis en recollant les réponses en sens inverse
    L’idée que mon collègue, le LLM et moi puissions tous participer plus facilement à la même conversation est extrêmement séduisante
    Cela ne veut pas dire que l’équipe de Zed va dans la bonne direction, ni que notre équipe ne travaillerait pas mieux autrement. Mais notre approche actuelle est trop « efficace » pour qu’il y ait vraiment une pression organisationnelle à changer

• Le travail d’une équipe logicielle consiste à apprendre ensemble des modèles qui fonctionnent efficacement dans un domaine donné. On exprime ces modèles et ces apprentissages dans le code, les tests et la documentation associée
  Donc, d’un côté, je suis entièrement d’accord pour dire que les pull requests et la revue de code nuisent gravement à ce processus, mais je tique aussitôt à l’idée de créer encore d’autres procédures et livrables secondaires qui nous distraient. Tout cela devrait se révéler dans la base de code
  pas dans quelque chose de séparé. Pas dans des messages de commit ni dans un ensemble d’ADR. Si la base de code n’est pas capable, à elle seule, d’expliquer complètement le quoi et le pourquoi, aussi bien aux humains qu’aux IA, alors c’est un échec, et nous passerons notre vie à inventer toujours plus de procédures pour gérer cet échec

  • Le branching peu coûteux pour les fonctionnalités et les expérimentations, la capacité à annuler rapidement un commit donné, et le fait de pouvoir lire le message du commit où une ligne de code a été modifiée pour la dernière fois, tout cela est extrêmement important et rendu possible par les systèmes de contrôle de version distribués
    L’état actuel du code, à lui seul, ne suffit pas au développement logiciel moderne