Software entsteht zwischen Commits

• DeltaDB ist eine neue Form eines Versionsverwaltungssystems, das sowohl Gespräche mit Agenten als auch die von Agenten bearbeiteten Worktrees gemeinsam versioniert
• Git ist auf einzelne Commits ausgerichtet und wurde nicht dafür konzipiert, fortlaufende Gespräche zusammen mit Codeänderungen zu behandeln, während sich der Code ständig weiterentwickelt
• DeltaDB zeichnet nicht nur Commits auf, sondern alle während der Arbeit entstehenden Operationen als feingranularen Delta-Strom und weist jedem Delta eine stabile Kennung zu
• Nachrichten und die durch diese Nachrichten erzeugten Bearbeitungen werden nebeneinander aufgezeichnet, und mehrere Personen und Agenten können dieselbe Datei gleichzeitig auf unterschiedlichen Maschinen bearbeiten
• Zusammenarbeit kann direkter in den Gesprächen und im Worktree stattfinden, während der Code entsteht, statt erst im Review-Prozess nach Commit und Push

---

Hintergrund und Problemstellung

• Das Zed-Team war mit dem Pull-Request-Modell nicht vertraut und hatte Vertrauen sowie ein gemeinsames Verständnis aufgebaut, indem es im selben Worktree zusammenarbeitete und Code während des Schreibens diskutierte
• GitHub ermöglicht Gespräche über Code erst nach Commit und Push, aber die wichtigen Unterhaltungen des Zed-Teams waren zu diesem Zeitpunkt meist schon abgeschlossen
• Zed wurde 2021 gestartet, um die Grenzen von Commits zu überwinden: Zuerst wollte man einen Editor bauen, der den besten Entwicklern der Welt gerecht wird, und darin dann eine bessere Form der Zusammenarbeit ermöglichen
• Ein Problem, über das lange im Kontext menschlicher Zusammenarbeit nachgedacht wurde, ist bei der Zusammenarbeit mit Agenten noch wichtiger geworden
• Die Gespräche, die Code erzeugen, werden zunehmend zur eigentlichen Quelle von Software, und diese Gespräche müssen sich fortlaufend auf sich verändernden Code beziehen und von ihm referenziert werden können
• Git ist auf einzelne Commits ausgerichtet und wurde nicht dafür entworfen, diese Verbindung zwischen fortlaufenden Gesprächen und Codeveränderungen zu unterstützen

DeltaDB und die nächsten Schritte

• Nicht jeder Commit, sondern jede Operation

  • DeltaDB zerlegt die Arbeit in einen feingranularen Delta-Strom und zeichnet im Gegensatz zu Git, das pro Commit Snapshots speichert, alle Operationen zwischen den Commits auf
  • Jedes Delta hat eine stabile Kennung, sodass sich auch dann auf einen bestimmten Moment im Entwicklungsverlauf verweisen lässt, wenn sich der Code weiter verändert
  • Der Worktree selbst wird in seinem Wandel versioniert und zusammen mit den Gesprächen behandelt, die diese Veränderungen antreiben
  • Nachrichten und die Bearbeitungen, die sie ausgelöst haben, werden nebeneinander aufgezeichnet und nicht voneinander getrennt
  • DeltaDB hat konfliktfreie replizierte Worktrees eingebaut, sodass mehrere Personen und Agenten dieselbe Datei gleichzeitig auf unterschiedlichen Maschinen bearbeiten können
  • Dateien sind echte Dateien, Agenten arbeiten über das Terminal an ihnen, und Nutzer können bei Bedarf den gesamten Worktree auf die Festplatte mounten und ihre eigenen Tools verwenden

• Quellcode ist jetzt Quellgespräch

  • Da Verweise nicht an Zeilennummern, sondern an Deltas gebunden sind, bleiben sie erhalten, auch wenn Code darunter verschoben wird
  • Von jeder Zeile eines früheren Gesprächs aus kann man entweder zum aktuellen Zustand des Codes springen oder zu dem Code, den der Agent zum damaligen Zeitpunkt geschrieben hatte
  • Von jeder Codezeile aus lässt sich das Gespräch finden, das diesen Code erzeugt hat, ebenso wie alle späteren Gespräche, die diesen Code verändert haben
  • Auch Agenten können diese Informationen nutzen, um den Hintergrundkontext des Codes abzurufen, den sie bearbeiten
  • Agenten können den Agenten aufrufen, der zuvor an diesem Code gearbeitet hat, und fragen, warum er auf diese Weise geschrieben wurde

