Software Is Made Between Commits — Zed’s Blog

I’ve never been a big fan of pull requests.

Before Agents, it was easy to believe that the business comments function on Snapshots was an effective way to collaborate on software, but it never really worked for the Z team. We often work together in the same worktree, building trust and shared understanding by discussing code as we write this. GitHub doesn’t allow you to talk about code until you’ve committed and pushed, but by then our most important conversations are usually already over.

So in 2021, we founded Jade to go beyond the constraints of commitments. Our plan was to build an editor worthy of the world’s best developers, then introduce a better way to work together inside it. What we didn’t anticipate then was that the problems we had thought about for years in the context of human-to-human collaboration would become even more important when collaborating with agents.

Increasingly, the interactions that generate code are becoming the true source of our software. That conversation continues and should be cross-referenced as the code changes. Git, organized around separate commits, was never designed to support this.

So we are making something like this. We call it DeltaDB, a new kind of version control built on a single consistent abstraction that turns your interactions with agents and the worktrees they edit into shared artifacts. We’ve made a lot of progress since I last talked about it, and with the beta version ready in a few weeks, I’m excited to share more details about what we’re launching.

DeltaDB breaks your work into a stream of granularities delta. Where Git captures a snapshot at each commit, DeltaDB captures every operation in between and gives each a persistent identity. Since each delta is addressable by itself, you can point to the code at any moment in its evolution, even if it changes. This gives us the flexibility to version the worktree as it evolves, along with the conversations that drive it.

A message and the edits made to it are recorded together, so one doesn’t take away from the other. Because DeltaDB embeds conflict-free replication worktrees, multiple people and agents can edit the same file on different machines at once. The files are real: agents work in them through a terminal, and you can mount the entire worktree on disk whenever you want.

Since each reference is associated with a delta rather than a line number, it remains alive when the code below it is executed. From any line of the previous conversation, you can jump to the code that is there now or was at the time the agent wrote it. From any line of code, you can find the conversation that originated it and every conversation that has touched it.

Agents can also take advantage of this. They pick up the context behind the code they’re touching or call former agents who worked on it and ask why it’s written that way.

What we’re really looking for is simple: The conversation with the agent becomes the only conversation you should have. A teammate can join in while the work is going on, talk to the agent who did the work, and comment as they go, without having to wait for you to commit and push first.

Pull requests, review threads, and inline comments exist to reconnect the discussion to the code after the fact because the discussion and code lived in different places. Put them in the same place, and the function will disappear. Git and CI remain for what they are good at: running checks and connecting you to the rest of the world, rather than being a place where collaboration is forced.

Software now takes shape in conversation, not commitment. DeltaDB is version control built for that, and in a few weeks we’ll start putting it into the hands of early users.

If you want to be among the first to try it, join the waiting list.