I used to think the commit was the natural unit of software history. It is clean. It has a hash. It has a message. It fits in CI. It can be reviewed, reverted, cherry-picked, and blamed.
Then AI coding agents made the gap around the commit much louder.
A lot of important engineering work now happens before the commit exists: prompts, failed attempts, corrections, abandoned edits, one-off terminal commands, agent assumptions, human steering, test failures, and small decisions that never make it into the final diff. Git sees the snapshot. The pull request sees the final red and green lines. The actual process is mostly gone.
That is the problem Zed is aiming at with DeltaDB. After listening to Scott Hanselman’s Hanselminutes episode with Zed co-founder Nathan Sobo, “The space between the Commits with Zed and DeltaDB’s Nathan Sobo”, DeltaDB clicked for me less as “Git replacement” and more as a missing layer below the pull request: version control for the act of programming itself.
This post is my attempt to unpack that idea.
Zed Is Not Just Chasing VS Code#
Some context on Zed itself, because DeltaDB makes more sense once you know who is building it and on what foundation.
Zed comes from Nathan Sobo, Antonio Scandurra, and Max Brunsfeld — the same team that built Atom, Electron, and Tree-sitter at GitHub. That lineage matters. They shipped the editor that made Electron popular, watched it hit a performance ceiling, and concluded the fix was not more optimization but a different foundation.
So Zed is Rust from top to bottom. The UI runs on GPUI, a GPU-accelerated framework the team wrote specifically for the editor — the window is rasterized the way a game engine renders a frame, which is why Zed’s benchmark obsession is typing latency and boot time rather than plugin counts. It does not feel like a browser in a trench coat because it is not one. The editor ships on macOS, Linux, and Windows.
Two more facts shape how I read the DeltaDB bet:
It has been open source since January 2024. The editor is GPL, the server-side collaboration components are AGPL, and GPUI is Apache 2.0. The stated business model is paid services on top of an open editor — hosted collaboration, AI features — not a proprietary product. DeltaDB slots directly into that model.
Collaboration is the data model, not a plugin. Zed’s text buffers are CRDTs: every edit is an operation with a stable identity, deletions are tombstones rather than destructive removals, and concurrent edits are ordered with Lamport timestamps. Multiplayer editing works by exchanging operations, not by diffing text or sharing pixels. Hold that thought — an editor whose core document type is already an operation log is unusually well positioned to persist that log. That is, in one sentence, what DeltaDB does.
On the AI side, Zed has been assembling an agent stack for a while:
- A native Agent Panel, plus edit prediction powered by Zeta2, Zed’s own open-weight model.
- External agents through the Agent Client Protocol, including tools like Claude, Codex, OpenCode, Copilot, Cursor, and others.
- MCP servers to extend what those agents can reach.
- A built-in debugger speaking the Debug Adapter Protocol, so agents and humans share the same debugging surface.
- Terminal Threads, where CLI agents and long-running terminal workflows become managed threads inside the editor.
- Parallel Agents, where multiple agent conversations can run side by side, often isolated through worktrees.
- Real-time multiplayer editing, calls, and screen sharing.
This is not only a text editor. It is becoming an agent workbench.
That changes what source control needs to remember.
The Podcast Framing: The Dark Matter Between Commits#
The most useful moment in the Hanselminutes conversation comes when Scott Hanselman paraphrases the idea back to Nathan Sobo: Git versions the checkpoints, while DeltaDB wants to version the process between those checkpoints.
That phrase captures the whole product direction.
Git stores snapshots. It is very good at that. Nathan is careful not to dismiss Git; he points out that Git’s model of snapshots chained in a causal graph works. Pack files, bulk transfer, commits, branches, and CI integration are all useful.
The problem is not that Git is bad. The problem is that Git is blind to the workspace while the code is being shaped.
In an agent workflow, that workspace is no longer private scratch space. It contains the conversation that produced the code. It contains why an approach was tried, why it failed, what the agent assumed, what the human corrected, and what changed as a result.
When that work is collapsed into a commit, a lot of meaning is lost.
Why Pull Requests Feel Too Late#
A pull request is a conversation attached to a snapshot.
That is useful, but it starts after much of the useful conversation already happened. By the time code reaches a PR, the author and the agent may have already discussed the design, debugged the failure, changed direction, deleted a first attempt, and landed on the final patch.
The reviewer sees the artifact, not the path.
In the podcast, Nathan describes today’s agent workflow as a one-on-one DM session with an agent. The byproduct of that session is a set of snapshots that get committed and pushed somewhere like GitHub, where the original conversation is not present. A separate review conversation then starts downstream on those artifacts.
DeltaDB’s design tries to move collaboration upstream. Instead of waiting for commit and push, a teammate can join the original thread, see the worktree that belongs to it, ask the agent what happened, and continue from the same state.
That is a different model:
The commit still exists. It is just no longer the first moment where collaboration becomes possible.
What DeltaDB Is Trying to Store#
Zed’s public DeltaDB page describes it as continuous source control and review. The important word is continuous.
DeltaDB records fine-grained deltas: every operation between commits, not only the commit itself. Each delta gets a stable identity. Zed can then attach conversations, annotations, and code references to those identities instead of brittle line numbers.
From Zed’s public material and the podcast, the model looks roughly like this:
A delta can be tiny, like a keystroke. It can also be a large paste or an agent-generated patch. The point is not that humans should inspect every character-level event manually. The point is that the system has enough causal history to answer higher-level questions later.
Questions like:
- What conversation produced this code?
- What did this code look like when the agent first referenced it?
- Where did this logical chunk move over time?
- Which agent threads touched this area in the last month?
- Can a teammate pick up this worktree even though I never committed it?
Git can sometimes reconstruct parts of this from commits and diffs. DeltaDB is trying to make it a first-class data model.
The Most Interesting Feature Is Not Replay#
The obvious feature is replay: if you store every edit, you can play back the work.
That is interesting, but also noisy. Nobody wants to watch a full recording of someone fighting an agent for two hours.
The more interesting feature is addressability.
Nathan describes a feature called portals: when an agent references code in a conversation, you can step through that reference into the exact code at the exact moment the reference was made. From there, DeltaDB can keep your cursor attached to the same logical location as you scrub time forward. If that code moved to another file, the system can follow it because it knows the operations that moved it.
That is hard to do with Git because Git mostly sees snapshots. You can diff snapshots and infer movement, but you are squinting through the final artifacts. DeltaDB records the path.
This is where the architecture gets more interesting than “better git blame.” It is closer to a causal index over the programming session.
Worktrees Become Collaborative Artifacts#
A normal Git worktree is personal. The repository is shared, but the dirty worktree on my laptop is mine. If I forget to commit or push, my teammate cannot see it.
DeltaDB changes that assumption.
In the podcast, Nathan describes making worktrees themselves collaborative artifacts. If a teammate joins the conversation, the exact state of the code in that thread can mirror to their disk. They can continue from there, ask the agent what happened, or review while the work is still alive.
That matters for agent-heavy work because teams are already creating many parallel branches and worktrees. The branch contains the resulting files. It does not contain the conversational stack trace: the prompt, the assumption, the correction, the failed test, the retry, and the final decision.
DeltaDB tries to version that stack trace with the code.
Git Still Matters#
The right way to read DeltaDB is not “Git is dead.”
Zed’s own announcement says Git and CI stay for what they are good at: checks and connection to the outside world. The podcast makes the same point. Git remains a clean publication and interoperability layer.
DeltaDB sits underneath and around that layer.
Think of Git as the durable public checkpoints, and DeltaDB as the high-resolution local and collaborative history between those checkpoints.
That distinction matters. Git won because it is simple enough at the boundary: commit, push, fetch, merge, rebase. DeltaDB should not make every developer think about a new database every time they edit a file. Nathan says the goal is that Git users can keep using Git while DeltaDB lights up extra capabilities on top.
If that works, DeltaDB becomes “Git++” in practice: Git-compatible, but with the missing pre-commit layer captured.
The Privacy Problem Is Real#
There is a thin line between provenance and surveillance.
Scott asks this directly in the podcast. If DeltaDB stores the process, who gets to see it? The author? The team? The company? What happens when someone pasted a secret into an agent chat? What happens when the transcript contains panic, false starts, or half-formed thinking?
Nathan’s answer is not that everything should be visible to everyone. He says the current internal version can share an entire conversation, but the intended direction is finer-grained control: share from a point in the conversation, compact or summarize earlier parts, and decide what gets exposed to peers.
This is the hardest product problem in DeltaDB.
The technical model wants to capture everything because the value comes from complete history. The human model needs selective disclosure because programming contains messy thinking. A good DeltaDB cannot become a playback system for judging how someone spent their day.
Any serious article about DeltaDB needs to keep that tension visible.
Why This Fits Zed Specifically#
DeltaDB would be hard to bolt onto a random editor as a side feature.
Zed has been moving toward this for years:
- It was built around editor performance because the UI needs to stay responsive even as collaboration and agent workflows become heavier.
- Its buffer is already a CRDT: every edit is an operation with an identity, ordered causally. DeltaDB is, in one sense, that in-memory operation log made durable, queryable, and shareable.
- It has agent threads, terminal threads, external agents, and parallel agents.
- It has a team culture shaped by pair programming and working together in the same worktree.
- It is willing to question foundations that most tools treat as fixed.
That last point came through strongly in the podcast. Zed came from dissatisfaction with the Electron/editor stack. DeltaDB comes from similar dissatisfaction with snapshot-only collaboration.
The shared pattern is: if the foundation blocks the experience they want, they rebuild lower in the stack.
What I Still Want To Know#
DeltaDB is still early access, so there are important unanswered questions:
- Is DeltaDB itself open source, hosted, local-first, or some mix?
- What exactly is stored locally versus synced through Zed services?
- How are secrets, deleted text, generated files, and binary files handled?
- How does DeltaDB behave when Git operations happen outside Zed?
- How does it scale with monorepos and very large generated diffs?
- Can external agents through ACP and terminal threads participate fully, or is the best experience limited to Zed Agent?
- What is the review UI for turning a noisy history into useful signal?
- How much can a company administrator see?
Those questions decide whether DeltaDB becomes a daily workflow or stays an impressive demo.
My Take#
DeltaDB is interesting because it names a problem many agent users already feel: the commit is too coarse to explain how the code came to exist.
When humans wrote most code by hand, losing the messy middle was acceptable. The author carried much of that context in their head. With agents, the messy middle is often the real source material. It includes the instructions, corrections, and constraints that shaped the output.
Git will remain the public ledger of software. I do not want every keystroke in my release history. But I do want a better memory for the work that happens before release history begins.
That is the promise of DeltaDB: not replacing commits, but making the space between commits visible, reviewable, and collaborative.
If Zed gets the privacy controls right, this could become one of the more important developer-tool ideas in the agent era.
If you want to form your own opinion, the path is short: listen to the Hanselminutes episode, install Zed and run one real agent thread inside it, and sign up for DeltaDB early access. The idea lands differently once you have watched an agent session produce work that Git immediately forgets.
References#
- DeltaDB early access
- Hanselminutes: The space between the Commits with Zed and DeltaDB’s Nathan Sobo
- Zed: Software Is Made Between Commits
- Zed homepage
- Zed GitHub repository
- Zed is now open source
- How CRDTs make multiplayer text editing part of Zed’s DNA
- Introducing Parallel Agents in Zed
- Terminal Threads Are Live in Zed
- Bring Your Own Agent to Zed
- Sequoia backs Zed’s vision for collaborative coding
- Zed AI docs