Zed and DeltaDB: Version Control Between Commits

I used to think the commit was the natural unit of software history. It is clean: a hash, a message, something CI can chew on and a reviewer can revert, cherry-pick, or blame. Then AI coding agents made the gap around the commit impossible to ignore.

A lot of real engineering work now happens before the commit exists: prompts, failed attempts, corrections, abandoned edits, agent assumptions, human steering, test failures. Git sees the snapshot. The pull request sees the final red and green lines. The process that produced them is mostly gone.

That gap is what Zed is aiming at with DeltaDB¹. After Scott Hanselman’s Hanselminutes episode² with Zed co-founder Nathan Sobo, it clicked for me less as a “Git replacement” and more as a missing layer below the pull request: version control for the act of programming itself.

Why Zed can build this

The load-bearing fact is that Zed’s text buffers are already CRDTs³: every edit is an operation with a stable identity, deletions are tombstones, concurrent edits are ordered with Lamport timestamps. An editor whose core document type is already an operation log is unusually well positioned to persist that log. That, in one sentence, is what DeltaDB does.

And Zed is no longer just an editor. It has agent panels, terminal threads, external agents over ACP, and parallel agents. That changes what source control needs to remember.

The dark matter between commits

Hanselman paraphrases the pitch neatly: Git versions the checkpoints, DeltaDB wants to version the process between them. Nathan does not dismiss Git. Snapshots chained in a causal graph work, and pack files, branches, and CI are all useful.

The problem is that Git is blind to the workspace while the code is being shaped. In an agent workflow that workspace holds the conversation that produced the code: why an approach was tried, why it failed, what the agent assumed, what the human corrected. Collapse that into a commit and the meaning is lost. A pull request does not recover it, because it starts too late: the reviewer sees the artifact, not the path.

What DeltaDB stores

Zed calls DeltaDB continuous source control and review. It records fine-grained deltas: every operation between commits, each with a stable identity, so conversations, annotations, and code references attach to those identities instead of brittle line numbers. A delta can be a keystroke, a large paste, or an agent patch. Nobody inspects every event; the point is enough causal history to answer questions later:

• What conversation produced this code?
• What did it look like when the agent first referenced it?
• Where did this logical chunk move over time?
• Can a teammate pick up this worktree even though I never committed it?

Addressability, not replay

Replay is the obvious feature and the least useful: nobody wants to watch two hours of someone fighting an agent. The interesting one is addressability.

Nathan describes portals: when an agent references code in a conversation, you step into the exact code at the exact moment the reference was made, and your cursor stays attached to that logical location as you scrub time forward, even after the code moves to another file, because DeltaDB knows the operations that moved it. That is closer to a causal index over the session than to a better git blame.

It also makes worktrees collaborative. A normal Git worktree is personal: forget to push and your teammate cannot see it. In DeltaDB, if a teammate joins the thread, the exact state can mirror to their disk and they continue from there.

Git still matters

None of this means Git is dead. Zed keeps Git and CI for what they are good at, publication and interoperability, with DeltaDB underneath as the high-resolution local history between checkpoints. The stated goal is that Git users keep using Git while DeltaDB lights up capability on top: Git++ in practice, with the missing pre-commit layer captured.

graph TD
    A[Continuous programming session] --> B[DeltaDB records operations]
    B --> C[Conversation-linked history]
    B --> D[Collaborative worktree]
    B --> E[Waypoints]
    E --> F[Git commit]
    F --> G[CI / PR / release]

The privacy problem is real

The hardest problem is not technical. There is a thin line between provenance and surveillance. If DeltaDB stores the process, who sees it? What about the secret someone pasted into an agent chat, or a transcript full of false starts? Nathan’s answer is finer-grained control: share from a point in the conversation, summarize earlier parts, decide what peers see.

The technical model wants everything, because complete history is the value; the human model needs selective disclosure, because programming is messy thinking. A DeltaDB that becomes a system for judging how someone spent their day is a failure, however good the engineering. It is still early access, and the answers that decide it are not public yet: what stays local versus synced through Zed services, how secrets and deleted text are handled, and how much a company administrator can see.

My take

DeltaDB names a problem agent users already feel: the commit is too coarse to explain how the code came to exist. When we wrote code by hand, losing the messy middle was fine, because the author carried the context in their head. With agents, that middle is often the real source material.

I do not want every keystroke in my release history. I do want a better memory for the work that happens before release history begins.

References

• DeltaDB early access¹
• Hanselminutes: The space between the Commits with Zed and DeltaDB’s Nathan Sobo²
• Zed: Software Is Made Between Commits⁵
• How CRDTs make multiplayer text editing part of Zed’s DNA³
• Zed homepage⁴