• Für Zusammenarbeit sollte man nicht committen müssen

  • Das Ziel ist, dass Gespräche mit Agenten die einzige Form von Unterhaltung sind, die für Zusammenarbeit nötig ist
  • Teammitglieder können einsteigen, während die Arbeit noch läuft, mit dem Agenten sprechen, der die Arbeit ausgeführt hat, und währenddessen Kommentare hinterlassen
  • Sie müssen nicht erst auf Commit und Push warten, um sich zu beteiligen
  • Pull Requests, Review-Threads und Inline-Kommentare waren Verfahren, um Diskussionen nachträglich wieder an den Code anzubinden, weil Code und Diskussion an unterschiedlichen Orten lagen
  • Wenn Code und Diskussion am selben Ort sind, verschwinden solche Verfahren
  • Git und CI bleiben dafür da, Prüfungen auszuführen und Verbindungen zur Außenwelt herzustellen, werden aber nicht mehr zum Ort, an dem Zusammenarbeit erzwungen wird

• Nächste Schritte

  • Software nimmt heute nicht mehr in Commits, sondern in Gesprächen Gestalt an
  • DeltaDB ist das dafür gedachte Versionsverwaltungssystem und soll in wenigen Wochen ersten Nutzern bereitgestellt werden
  • Wer es früher ausprobieren möchte, kann sich in die Warteliste eintragen

[GN⁺]

Hacker-News-Kommentare

• Die Arbeit zwischen Commits ist eine chaotische Suppe und selbst wenn man hineinschaut, ist sie für niemanden nützlich. Mit git rebase schreibt man die Historie um, damit jeder Commit klein und atomar ist, und die durch die Commits erzählte Geschichte erklärt, warum der aktuelle Stand so aussieht
  Es ist eigentlich nicht wichtig, in welcher zeitlichen Reihenfolge es tatsächlich passiert ist. Ich stimme zu, dass Pull-Request-Reviews zu spät kommen, aber das Problem ist, dass Pull Requests darauf ausgelegt sind, das Gesamtergebnis eines Branches auf einmal zu reviewen, wodurch Reviews einzelner Commits schwierig werden. Die Lösung sollte nicht darin bestehen, sämtliches Rauschen zu teilen, sondern kleine, atomare Commits zu fördern, damit frühe Arbeit schon vor Abschluss eines Features oder Fixes reviewt werden kann

  • Wenn ich mir die Kommentare hier und mein berufliches Umfeld anschaue, teilen sich die Leute meist in zwei Lager. Das eine nutzt Git wie ein grobes Autosave und fasst beim Merge alles zusammen, das andere bevorzugt sauber aufbereitete, vollständig funktionierende atomare Commits
    Meiner Erfahrung nach ist Variante 1 verbreiteter, möglicherweise weil GitHub diesen Ansatz natürlicherweise besser unterstützt und aufeinander aufbauende Commits einige Probleme von Variante 2 lösen können. Wenn ich wählen müsste, würde ich sagen, dass 1 deutlich sinnvoller ist
  • Ist das nicht eher ein GitHub-Problem als ein Problem von Tools wie Phabricator oder Gerrit?
  • Ob chaotische Suppe oder nicht: Solange Speicherplatz oder Kosten kein Problem sind, finde ich es okay, wenn jemand — vermutlich ein Agent — sehen kann, was ich gemacht habe
    Ich bin mir nicht ganz sicher, aber ich denke, ein Agent bevorzugt zusätzliche Informationen, auch wenn sie für manche nur Rauschen sind
  • Mit so einer Reaktion hatte ich gerechnet. Beim Lesen des Artikels blieb mir vor allem die Enttäuschung in Erinnerung, dieses gleiche Gefühl jedes Mal wiederzusehen, wenn es um Versionsverwaltung geht
    Viel zu viele Menschen werfen den Verlauf viel zu leicht weg, nur damit er „sauber“ aussieht. Das ergibt keinen Sinn, wirkt aber überraschend plausibel innerhalb einer bestimmten Art von Programmiererlogik
    Meine Arbeitsweise ist, sehr häufig zu committen, dutzende Male am Tag. Ein Commit ist ein Protokoll dessen, was passiert ist, und ich möchte, dass möglichst viel dieses Protokolls erhalten bleibt. git bisect hat mich schon oft auf einen winzigen Ein-Zeilen-Commit geführt, der völlig harmlos aussah, aber einen subtilen Bug aufdeckte, der erst viel später entdeckt wurde
    Für mich ist Source Control genau dafür da. Hätte ich stattdessen jede Zeile eines großen Commits durchforsten müssen, wäre das alles viel schmerzhafter gewesen
    Deshalb verstehe ich wirklich nicht, warum Leute absichtlich alle Commits eines PRs zu einem Block zusammenziehen und damit genau den einzigen Teil wegwerfen, in dem Versionsverwaltung wirklich nützlich ist. Da es viele Lager wie im übergeordneten Kommentar gibt, dürfte der Plan des Autors für einen detaillierteren Verlauf kein leichter Kampf werden
  • Die Art, wie du Commits verwendest, klingt ähnlich wie meine Nutzung von gestapelten PRs im Unternehmen
    Gute Commit-Hygiene ist auf Teamebene schwer durchzusetzen, aber merkwürdigerweise sind die Leute auf PR-Ebene ziemlich kooperativ, wenn es darum geht, gute Beschreibungen zu schreiben und Änderungsgruppen sauber zu halten

