Kurz gesagt: Der Artikel argumentiert, dass das Commit- und Pull-Request-Modell von Git für KI-gestützte Entwicklung zu langsam und zu kontextarm ist, weil Agenten fortlaufend Entscheidungen und Änderungen erzeugen statt einzelner Snapshots. Er schlägt DeltaDB vor, einen feingranularen Delta-Stream, der Konversationen mit sich entwickelndem Code verknüpft, gleichzeitiges Bearbeiten durch Menschen und Agenten über CRDTs ermöglicht und Git für Distribution, CI und eine saubere öffentliche Historie beibehält.
- Klassische Pull Requests trennen den Code von den Überlegungen in Echtzeit, aus denen er entstanden ist – das verzögert Feedback und verschleiert die Absicht.
- DeltaDB erfasst jede Operation im Worktree mit einer stabilen Identität, sodass sich Code und Konversation an jedem Punkt ihrer Entwicklung nachvollziehen lassen.
- CRDT-basierte replizierte Worktrees sollen es Menschen und Agenten ermöglichen, gleichzeitig zu bearbeiten – ohne Sperren oder klassische Merge-Konflikte.
- Git bleibt als externes Referenzprotokoll und für die abschließende Verifizierung nützlich, während DeltaDB als Kollaborationsschicht dient.
- Delta-Streams verbessern den Kontext, bringen aber Zielkonflikte bei Speicher, Performance und Eventual Consistency mit sich, die eine robuste Infrastruktur und stabil gemountete Worktrees erfordern.
Klassische Commits verdichten Arbeit zu Snapshots. KI-Agenten erzeugen einen Strom aus Entscheidungen, Änderungen, Korrekturen und Kontext, der ein anderes Modell der Zusammenarbeit braucht.
Klassische Versionskontrolle ist um den „Snapshot“ herum aufgebaut – einen diskreten Zeitpunkt, an dem ein Entwickler entscheidet, dass seine Arbeit reif zum Teilen ist. Bei DataTip leben wir seit Jahrzehnten mit dem Zeremoniell des Pull Requests, doch während wir KI-Agenten in unsere täglichen Workflows integrieren, wird diese Grenze zu einer strukturellen Belastung. Die Reibung, Kommentare zu statischen Snapshots hin- und herzuschicken, ist nicht mehr nur lästig; sie ist ein Hindernis für die kontinuierliche Konversation, die moderne Softwareentwicklung heute ausmacht. Im Zeitalter autonomer Agenten ist das Warten auf einen Commit ein fataler Engpass. Wir brauchen ein System, das die Arbeit erfasst, während sie entsteht – nicht nur das fertige Produkt. Jenseits des Commits müssen wir einen grundlegenden Wandel erkennen: Die Konversation, die den Code erzeugt, wird zur eigentlichen Quelle unserer Software. Dieser Dialog läuft kontinuierlich ab und muss mit dem Code verknüpft werden, während sich dieser verändert. Git, organisiert um diskrete Commits, wurde nie für diese Granularität entworfen. Wir bewegen uns auf eine Realität zu, in der Quellcode faktisch zur Quellkonversation wird, und unsere Werkzeuge müssen diesen Wandel widerspiegeln. Dieser Artikel untersucht, warum das Snapshot-Modell scheitert und warum eine neue Abstraktion – aufgebaut auf feingranularen Deltas – nötig ist, um die Lücke zwischen menschlicher Absicht und maschineller Ausführung zu schließen.
Das Scheitern des Pull-Request-Zeremoniells
Klassische Pull Requests und snapshotbasierte Versionskontrolle (Git) erzeugen Reibung, weil sie die Konversation vom Code trennen. In Umgebungen mit hohem Vertrauen und hohem Tempo findet das Ritual aus Committen, Pushen und Warten auf ein Code-Review oft erst lange statt, nachdem die wichtigsten technischen Entscheidungen bereits gefallen sind. Wir haben festgestellt, dass die eigentliche Zusammenarbeit im Worktree stattfindet, nicht im PR-Thread. Wenn wir mit der Diskussion über Code auf einen PR warten, obduzieren wir im Grunde eine Entscheidung, die schon vor Stunden oder Tagen endgültig getroffen wurde. Bis ein menschlicher Reviewer oder ein Agent sich einen Snapshot ansieht, hat sich der Kontext des ursprünglichen Gedankengangs bereits verschoben. Git zwingt einem asynchronen Prozess eine synchrone Verzögerung auf und macht es schwer, den KI-Produktivitätsengpass zu bewältigen, der entsteht, wenn Tools schneller sind als unsere Review-Zyklen. Das PR-Zeremoniell war in einer Welt vor den Agenten ein Stellvertreter für Vertrauen, doch heute wirkt es lediglich als Puffer, der das „Warum“ hinter dem „Was“ verbirgt. Im Grunde tauschen wir Abstimmung in Echtzeit gegen eine saubere Historie, die niemand wirklich liest.
Warum KI-Agenten das Snapshot-Modell sprengen
Der Aufstieg von KI-Agenten hat den Bedarf an einer engen Kopplung von Code und Konversation verschärft. Ein Agent muss nicht nur den aktuellen Zustand einer Datei sehen; er muss die Absicht hinter den Änderungen verstehen. In einem Standard-Git-Workflow ist diese Absicht in einer Commit-Message oder einem separaten Chatfenster vergraben. Diese Trennung führt zu fehlendem gemeinsamem Verständnis zwischen dem menschlichen Operator und dem autonomen Agenten. Wenn ein Agent den Faden der Konversation verliert, beginnt er, von den Architekturstandards des Projekts abzuweichen. Wenn ein Agent Ihren Worktree bearbeitet, sollten Sie nicht warten müssen, bis er einen „Arbeitsblock“ abgeschlossen hat, bevor Sie seine Richtung sehen oder korrigieren können. Die Konversation ist die eigentliche Quelle der Software. Dieser kontinuierliche Gedankenstrom muss in Echtzeit mit dem sich ändernden Code verknüpft werden, damit weder die Nachricht noch die Änderung voneinander abdriften. Ohne das bleibt uns eine Vorhersagbarkeitslücke, bei der wir nicht vollständig darauf vertrauen können, dass die Ausgabe des Agenten den mündlichen Anweisungen von vor drei Prompts entspricht.
DeltaDB: Ein Stream feingranularer Deltas
DeltaDB ist ein neues Versionskontrollsystem, das auf feingranularen Deltas statt auf diskreten Commits basiert. Statt alle paar Stunden einen Snapshot zu erstellen, erfasst DeltaDB jede einzelne Operation im Worktree und gibt jeder eine stabile, adressierbare Identität. Das ist nicht einfach „Autosave“ für Git; es ist eine grundlegende Neukonzeption der Art, wie Zustände erfasst werden. Mit dem Wechsel von Snapshots zu Streams erreichen wir eine Versionierungsauflösung, die mit der Geschwindigkeit des Denkens Schritt hält. Da jedes Delta einzeln adressierbar ist, können Sie auf den Code zu jedem beliebigen Zeitpunkt seiner Entwicklung verweisen. Das ist eine grundlegende Abkehr von der Architektur von Git. So können wir einen Worktree versionieren, während er sich entwickelt – zusammen mit der Konversation, die ihn antreibt. Sie können von einer Zeile in einem früheren Chat zum exakten Zustand des Codes springen, als diese Zeile geschrieben wurde, oder umgekehrt. Diese Tiefe der technischen Inhaltsanalyse stellt sicher, dass die Projekthistorie ein lebendiges Protokoll ist und kein Friedhof aus Squash-Merge-Commits. In DeltaDB werden der „Undo“-Stack und die Versionshistorie zu ein und demselben.
Gleichzeitiges Bearbeiten über konfliktfreie replizierte Worktrees
Wie arbeiten mehrere Agenten und Menschen an derselben Datei, ohne gefürchtete Merge-Konflikte? Das System nutzt konfliktfreie replizierte Worktrees (CRDTs), damit Menschen und Agenten dieselben Dateien gleichzeitig bearbeiten können. Es ist dieselbe Technologie, auf der kollaborative Editoren wie Google Docs basieren – angewendet auf das gesamte Dateisystem eines Projekts. Agenten können über ein Terminal oder über gemountete Worktrees arbeiten, sodass Sie Ihre eigenen lokalen Tools nutzen können, während der Agent im Hintergrund arbeitet. Diese Architektur macht es überflüssig, Dateien zu „sperren“ oder nach einer langen Agentenaufgabe komplexe Merge-Konflikte aufzulösen. Mehrere Beteiligte – menschlich oder synthetisch – können ohne Merge-Zeremoniell auf denselben Dateizustand konvergieren. Der Worktree wird so von einer privaten Sandbox zu einem gemeinsamen, lebendigen Artefakt. Wenn es nicht mehr nötig ist, „zu committen, um zusammenzuarbeiten“, kann ein Teammitglied einer laufenden Sitzung beitreten, mit dem arbeitenden Agenten sprechen und den Code kommentieren, während er geschrieben wird.
Wann Sie Git behalten sollten: Die Rolle von CI und Distribution
Wann sollten Sie keinen deltabasierten Stream verwenden? Wichtig ist: DeltaDB ist kein vollständiger Ersatz für das gesamte Ökosystem. Git und CI bleiben für externe Integration und Prüfungen bestehen. Git ist hervorragend darin, das „Referenzprotokoll“ für den Rest der Welt zu sein und abschließende Verifizierungspipelines vor einem Release auszuführen. Sie wollen nicht, dass der „unordentliche“ Stream jedes einzelnen Tastenanschlags Ihre öffentliche Repository-Historie wird. Wir sehen DeltaDB als die Kollaborationsschicht, in der die eigentliche Arbeit stattfindet, während Git die Distributionsschicht bleibt. Mit DeltaDB bauen Sie die Software durch Konversation und feingranulare Iteration, mit Git verpacken Sie diese Arbeit anschließend für die Außenwelt. Diese Trennung ermöglicht eine saubere Git-Historie, während Sie in der Entwicklungsphase vom rohen, unbearbeiteten Kontext des DeltaDB-Streams profitieren. Stellen Sie es sich wie den Unterschied zwischen einer Live-Studioaufnahme und dem final gemasterten Track vor.
Vom Quellcode zur Quellkonversation
In dieser neuen Ära ist jede Referenz an ein Delta statt an eine Zeilennummer gebunden. Referenzen bleiben also erhalten, auch wenn sich der Code um sie herum verschiebt oder verändert. Schreibt ein Agent eine Funktion und Sie diskutieren darüber, bleibt diese Diskussion mit genau dieser Logik verknüpft – egal, wohin sie später refaktoriert wird. Das löst das altbekannte Problem „toter Links“ in Dokumentation oder PR-Kommentaren, die auf Code verweisen, der in dieser Zeile nicht mehr existiert. So entsteht eine durchsuchbare, abfragbare Historie der Absicht. Agenten können auf diesen Kontext zurückgreifen, um zu verstehen, warum ein bestimmtes Muster verwendet wurde, oder um die früheren Agenten, die an einem Codeblock gearbeitet haben, „einzuberufen“ und um Klärung zu bitten. Damit lösen wir faktisch die Krise der Wissensschulden, indem wir sicherstellen, dass das „Warum“ nie vom „Was“ getrennt wird. Wenn Code eine Verbindlichkeit ist, wie wir oft sagen, lässt sich diese Verbindlichkeit nur mit einem lückenlosen Protokoll der Konversation steuern, die seine Existenz begründet hat.
Technische Zielkonflikte: Snapshots vs. Delta-Streams
Auch wenn die Vorteile von Delta-Streams für die Zusammenarbeit klar sind, gibt es technische Zielkonflikte zu bedenken. Snapshotbasierte Systeme wie Git sind beim Speicher sehr effizient, weil sie Delta-Kompression auf große Datenblöcke auf einmal anwenden können. Ein streambasiertes System wie DeltaDB muss ein deutlich höheres Volumen einzelner Operationen verarbeiten, was ein robustes Datenbank-Backend erfordert, um die Performance zu halten. Für den aktiven Worktree eines Unternehmens mit 10 bis 200 Mitarbeitenden ist der Overhead jedoch vernachlässigbar im Vergleich zu den Produktivitätsgewinnen durch Agenten-Zusammenarbeit in Echtzeit. Zudem bedeutet der Umstieg auf CRDTs, dass die „Wahrheit“ einer Datei letztlich konsistent (Eventual Consistency) ist. Für die Textbearbeitung funktioniert das perfekt, erfordert aber sorgfältigen Umgang, wenn Agenten Compiler oder Testsuites gegen den Worktree ausführen. Deshalb können Sie mit DeltaDB den Worktree auf die Festplatte mounten – so sieht Ihre bestehende Toolchain aus Compilern, Lintern und Debuggern ein stabiles Dateisystem, auch während die zugrunde liegenden Deltas über das Netzwerk synchronisiert werden.
Zusammenfassung und nächste Schritte
Wir haben 2021 bei Zed begonnen, die Grundlage dafür zu bauen, und sind nun endlich bereit zu sehen, wie sie mit realen Workloads umgeht. In den kommenden Wochen werden wir DeltaDB ersten Nutzern zur Verfügung stellen. Wenn Sie das PR-Zeremoniell satthaben und bereit für ein Versionskontrollsystem sind, das wirklich versteht, wie Agenten arbeiten, ist es Zeit, über den Commit hinauszugehen. Software nimmt heute in der Konversation Gestalt an, nicht im Snapshot.
Nächster Schritt
Nutzen Sie den Artikel als technische Perspektive; ein verkaufslastiger CTA ist nicht nötig. Mit DataTip sprechen.