The Commit Is the Wrong Unit of Work in the Agent Era
Zed Industries is betting that a database of addressable, conversation linked deltas can capture the reasoning that commits leave behind.
Zed Industries is betting that a database of addressable, conversation linked deltas can capture the reasoning that commits leave behind.
Git was designed around a stable unit: the commit, a snapshot of code at a moment in time, surrounded by the social machinery (branches, pull requests, code review) that turns snapshots into shared work. Zed Industries' new essay, "Software Is Made Between Commits," argues that unit is the wrong shape for an era when humans and coding agents rewrite the same files continuously, in the same worktree, often before a commit is even formed.
The argument is structural, not promotional, even though the post is the launch vehicle for a new Zed-built data layer called DeltaDB. The premise: when an engineer and an AI pair-programmer work in parallel, the meaningful unit of work is no longer a diff against a frozen tree. It is the stream of edits and the conversation that produced them, threaded together, addressable, and replayable. "The conversation that generates the code is becoming the true source of our software," the Zed team writes. Saving only the snapshot loses the reasoning behind it.
That framing extends a practice Zed has been running internally for years. Founded in 2021 to "move beyond the constraints of commits," Zed's editors let multiple engineers and guests share a single worktree and discuss the code as it is being written, the post explains, rather than reviewing finished patches on GitHub. The company says the friction of keeping chat, edits, and code in sync, especially as agents began editing the same files, is now the same friction every team is about to inherit. Agents do not write pull requests; they stream edits into a live buffer and answer questions in the margin.
DeltaDB is Zed's answer to that inheritance. It is a database, not a Git replacement, that records fine-grained, addressable deltas against a worktree and ties each delta to the message that produced it, with conflict-free replication across collaborators and machines. The point is that a code review or a postmortem can ask, "Why is this line here?" and get back the prompt or chat exchange that put it there, not just a commit message written afterward. The source is the DeltaDB introduction, so the technical details, including storage model, sync semantics, license, and availability, are still vendor-described rather than independently verified.
The interesting question is whether this is a Zed-shaped bet or a general one. The wire frame would call this a product launch. The workflow question is broader: if the artifact worth saving is the conversation-plus-edit pair, what does version control actually need to do? A hybrid of Git for snapshots and a separate log for the chat that produced them is technically possible, and several teams are already stitching that together with hand-rolled scripts. DeltaDB's bet is that the conversation is not a sidecar; it is the index.
There is real friction to call out. The post is a founder's polemic, and the rhetoric (commits as the wrong primitive, PRs as an outdated ritual) is one team's argument, not a measured verdict on Git. Deltas as the unit of work also imply heavier infrastructure than snapshots, and a database that promises conflict-free replication across worktrees has to survive contact with real codebases before the bet pays off. Adoption figures, customer deployments, and independent benchmarks are not in the post, and any claim that DeltaDB "replaces" Git is unsupported by anything in the source.
What to watch is whether the primitives themselves change. The question worth tracking is whether the next generation of version control records the conversation that produced the code as a first-class object, with the diff indexed against it, or bolts chat logs onto a commit graph and calls it done. The commit was built for a cycle humans owned. Agents change that cycle, and the unit of work is the next thing to give.