• Das klingt nach häufigen Auto-Commits mit weniger Vertrauen in Git. Git kann mit häufigen Auto-Commits problemlos umgehen
  Wenn du häufige Auto-Commits zu „saubereren“ übergeordneten Commits aufrollen, aber zugleich die „Konversation“ der Auto-Commits zu den jeweiligen Zeitpunkten bewahren willst, kannst du gelegentlich git merge --no-ff verwenden und dich mit Tools wie --first-parent auf die übergeordneten Commits statt auf die „Konversations“-Commits konzentrieren
  Das Git-Backend hat durch Git pack und andere Tools bereits viel Delta-DB-Optimierung, und eigentlich etwas Nacharbeit braucht eher das Git-Frontend — vor allem --first-parent — sowie die unzähligen Git-UIs, die die „U-Bahn-Linienkarte“ priorisieren oder ausschließlich zeigen. Viele Leute finden diese Linienkarte hässlich, verwirrend und unerquicklich, daher sollte es mehr Drilldown-UIs geben, die --first-parent entsprechen

  • Ich mache das auch so. Die Commits auf dem Branch schaue ich mir normalerweise nicht an, aber falls nötig, sind sie noch da. git blame kann man auch so konfigurieren, dass es --first-parent verwendet

• Ich stimme zu, dass „Software zwischen den Commits entsteht“, aber nicht, dass „DeltaDB die gesamte Arbeit zwischen den Commits erfasst“
  Zunächst fühlt es sich übergriffig an. Ich möchte auch keinen Bildschirmrekorder, der beim Arbeiten rund um die Uhr mitläuft. Es ist zwar nicht falsch, wenn meine Fehler sichtbar werden, aber wenn ich meine Arbeit ordentlich mache, steckt der von mir geschaffene Wert in den Commits, und das fühlt sich deutlich weniger übergriffig an
  Zweitens verwende ich viele Tools, und ich möchte nicht alles davon in irgendeine seltsame DB integrieren. Wenn es an irgendeinem Punkt ohnehin nur darauf hinausläuft, dass „ein externer Prozess irgendetwas getan hat“, was bringt es dann, alles zu erfassen? Es ist gut, dass Zed vieles integrieren kann, aber das heißt nicht, dass ich alles nutzen will, was in Zed integriert ist. Als ich zuletzt nachgesehen habe, konnte man in Zed mit ACP für Claude Code nicht einmal frühere Nachrichten zurückspulen und bearbeiten
  Außerdem glaube ich persönlich, dass wir das Wesen von Commits ohnehin schon verfehlt haben. Die meisten erzeugen irgendein beliebiges, unbegrenztes Bündel an Änderungen, führen dann git commit aus, dieses Bündel wird als riesiger Block reviewt, und danach werden die Commits zusammengeführt. Davon geht die Welt nicht unter, aber sorgfältig von Hand geformte Commits sind wirklich großartig. Wenn du in einem Projekt git blame ausführst, das diese Arbeitsweise erzwingt, weißt du sofort, was ich meine
  Etwas wie DeltaDB verstärkt und verfestigt nur noch die Praxis, Commits grob zusammenzuklumpen. Wenn man wissen will, was passiert ist, kann man dann stattdessen voyeuristisch die Unterhaltung des Nutzers mit dem LLM wieder abspielen
  Der letzte Punkt ist interessant, aber auch ärgerlich. Ich konnte Teammitglieder nie allein mit dem Argument überzeugen, Änderungen und Motivation zu dokumentieren, weil das gute Engineering-Praxis sei, die anderen hilft — aber gegenüber einem LLM erklärt es plötzlich jeder bereitwillig. Das liegt zu einem großen Teil daran, dass das LLM es braucht, um die Arbeit zu erledigen, aber ich finde es faszinierend, wie viel plötzlich getan wird, was früher nicht getan wurde, nur um das LLM zufriedenzustellen. Auf einmal werden seltsam undokumentierte Dinge in CLAUDE.md dokumentiert

