Introducing DeltaDB: Version Control for the Era of AI Agents
DeltaDB shifts version control from snapshots to operation streams
Zed is building DeltaDB to move software development beyond the constraints of discrete commits. Unlike Git, which captures snapshots of code at specific points in time, DeltaDB records a continuous stream of fine-grained "deltas"—every single operation performed on a worktree. This approach allows the system to assign a stable identity to every change, enabling developers to reference the exact state of the code at any moment in its evolution.
This architectural shift is designed specifically for the era of AI-assisted coding. By recording operations in real-time, DeltaDB ensures that the conversation driving the code changes is stored side-by-side with the edits themselves, preventing the intent (the conversation) from drifting away from the implementation (the code).
Integrating conversation as a first-class source of truth
DeltaDB treats the conversation between a human and an AI agent as the primary source of the software. Because references are anchored to specific deltas rather than volatile line numbers, the historical context survives as the code continues to evolve.
Key capabilities of this integration include:
- Bidirectional Navigation: Developers can jump from a line in a past conversation to the current state of that code, or conversely, find the specific conversation and subsequent edits that produced a particular line of code.
- Agent Context: AI agents can access the full history of deltas to understand the "why" behind a piece of code by reviewing the prior agents and humans who touched it.
- Real-time Collaboration: Multiple humans and agents can edit the same files simultaneously across different machines using conflict-free replicated worktrees. These worktrees remain accessible as real files on disk for use with external terminal tools.
Eliminating the "Ceremony" of Pull Requests
By unifying the discussion and the code in a single location, DeltaDB aims to eliminate the need for traditional pull requests and review threads. In the current Git-based workflow, PRs serve as a mechanism to reattach a discussion to code after the work is already committed and pushed. DeltaDB intends to make the conversation with the agent the only necessary dialogue, allowing teammates to join a live work-in-progress, interact with the agent, and annotate changes in real-time.
Under this model, Git and Continuous Integration (CI) are relegated to their original strengths: running automated checks and managing the final connection to the broader ecosystem, rather than serving as the primary venue for collaboration.
Community Perspectives and Technical Critiques
The announcement of DeltaDB has sparked significant debate among developers regarding the value of "intermediate" code and the nature of professional software engineering.
The Value of the "Messy Middle"
Many developers argue that the work between commits is a "messy soup" of trial and error that should not be preserved. Critics suggest that commits are a curated story of why a change was made, whereas a stream of every operation is merely a recording of how it happened.
"The code I write between commits is my thinking. I think by writing some code out, deleting it, writing again. The code I write that's shipped in commits is written for others to understand... I don't want my thoughts to be serialized, version controlled and publicly accessible."
Concerns Over Surveillance and Noise
Some contributors expressed concern that capturing every keystroke could enable a level of developer surveillance. Others argued that the resulting history would be filled with "junk"—dead ends and mistakes—that would burden future maintainers.
"Saving every change and every agent message keeps all that junk around instead."
Comparison to Existing Systems
Technical counterpoints were raised suggesting that similar functionality could be achieved with existing tools:
- Git Optimizations: Some users noted that frequent auto-commits combined with
git merge --no-ffand--first-parentcan provide a similar balance of granular history and clean top-level commits. - Enterprise Precedents: It was noted that Google's Piper/CitC system has operated with high-granularity history for years.
- Alternative Context: Some developers prefer "context hierarchies" (live Markdown documentation next to source files) over a database of chat logs to codify intent.
AI-Specific Utility
Conversely, some developers building tools for non-engineers argue that for those who do not follow strict commit hygiene, a persistent chain of English-language discussions is the only way to represent the "chain of thought" required to build software.