Git has been the backbone of software development for two decades. It’s reliable, ubiquitous, and completely wrong for the era of AI agents that generate thousands of edits per session without ever pausing to ask, “Should I commit this?”
Zed just called that bluff. On August 12, 2026, the company behind the Rust-based editor introduced Delta, a multiplayer environment built on DeltaDB, a CRDT-backed synchronization engine that treats every single edit as first-class history. No commits required. No waiting for a pull request to discuss code. The conversation is the version control.
This isn’t a feature update. It’s an architectural declaration of war on the snapshot-based model that has defined collaborative development since Linus Torvalds dropped Git on the world in 2005.
The Problem: Git Was Built for Humans Who Commit. Agents Don’t Commit.
Let’s be brutally honest about what Git actually stores. Run git log --oneline on any project and you’ll see artifacts, points where a human decided “this is worth freezing.” Between those commits lies the actual work:
- Four failed approaches to a refactor, three discarded
- A promising solution backed out because of a missing dependency
- A long conversation with a developer about architectural trade-offs
- The exact moment an agent realized approach A had a TOCTOU race condition
None of that exists in Git. The commit boundary was a reasonable unit of work when humans wrote code in deliberate chunks. But agents don’t work that way. They iterate continuously, producing hundreds of edits per session, and the reasoning behind those edits lives in a terminal transcript that disappears when the session closes.
Zed’s DeltaDB blog post put it bluntly: “Increasingly, the conversation that generates code is becoming the true source of our software.” Git was never designed to capture that.
CRDTs: The Architecture That Makes Real-Time Sync Work Without a Coordinator
DeltaDB’s underlying sync engine isn’t based on operational transforms (the approach Google Docs popularized) or traditional CRDT implementations. It uses a delta-based synchronization model that Zed claims offers better performance characteristics for their editor. The goal is simple: multiple agents and humans editing the same files simultaneously, across different machines, with no central server arbitrating conflicts.
Here’s the technical magic of CRDTs (conflict-free replicated data types): every edit is an operation that can be applied in any order across replicas, and all replicas converge to the same state. No merge conflicts. No “please resolve this before continuing.” Just deterministic convergence.
As Gus Mueller noted on The Shape of Everything, “DeltaDB uses CRDTs to incrementally record and synchronize changes as they happen. It’s designed to interoperate with Git, but its operation-based design supports real-time interactions that aren’t supported by Git’s snapshots.”
This matters beyond Zed. Any team building collaborative features, whether that’s real-time data synchronization at scale or agent-driven workflows, faces the same architectural decision: central coordinator or CRDTs?
Operation-Level Version Control: Rewinding, Tracing, and Branching
DeltaDB’s most radical departure from Git is its minimum unit of history. Where Git captures snapshots at commits, DeltaDB captures every operation between commits and assigns each one a stable identity.
This enables four capabilities that Git fundamentally cannot provide:
Rewind to any edit. Want to see what a file looked like midway through an agent’s refactoring run, before it realized it was going down the wrong path? You can point to that exact moment. Not a commit that captured it. The actual operation.
Trace code to conversation. Every change is linked to the agent conversation that produced it. From any line of code, you can find the conversation that originated it. From any message in the conversation, you can jump to the code it touched. This bidirectional traceability is baked into the data model, not bolted on.
Branch at any moment. By virtualizing the worktree, creating a new agent branch is “effectively free.” Any point in history, even mid-way through an agent run, is a valid branch point. You can fork an agent’s work at any intermediate state, explore an alternative direction, and compare results without committing, stashing, or managing multiple worktrees.
Share thread, not pull request. A teammate can join while work is still in progress, talk to the agent that did the work, and comment along the way. No waiting for someone to commit and push first.
The delta-based model also anchors references to operations rather than line numbers. When code moves, your comments and annotations survive because they’re attached to a stable operation identity, not a shifting coordinate.
Why Git’s Model Breaks Down with AI Agents
Here’s a concrete scenario that illustrates the problem. A developer asks an agent to refactor a session management module. The agent tries approach A, which introduces a race condition. It tries approach B, which works but adds 200ms per call. It converges on approach C, which is correct and performant.
In a Git-based workflow, only approach C survives. The reasoning behind rejecting A and B is lost forever.
In DeltaDB, all three attempts are preserved, linked to the conversation that evaluated each one. Six months later, when a new developer wonders why the module doesn’t use approach B, which looked simpler at a glance, they can find the exact conversation where approach B was tested and rejected. The codebase becomes a searchable record of reasoning, not just a record of results.
This kind of context retrieval is exactly the problem that Delta Attention mechanisms in AI models are tackling on the model side. DeltaDB tackles it on the data side: making the full context of code available to both humans and agents.
The Agent Is in the Thread: Delta’s Review Model
Delta’s interface reflects a fundamental shift in who’s doing the reviewing. On a commit-based platform, comments attach to snapshots and fall out of date as soon as the code changes. In Delta, you can comment on anything: the conversation, or any line of code in the worktree, whether an agent touched it yesterday or a human wrote it three years ago.
The agent is right there in the thread, working from the same original conversation and decisions as you. When something looks wrong, you don’t reconstruct intent from a diff. You ask the agent to explain it or fix it.
This is a direct challenge to the pull request ceremony that has become standard practice. The DeltaDB blog post frames it as eliminating unnecessary process: “Pull requests, review threads, and inline comments exist to reattach discussion to code after the fact because discussion and code lived in separate places. Put them in the same place, and the ceremony disappears.”
An Interface Built for Agent Throughput
Agents produce text faster than humans can read it. Most agent tools cope by hiding things: collapsing diffs, truncating transcripts, summarizing what you “should” be reading. Delta takes the opposite approach, show everything, render it as fast as the model can emit it.
More importantly, Delta treats the conversation as a document, not a stream. Your cursor works everywhere in it. When you want to respond to something, you put your cursor on it and start typing. Comments attach to the exact text they’re about: a line of the diff, a step in the plan, a thinking block. Nothing in the thread is off-limits.
This matters because the alternative, serial messages in a text box at the bottom, can’t handle the complexity of agent-driven work. If you need to react to three parts of a plan, you’d normally send three messages and hope the agent untangles them. In Delta, you comment in place, on each part, and the agent sees precisely what you mean.
The Cloud Runner and the Browser: Multiplayer Beyond the Editor
DeltaDB’s replication model extends to the cloud. You can move work to a cloud runner, close your laptop, and the agent keeps going while its conversation and code stay synchronized with the thread.
Share any thread with a link, and a teammate can open it in a browser without installing anything. Delta.dev isn’t a JavaScript/HTML approximation, it’s the same Rust application compiled to WebAssembly and rendered through WebGL. Same experience, no install.
The system also connects to third-party agent harnesses, starting with Claude Code. Keep working in the terminal you already use, and your session syncs live into a Delta thread. Share it, and teammates can watch the conversation and code evolve, comment in place, and pick up the work with full context.
What’s Still Unanswered (And Should Concern You)
DeltaDB is compelling, but it’s also genuinely unproven. As of August 2026, there’s no public CLI, no open technical documentation, and no third-party benchmarks. Jed is still in early access with a private beta.
The open questions are significant:
Storage growth. Recording every intermediate operation of every agent conversation means storing orders of magnitude more history than commit-based systems. An agent making hundreds of edits during a single refactoring session produces more data than years of human commits. Zed hasn’t published how it plans to handle that growth.
Git interoperability. Does DeltaDB replace Git within a repo, or coexist? If it coexists, how are the two histories synchronized? The blog post says “Git and CI stay for what they’re good at”, but the mechanics haven’t been specified.
Editor dependency. If DeltaDB requires Zed, its addressable market is limited. If it works with any tool, it could become a broadly adopted standard. This is one of the most consequential open questions.
Network overhead. CRDT-based synchronization sends every operation to every replica. What’s the bandwidth cost for large teams with high-frequency edit streams?
Merge behavior. CRDT convergence handles most conflicts, but what about genuinely incompatible changes, two agents making contradictory edits to the same logic? CRDTs guarantee eventual consistency, but not semantic correctness.
Privacy and retention. If every conversation is stored alongside code, what happens to sensitive information shared in agent conversations? Can history be selectively pruned?
These are the same kinds of distributed systems challenges with real-time coordination that every team building collaborative infrastructure eventually faces. CRDTs solve the synchronization problem, but they introduce operational complexity that snapshot-based systems don’t have.
Why This Matters Beyond Zed
Whether Delta succeeds or fails, the architectural questions it’s asking are the right ones. Git was designed for a world where humans wrote code in discrete, intentional chunks and reviewed each other’s work at well-defined boundaries. DeltaDB is designed for a world where agents write code continuously, iteratively, and in conversation with humans.
The comparison table says it all:
| Aspect | Git | DeltaDB |
|---|---|---|
| Minimum unit of history | The commit (snapshot) | Every operation between commits |
| Link to AI conversation | None native | Every change linked to conversation |
| Cost of new branch | Requires committed base | “Effectively free”, any point is valid |
| Collaborating on unfinished work | Requires commit and push | Join ongoing conversation in real time |
| Concurrent editing | Not supported natively | CRDT-based real-time sync |
| Reference stability | Line numbers shift and break | Anchored to deltas, survive movement |
For teams building AI-assisted development workflows, this is worth tracking on multiple fronts. Whether the operation-level model holds up under real-world data volume. Whether conversation-to-code linkage proves useful enough to change review habits. Whether Zed ships this as an open standard or keeps it tied to its own editor.
The bet is simple to explain and hard to build: capture every operation between commits, give it stable identity, and connect it to the conversation that produced it.
If it works, it changes what “version control” means for a generation of developers who increasingly collaborate with agents rather than just with each other. The thread becomes where software happens. The commit becomes just a checkpoint, not the boundary of what’s remembered.
And maybe, just maybe, we finally stop reconstructing intent from diffs and start reading the actual conversation where the decisions were made.