• Der Code, den man zwischen Commits schreibt, ist mein Denkprozess. Ich denke, indem ich Code schreibe, lösche und neu schreibe
  Der Code, der in einem Commit ausgeliefert wird, ist so geschrieben, dass andere ihn verstehen können, und ist das Ergebnis des Prozesses, den ich zum Denken durchlaufe. Ich möchte nicht, dass meine Gedanken serialisiert, versioniert und öffentlich zugänglich werden
  https://www.nature.com/articles/s44222-025-00323-4

  • Dasselbe Problem hatte ich auch mit JJ. Ich will nicht, dass alles zwischen den Commits versioniert wird
    Ich bin mir auch nicht sicher, ob all diese Zwischenzustände zwischen Commits überhaupt relevant oder nützlich sind. Allerdings habe ich das Gefühl, damit in der Minderheit zu sein
  • Deshalb nutze ich vor einem PR Rebase und mag Squash nicht. In zwei Jahren werde ich mich nicht mehr daran erinnern, warum ich den Code so geschrieben habe, und um Bugs zu verstehen und Situationen im Sinne von Chestertons Zaun zu erkennen, bleiben nur Deltas und die Commit-Historie
    Wenn man squasht, bleiben als Kontext nur der 400-Zeilen-Code, den man „auf einmal“ geschrieben hat, und die Feature-Anfrage, der dieser Code zugeordnet war. Das hilft überhaupt nicht
    Die schlimmste Person, mit der ich zu tun hatte, checkte beim Schreiben eines neuen Moduls gar nichts ein, bis es einigermaßen funktionierte. Das hing wohl auch mit einem fragilen Ego zusammen, das Bugs im eigenen Code heimlich behob, statt sie zuerst anzusprechen. Er schrieb obskuren Code, in dem sich Kernighans Gesetz zeigte, und dafür hatte er gut 10 Jahre zu viel Berufserfahrung. Er prahlte damit, sein Code sei „powerful“, was kein Kompliment, sondern ein Omen ist. Ich habe in seinem Code aus frühen Commits mehrfach Bugs gefunden. Bitte hinterlasst einfach irgendetwas
    Man muss nicht gestehen, dass man alles Mögliche ausprobiert hat, bis man das Problem gefunden hat. Sobald man weiß, dass man Punkt B erreichen kann, kann man die gewünschte Erzählung von A nach B konstruieren. Man kann die Commits so neu anordnen, wie man sie geschrieben hätte, wenn man von Anfang an genau gewusst hätte, was zu tun ist. 90 % des Codes, den man geschrieben und sofort wieder gelöscht hat, oder alles, was diese Erzählung nicht stützt, kann man wegwerfen
    In der Strafverfolgung gibt es so etwas wie Parallelkonstruktion. Man weiß vielleicht durch vor Gericht unzulässige Tatsachen, dass ein Verdächtiger schuldig ist, muss dieselben Tatsachen aber auf ordnungsgemäßem Weg erneut entdecken. Etwa indem man am Müllabfuhrtag den Müll sicherstellt, Nachbarn befragt, genug Indizien für einen Durchsuchungsbefehl sammelt und die Beweise dann erneut findet
  • Gemeint sind wohl vor allem AI-Agenten. Das ist eine interessante Idee, die ich schon einmal gesehen habe, und es ist amüsant, wie alle für AI irgendetwas neu erfinden wollen
    Trotzdem bin ich skeptisch und denke mir: Reicht es nicht, einfach eine Textdatei anzulegen und Commit-Referenzen einzufügen? Ich verstehe auch nicht, warum man nicht Fossil verwenden sollte. Es ist eine SQLite-Datenbank, man kann also das, was man will, ohnehin hineinpacken, und es hat alle möglichen eingebauten Funktionen, mit denen man auf Commits verweisen kann
  • Beim Kollaborationsteil bin ich skeptisch, aber es klingt nach einer Funktion für Unternehmenskunden, also verstehe ich die Absicht
  • Stimme voll zu. Dieses Überwachungs-Gefühl ist extrem unangenehm. Besonders der Teil „DeltaDB zerlegt Arbeit in einen feingranularen Delta-Stream. Während Git Snapshots jedes Commits erfasst, erfasst DeltaDB die gesamte Arbeit dazwischen und gibt jedem Schritt eine stabile Kennung“
    Ich hatte gehört, dass Zed ein emacs-Keymap bekommen hat, und dachte, ich probiere es vielleicht mal aus, aber jetzt nicht mehr. Das ist eine viel zu schrecklich invasive Funktion, und ich will ganz sicher nicht, dass Kollegen jede einzelne Zwischenbearbeitung bis zum Commit, den ich zur Review freigegeben habe, auf Tastenanschlagsebene durchgehen
    Bevor ich einen PR öffne, poliere ich in magit manchmal die Commit-Historie etwas, damit sie linearer und leichter verdaulich ist. Ich bessere etwa Beschreibungen aus oder fasse benachbarte Commits zusammen. Diese Funktion wirft aber einen ganzen Aspekt dieser Arbeit über Bord und sagt im Grunde: „Kollege, saug diesen Feuerwehrschlauch aus Deltas auf und hab Spaß dabei“
    Was soll der Satz „Was wir wirklich wollen, ist einfach: dass das Gespräch mit dem Agenten das einzige Gespräch wird, das du brauchst“ überhaupt bedeuten? Nein, falsch

