Git is excellent at preserving finished decisions. It is much weaker at preserving the work that made those decisions understandable.
That gap used to be tolerable. A developer would think, experiment, delete a few bad starts, assemble a commit, write a message, and push. The useful artifact was the final patch. The private mess before that patch was mostly nobody else’s business.
AI coding agents change the economics of that private middle space. A large part of the work now happens in a conversation: prompts, clarifications, tool calls, generated edits, human corrections, retries, and local experiments. The final diff still matters, but it is no longer the only artifact with engineering value. The conversation often contains the constraints, assumptions, and failed paths that explain why the diff looks the way it does.
That is the premise behind Zed’s DeltaDB announcement. Nathan Sobo argues that software is increasingly made between commits, not only at commits, and that version control should understand that middle space directly.
DeltaDB is Zed’s attempt to do that. It is not framed as a replacement for Git in the normal publishing path. It is framed as an operation-level layer for work-in-progress code, agent conversations, and live collaboration. Git remains the bridge to CI, hosting, and the wider ecosystem. DeltaDB tries to capture the richer story before the commit is ready.
The Problem With Snapshot-Only Collaboration
Git stores snapshots. A commit names a state of the tree, plus metadata and parent links. That model is powerful because it is simple, portable, and durable. It lets teams branch, merge, bisect, blame, review, release, and recover.
But a snapshot has a built-in blind spot: it says what changed, not what happened while the change was being made.
In human-only workflows, teams paper over that blind spot with commit messages, pull request descriptions, issue links, design docs, Slack threads, code comments, and reviewer memory. Those tools work, but they are scattered. The rationale lives somewhere else from the code. The review discussion is usually attached after a patch is pushed. The real-time conversation that shaped the work often disappears.
Agent workflows make that separation more obvious. When an agent writes code, the interaction that produced it is not just background chatter. It can be the nearest thing to design history:
- The human told the agent which constraint mattered.
- The agent tried an approach and hit a compiler error.
- The human corrected a wrong assumption.
- The agent edited three files in response to one message.
- A later message asked it to unwind part of the change.
By the time this becomes a clean commit, the commit may be much more polished than the process that produced it. That polish is useful for review, but it also discards context that could help the next developer or the next agent.
The result is a strange split. We ask agents to reason from context, then we throw away much of the context as soon as the code lands.
DeltaDB’s Core Bet
DeltaDB’s bet is that the unit of useful history is no longer only the commit. It is the delta: a fine-grained operation in the evolving worktree.
Instead of waiting for the developer to decide that a snapshot is ready to publish, DeltaDB records a stream of edits as the worktree changes. Each operation gets a stable identity. That makes the in-progress tree addressable at a much finer level than “the state at commit X.”
The important part is not simply “more history.” Developers already know how to make too much history. Anyone who has seen a messy branch full of checkpoint commits knows that more snapshots can create more noise.
The stronger idea is that code changes and conversations can be represented as one linked artifact. A message that caused an edit can be stored next to the edit. A later reader can move from code to the conversation that created it, or from a conversation line to the code as it existed at that moment.
That is different from an auto-commit bot. Auto-commits still treat Git commits as the universal container. DeltaDB is trying to model the work itself: operation streams, conversations, agents, and worktrees that may be changing at the same time.
Why Stable Delta Links Matter
Line comments are fragile. A reviewer attaches a note to line 147. The author rebases, formats the file, extracts a helper, or accepts an agent’s rewrite. Suddenly the comment is attached to a stale view, hidden behind “outdated,” or floating near code it no longer describes.
That is one reason review tools keep inventing ways to re-anchor comments. The underlying model is fighting the workflow. Comments want to point at semantic places in changing code, but the common implementation points at positions in snapshots.
DeltaDB approaches that from the other direction. If every change in the worktree has its own identity, then references can be anchored to the evolution of the text rather than to a single rendered line. Zed describes this as a way to jump from a past conversation to the current code, or from current code back to the conversations that touched it.
That would be valuable even without AI. It is especially valuable with agents because the useful context may be distributed across many small exchanges. A reviewer does not only want to know “this line changed.” They may want to know:
- Which prompt caused this branch of the implementation?
- Did the agent add this because it inferred a requirement or because the human asked for it?
- Was this error-handling path tested, or did it appear during a retry?
- Did a later edit quietly invalidate the original rationale?
Git can answer some related questions if the team practices excellent commit hygiene. Most teams do not. Even when they do, the answer is often spread across commits, PR text, and chat history.
DeltaDB’s pitch is that the link should exist by construction.
Collaborative Worktrees, Not Just Better Blame
The earlier Sequoia-backed Zed post described DeltaDB as operation-based version control using CRDTs. That detail matters. CRDTs are data structures designed so multiple replicas can accept changes independently and converge without a central lockstep editor session.
For a code editor, that means the worktree can become collaborative without turning every participant into a guest inside one person’s machine. Humans and agents can edit the same set of files across machines, while the system keeps enough operation history to reconcile changes.
Zed’s current announcement extends that into an agent-native workflow. The files are still real files. Agents can operate through a terminal. The worktree can be mounted to disk so existing tools still work. That is important because developers do not want a magical database that only one editor understands. They want their compiler, formatter, test runner, grep, shell scripts, and language server to keep working.
The product idea is more ambitious than shared editing. A teammate could join a piece of work before it is packaged as a pull request. They could ask the same agent why it made a change. They could annotate code while it is still in motion. They could review the work as a living process instead of waiting for a branch to be pushed.
That is the part of DeltaDB that feels most like Zed’s broader identity. Zed has long argued for the editor as a multiplayer workspace, not just a personal text area. DeltaDB gives that workspace a historical model.
Pull Requests Are a Late Conversation
The announcement is blunt about pull requests: they are useful, but they are late.
A pull request starts after someone has already shaped the change into a branch. Reviewers then react to a snapshot or a series of commits. If the author did a good job, the PR description explains intent, the commits are tidy, and the tests make the change inspectable. If not, reviewers reconstruct the path from the diff.
That reconstruction is expensive. Review comments often become questions that could have been answered earlier:
- Why is this abstraction here?
- Did you consider the smaller change?
- Is this behavior intentional?
- What is the migration plan?
- Why did this unrelated file move?
DeltaDB’s model pushes collaboration earlier. Instead of turning every discussion into a PR comment after the fact, the discussion happens beside the worktree while the code is being formed. The final Git commit still exists, but it is not the only collaboration surface.
There is a real benefit here for agent-heavy work. Agents can produce a lot of plausible code quickly. The bottleneck becomes understanding, steering, and verifying the work. If review waits until the end, the human reviewer gets a polished blob that may hide a lot of uncertainty. If the conversation and edits are linked throughout the process, the reviewer can inspect not just the result but the path.
That does not mean every team should abandon pull requests. It means PRs are not enough if the richest engineering conversation now happens before the branch is ready.
The Privacy Objection Is Not Minor
The public reaction to the announcement was strong because the tradeoff is real. The discussion thread quickly filled with versions of the same concern: the code between commits is thinking, not publication.
That objection deserves more than a shrug.
Developers write bad code on purpose while thinking. They paste temporary notes. They try names they hate. They sketch an approach and delete it. They may explore a wrong path because seeing it fail is how they decide what is right. Turning all of that into a durable shared artifact can feel invasive.
There is also a quality concern. Good commits are curated. They compress messy work into units other people can understand. If a tool makes the messy middle too easy to inspect, teams may stop doing the discipline of shaping commits and writing explanations.
DeltaDB only works if it respects that boundary. The operation log cannot be treated as an always-public transcript of a developer’s mind. A usable product needs strong answers to practical questions:
- What is private by default?
- What is shared with teammates?
- What is shared with agents?
- What is retained after a branch lands?
- What can be deleted, squashed, redacted, or summarized?
- What is exported to Git, and what remains local to Zed’s system?
The announcement emphasizes collaboration, but adoption will depend on control. Developers will tolerate detailed history when it helps them recover, review, or coordinate. They will reject it if it feels like workplace surveillance with syntax highlighting.
Why “Just Use Git” Is Not a Complete Answer
Many skeptics argue that Git can already handle this. Make frequent commits. Use branches. Merge with --no-ff. Keep scratch commits under a topic branch. Use Gerrit or Phabricator for smaller review units. Store notes next to commits. Use Fossil if you want tickets, wiki pages, and code in one system.
Those are reasonable comparisons. Git is not weak software. It is one of the most successful developer tools ever made.
But “Git can store it somehow” is not the same as “the workflow is modeled well.”
Git can store generated checkpoint commits, but it does not know which chat message caused which edit. It can store notes, but notes are not the normal collaboration interface. It can preserve every scratch state, but it does not make those scratch states pleasant to navigate. It can support careful stacked commits, but most teams do not consistently write history that way, especially when agents generate large chunks of change.
The interesting question is not whether Git can be stretched. It is whether a new layer can make the common path better without breaking the parts Git already handles well.
DeltaDB is strongest if it becomes a work-in-progress context layer that eventually exports clean Git history. It is weakest if it asks teams to trust a proprietary-feeling database more than the plain repository.
The Agent Memory Angle
The most practical case for DeltaDB may not be human review. It may be agent memory.
Agents need context to make good edits. Today that context is assembled from the current files, selected snippets, project docs, terminal output, previous chat turns, and sometimes commit history. That is useful, but lossy.
A delta-linked worktree would give an agent better questions to ask:
- Why did this function become asynchronous?
- Which conversation introduced this invariant?
- What files changed together when this abstraction first appeared?
- Which edits were made to satisfy a failing test?
- Where did a human override an agent’s earlier decision?
That kind of history could make agents less likely to rediscover old mistakes or violate hidden assumptions. It could also make handoff between agents less chaotic. A new agent would not only see the final code; it could inspect the trail of decisions that produced it.
This is where the “conversation as source” framing becomes useful. Not because chat is more important than code, but because chat increasingly contains the intent that code alone cannot express.
The danger is obvious: if the captured conversation is noisy, wrong, or overly verbose, the agent may inherit noise. A better memory substrate does not remove the need for curation. It shifts the curation problem from “what do we write in the commit message?” to “what parts of the working conversation are worth preserving and retrieving?”
What a Good Version Would Feel Like
A good DeltaDB-style workflow would not feel like a recorder bolted onto an editor. It would feel like a better working memory.
While coding, it would let you recover any recent state without polluting Git history. While using an agent, it would attach edits to the exact request that caused them. While reviewing, it would let you ask why code changed without digging through stale comments. While collaborating, it would let another person join early without forcing a premature commit.
It would also have restraint:
- Private scratch work would stay private unless shared.
- Published history would still be curated.
- Git would remain the durable interchange format.
- External tools would keep working on real files.
- The operation log would be searchable and summarizable, not a raw stream everyone is expected to replay.
The failure mode is just as clear. If every keystroke becomes a social artifact, developers will perform for the log. If the system requires every tool to integrate with one editor database, it becomes a silo. If it encourages teams to skip good commits and good PR descriptions, it turns context into clutter.
The product challenge is therefore not only technical. It is cultural. DeltaDB has to preserve the useful middle without making the middle feel exposed.
The Bigger Shift
The broader lesson is that version control is being pulled in two directions.
One direction is publication. Teams still need clean commits, tested branches, releases, provenance, bisectable history, reproducible builds, and CI integration. Git remains excellent there.
The other direction is live work. Teams now have humans, agents, terminals, chat threads, generated patches, local tools, and review comments all acting on the same code before anything is ready to publish. Git was not designed to be the primary interface for that live, conversational state.
DeltaDB is Zed’s answer to the second direction. It says: keep Git for the world of commits, but build a richer versioned substrate for the work that happens before them.
That is a credible bet. It is also a bet that will only work if developers feel in control of what is captured, what is shared, and what becomes part of the permanent record.
The right mental model is not “replace Git.” It is “stop pretending the commit is the first moment software has history.”
In agent-era development, a lot of the real work happens before the commit exists. Tools that can preserve that context carefully, selectively, and without trapping teams in a silo will matter.
Top comments (0)