Nathan Sobo has never been a fan of pull requests.

Back before agents showed up, it was easier to believe that trading comments on a frozen snapshot was a good way to build software together. For the Zed team, it just never worked. They like to crowd into the same worktree, write and talk at the same time, and build trust by discussing the code as it happens. The problem is that GitHub won’t let anyone talk about code until it’s committed and pushed — and by then, the conversation that actually mattered is usually long over.

So in 2021 they started Zed, with one goal: escape the constraints of the commit. The plan was to first build an editor worthy of the world’s best developers, then offer a better way to work together inside it. What they didn’t see coming was that the problems they’d been chewing on for human-to-human collaboration would only get sharper once the collaborator was an agent.

Mogu inner monologue:

Plain version: disliking pull requests used to be a coworker-level annoyance. Now an agent rewrites thirty files a second, and telling it “commit first, then we’ll discuss” is like asking the fire truck to fill out a form before it leaves the station. The building already burned down. The thing this crew was grumbling about back in 2021 got blown up into a structural problem by AI — almost suspiciously good timing (⁠¬⁠‿⁠¬⁠)

The trend keeps getting clearer: the conversation that produces the code is becoming the real source of the software. That conversation runs continuously, and it has to stay cross-referenced to the code as the code keeps shifting. Git, built around discrete commits, was never designed to hold something like that.

Not just every commit — every operation

So Zed built a tool made for exactly this, called DeltaDB — a new kind of version control built on one coherent abstraction that turns your conversations with agents, and the worktrees they edit, into shared artifacts. Nathan first talked about the idea last fall, and a beta is only a few weeks out.

The core move is this: DeltaDB breaks the work into a stream of fine-grained deltas. Git takes a snapshot at each commit; DeltaDB captures every single operation that happens between commits, and gives each one a stable identity. Because every delta can be addressed on its own, you can point at any moment in the code’s evolution and say “right here” — even if it gets changed a second later. That lets the whole worktree be versioned as it evolves, tied together with the conversation driving it.

A message and the edit it produced get recorded side by side, so neither one drifts off and loses the other. Even better, DeltaDB has conflict-free replicated worktrees built in, so a whole crowd of people and agents can edit the same files at once on different machines. And these files are real: agents work inside them through a terminal, and whenever you want, the whole worktree can be mounted to disk so you can point your own tools at it.

Mogu butts in:

“Conflict-free replicated” sounds like wizardry, but underneath it’s CRDT tech — the same family that lets a crowd type into one Google Doc without fighting. The twist is that Zed pushed it up to the level of the entire worktree — not co-editing one file, but you and three agents thrashing the same repo on four machines without it collapsing into git-conflict hell. Sounds beautiful. But I’ll believe it when the beta actually runs — I’ve heard too many distributed-systems horror stories ╮(╯_╰)╭

The source of the code is now the conversation

Because every reference is anchored to a delta instead of a line number, it survives even as the code shifts underneath it. From any line in a past conversation, you can jump to that code as it stands now, or as it stood the moment the agent first wrote it. It works the other way too: stand on any line of code, and you can find the conversation that first produced it — and every conversation that has touched it since.

Agents get to use this too. An agent can pull up the backstory behind the code it’s editing, or summon the earlier agents that worked on it and ask, point-blank, why it’s written this way.

Mogu going off-topic:

This part is the most sci-fi of the whole piece. Line-number references have an ancient curse: change the code, the line numbers shift, and the link points at who-knows-what — which is why someone always replies “that line you mentioned doesn’t exist anymore” on a review. Anchoring to a delta is like giving every operation an ID card; the line can drift wherever it wants and the link still recognizes it. As for “summoning earlier agents to ask why” — friend, that’s more reliable than me asking my own self from three months ago, who (if it remembered at all) would mostly just shrug and say “dunno, it worked” (⁠´⁠_⁠ゝ⁠`⁠)

You shouldn’t have to commit to collaborate

What Zed is really after is simple: the conversation with the agent becomes the only conversation you need. A teammate can drop in while the work is still happening, talk to the agent that just did it, and annotate as they go — no waiting around for someone to commit and push first.

Pull requests, review threads, inline comments — these all exist to glue a discussion back onto the code after the fact, because the discussion and the code lived in two different places to begin with. Put them in the same place, and the whole gluing ritual just disappears. Git and CI go back to what they’re actually good at: running checks and connecting you to the rest of the world — instead of being forced to be the place where collaboration has to happen.

Mogu 's hot take:

This line stings a little: pull requests, review comments, inline comments are all basically patch jobs. The discussion and the code got split into two places at the start, so we needed all this machinery to sew them back together. Nathan isn’t out to kill Git — he very deliberately keeps Git and CI around for “running tests” and “connecting to the outside world,” the two things they’re genuinely strong at. He just takes the “collaboration” seat away from them. A revolution with manners, no “I shall overthrow everything” edginess — points for that (⁠๑⁠•⁠̀⁠ㅂ⁠•⁠́⁠)⁠و⁠✧

What comes next

Software now takes shape in the conversation, not the commit. DeltaDB is the version control built for that, and in a few weeks it’ll start landing in the hands of the first early users. If you want to be one of the first lab rats, there’s a waitlist.

Mogu whispers:

Usual reminder: this is Zed’s own product announcement, and the beta isn’t open to the public yet. All the “conflict-free” and “conversation-as-source” beauty is, for now, Zed’s own vision — not something outsiders have stress-tested. This team’s editor chops are the real deal (Nathan Sobo built the Atom editor back at GitHub), so this isn’t a slide-deck startup. But version control is the kind of thing you only trust once someone has dragged a real project through it and tried to break it. Grab a seat and watch — don’t go migrating the company repo just yet (⁠⌐⁠■⁠_⁠■⁠)

The takeaway

Git’s greatest design move was turning “a specific point in time” into something you can name and rewind to — and that’s also its biggest blind spot. Because the moments when software is actually written almost all fall in the gaps between two commits: all that messy back-and-forth of editing, undoing, then finally getting it — snipped clean off by the snapshot’s scissors.

Nathan’s bet is that in the age of agents, that snipped-off gap is the main character. The code is just the scar left behind after the conversation heals, and the conversation under the scar — the “why is it shaped like this” — is what everyone after, including the next agent, actually needs to read. What DeltaDB wants to do is fish that conversation back out of the trash, nail it next to every line of code, and never let it wander off again.

Whether it works is still anyone’s guess. But the angle alone is sharp: everyone else is busy making agents write better commits, and Zed just asks the quiet question back — software was never written in the commits, so what exactly are we all optimizing?