• Mir wird flau bei dem Gedanken, dass es sich unvermeidlich anfühlt, als würden Anthropic oder OpenAI Zed übernehmen. Die Idee ist zu gut und die Software ist zu gut

  • Zeds Coding-Harness ist viel besser als Claude Code, aber weil es direkt die Claude API nutzt, ist es deutlich teurer. Wenn es in dieselbe Produktfamilie käme, könnte es das Produktsegment definieren
  • Warum bei Zed aufhören? Die 1 Billion Dollar an Investments, die AI-Firmen eingesammelt haben, waren nominell für Rechenzentren gedacht, aber wenn die Kosten steigen und sich die Fertigstellung über normale Geschäftsplanungszeiträume hinaus verschiebt, ist es effizienter, das Geld anderswo auszugeben. Mit 1 Billion Dollar kann man kaufen, was man will
  • Dort, wo Anthropic oder OpenAI hinwollen, scheint es irgendwann keinen Editor mehr zu geben. Ich persönlich hätte lieber bessere schreibgeschützte Code-Tools oder vielleicht die Rückkehr von UML

• In diesem Bereich konkurrieren derzeit wirklich viele Startups in der Frühphase. In den letzten Wochen habe ich bei Bewerbungsgesprächen mit mindestens zwei davon gesprochen
  Wenn sich diese Tools so etablieren sollen, dass sie im großen Maßstab erfolgreich sind, wird der Wettbewerb enorm hart sein. Trotzdem werde ich den Gedanken nicht los, dass all das ein Maß an Entwicklerüberwachung ermöglicht, das ich als extrem unangenehm empfinde

  • Wenn ein Manager seine ganze Zeit darauf verwendet, alle Tastenanschläge sämtlicher Entwickler unter sich zu beobachten, dann hat er wohl zu wenig echte Arbeit oder zu wenig geschäftliche Probleme, um die er sich kümmern müsste

• Commits sind nützlich, weil sie vorher bereits aufgeräumt wurden. Das Dazwischen ist der Ort für Versuch und Irrtum, dafür, etwas auszuprobieren und Sackgassen wieder zu löschen, und das meiste davon sollte verworfen werden
  Wenn man alle Änderungen und Agenten-Nachrichten speichert, bleibt dieser Müll einfach dauerhaft erhalten

• Google macht das mit citc wohl schon seit ungefähr 10 Jahren. Ich weiß nicht, wann Gemini das tatsächlich nutzen wird, aber Google hat seit mindestens 10 Jahren faktisch die nahezu vollständige Historie fast aller Entwickler in Ctrl-S-Einheiten
  Wenn Gemini im Moment dumm wirkt, dann nur, weil man bei der Zuteilung von Rechenressourcen spart
  0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

• Ich verstehe hier nicht, worin genau das Wertversprechen besteht. Ich habe mehrere Firmen gesehen, die in etwa solche Funktionen anbieten, aber keine davon hat einen überzeugenden Grund geliefert, warum es diese Technik geben muss.

  • Es ist interessant, wie sehr sich deine Erfahrung und dein Arbeitsablauf von meinen unterscheiden. Diese Funktion behauptet, ein echtes Problem zu lösen, mit dem ich jeden Tag konfrontiert bin.
    Unsere Firma arbeitet vollständig remote, und die meisten Kolleginnen und Kollegen wohnen nicht in meiner Nähe. Wir sprechen zwar ein paarmal am Tag per Videochat, kommunizieren aber hauptsächlich über Slack.
    Wir sind auch ziemlich weit vorne auf der Kurve bei der Einführung von LLM-Agenten, um guten Code zu schreiben. Dank guter Modelle und sehr guter Schutzmechanismen in einem bestimmten Coding-Harness schreibt ein LLM inzwischen den Großteil unseres Codes.
    Normalerweise beginnt ein Tag damit, dass ich mir ein Ticket nehme, es dem LLM zeige und wir gemeinsam anfangen, das Problem zu lösen. Wir treffen Architekturentscheidungen, erstellen einen Plan und setzen ihn um. Die zuletzt von mir ausgelieferte Funktion hatte Token-Kosten von 19 US-Dollar, und auf dem Höhepunkt arbeitete das LLM etwa 30 Minuten lang ohne weitere Eingaben von mir weiter.
    Nur wenn ich mir nicht sicher bin, welche Richtung besser ist, stelle ich eine Frage im Team-Chat und bitte Kolleginnen und Kollegen um ihre Meinung. Viele Tickets werden jedoch vollständig autonom abgeschlossen.
    Danach eröffne ich einen PR und poste den PR-Link in Slack mit der Bitte um Review; meine Kolleginnen und Kollegen sehen die Implementierung dann zum ersten Mal. Manchmal haben sie Fragen. Für schnelle Gespräche in Echtzeit eignen sich GitHub-Kommentare nicht besonders gut, daher landen Fragen oft eher in einem Slack-Thread als in PR-Kommentaren.
    Die Antworten auf diese Fragen stehen im Chatprotokoll mit dem LLM auf meinem Laptop, aber ich habe keine einfache Möglichkeit, sie meinen Kolleginnen und Kollegen zu zeigen. Also spiele ich Stille Post, kopiere Fragen von Slack in den LLM-Chat und füge die Antworten dann wieder zurück ein.
    Die Idee, dass meine Kolleginnen und Kollegen, das LLM und ich alle leichter am selben Gespräch teilnehmen könnten, ist sehr attraktiv.
    Das heißt nicht, dass das Team von Zed auf dem richtigen Weg ist, und vielleicht wäre unser Team besser dran, wenn wir anders arbeiten würden. Aber unser aktueller Ansatz ist zu „erfolgreich“, als dass es organisatorisch viel Druck gäbe, ihn zu ändern.

• Die Aufgabe eines Software-Teams besteht darin, gemeinsam Modelle zu erlernen, die in irgendeiner Domäne wirksam funktionieren. Wir drücken diese Modelle und Erkenntnisse in Code, Tests und zugehöriger Dokumentation aus.
  Deshalb stimme ich einerseits völlig zu, dass Pull Requests und Code Reviews diesen Prozess fatal beschädigen, zucke aber gleichzeitig bei dem Gedanken zusammen, sofort wieder andere nachgelagerte Prozesse und Artefakte zu schaffen, die uns ablenken. All das sollte sich in der Codebasis zeigen.
  Nicht in etwas Separatem. Nicht in Commit-Messages oder einem Bündel von ADRs. Wenn die Codebasis für Menschen und KI nicht vollständig aus sich selbst heraus erklären kann, was und warum etwas so ist, dann ist sie gescheitert, und wir werden unser Leben lang immer neue Prozesse schaffen, um dieses Scheitern zu verwalten.

  • Günstiges Branching für Features und Experimente, die Möglichkeit, bestimmte Commits schnell zurückzunehmen, und das Lesen der Commit-Message zu dem Commit, in dem eine Codezeile zuletzt geändert wurde, sind allesamt enorm wichtig und wurden erst durch verteilte Versionsverwaltungssysteme möglich.
    Der aktuelle Zustand des Codes allein reicht für moderne Softwareentwicklung nicht aus.