Zed argues that Git, designed in 2005 around snapshots for human-typed kernel patches, loses all the meaningful state between commits — rejected AI completions, dead-end refactors, cursor movements, undos. Now that AI generates a meaningful fraction of code in the editor, the commit is just the output of an upstream workflow whose interesting state is being thrown away.
Zed positions DeltaDB explicitly against existing editor telemetry pipelines that ship events to opaque remote servers, and against rrweb-style session replay for web apps. The local-first stance makes the developer's own edit trajectory a queryable, SQL-addressable object on their own machine rather than vendor-owned analytics.
Zed points out that GitHub's claim that 46% of platform code is AI-written, Cursor's acceptance-rate dashboards, and Anthropic/OpenAI's coding benchmarks all describe a workflow whose state lives upstream of the commit. A senior dev inspecting the final artifact can't reconcile those numbers because the commit is downstream of the decisions that produced it — DeltaDB is the first serious attempt to make that upstream state inspectable.
Zed published *Software Is Made Between Commits* and introduced DeltaDB, a local-first database baked into the editor that captures the fine-grained edit history that lives between `git commit` calls. Not just diffs against HEAD — every insertion, deletion, cursor move, AI completion event, accept, reject, and undo. The editor already sees all of this; DeltaDB is the decision to stop throwing it away.
The pitch is structural, not feature-marketing. Git, designed by Linus Torvalds in April 2005 for kernel patch coordination, was built around snapshots. The unit of history is the commit. Everything between commits — the dead-end refactor, the three completions you rejected before the fourth, the 90-second pause while you stared at a function signature — is lossy by design. For 20 years nobody minded, because the process was a human typing and the snapshot captured the relevant artifact.
Zed's argument is that this assumption broke the moment AI started generating a meaningful fraction of the code in the editor. When the keyboard is no longer the only input device — when a model is proposing diffs you accept, modify, or reject — the snapshot loses the information that explains it.
GitHub claimed 46% of code on its platform is now AI-written. Cursor publishes acceptance-rate dashboards. Anthropic and OpenAI both treat coding as their flagship benchmark. None of these numbers can be reconciled against the artifact a senior dev actually inspects — the commit — because the commit is the *output* of a workflow whose interesting state lives upstream of it.
DeltaDB is the first serious attempt to make that upstream state a first-class, queryable object on the developer's own machine. The closest analogues are editor telemetry pipelines (which ship events to a remote server, usually opaquely), and rrweb-style session replay for web apps. Neither gives you SQL over your own edit trajectory. The local-first stance matters: Zed has staked a brand on not being a telemetry funnel, and a remote-first version of this would have been an instant rejection from the audience most likely to adopt it.
The community reaction on Hacker News (230 points within hours) split along predictable lines. Skeptics asked the obvious question: isn't this just keystroke logging with extra steps? The answer is that the storage model matters. Keystroke logs are append-only event streams that nobody queries; DeltaDB structures the events around semantic units — a completion, a refactor, a reverted block — so you can ask questions like *how often do I accept and then edit Claude's suggestions within 60 seconds* or *which files have the highest ratio of AI-generated lines that survived to a commit*.
Optimists noticed the second-order implication: if the data exists, every productivity claim made by an AI coding vendor becomes auditable from the user's seat for the first time. Today, a vendor tells you their tool saves you 55% of typing. With DeltaDB-style data, you can compute it yourself, against your own repos, with your own definition of "saved." That changes the negotiation.
There is also a research angle that vendors will care about more than they admit. The bottleneck for the next generation of coding models is no longer pretraining tokens — it's high-quality preference data on real workflows. Repos full of finished code are abundant; *trajectories* of how that code got built, with the rejected suggestions still attached, are not. Whoever owns the editor owns this substrate. Zed making it local-first and presumably opt-in for any sharing is both principled and competitively interesting.
If you are evaluating AI coding tools at work, this is the first data layer that lets you answer the question your finance team will eventually ask: *what did Copilot/Cursor/Claude actually do for us this quarter, measured in something more honest than seat-count?* Edit-distance on accepted suggestions, revert rate within N minutes, ratio of AI lines that survive to a merged PR — none of these are computable from `git log` alone, and all of them are computable from a delta store at the editor.
For tool builders, DeltaDB reframes what "developer analytics" can mean. The current generation — LinearB, Jellyfish, DX — reconstructs developer activity from downstream signals (PRs merged, review latency, deploy frequency) and is rightly mocked by senior engineers for measuring proxies. A delta store at the editor measures the thing directly. Expect a wave of products built on this assumption, and expect Zed to either become the substrate they all sit on or to be cloned by VS Code within two release cycles.
For your own workflow, the immediate question is whether you want this turned on. The honest answer is: probably yes for personal repos, cautiously for work, never for client code under NDA without an explicit policy. Local-first reduces the blast radius but does not eliminate it — a backed-up `~/.zed` directory is now a backup of your entire editing trajectory, which is a category of artifact your IT department has not thought about.
The deeper thesis under DeltaDB is that the artifact we have been versioning for two decades is increasingly downstream of the artifact that actually matters. Snapshots made sense when humans wrote code; trajectories matter when models write it with you. Whether Zed wins the editor war or not, the idea that the editor should remember the process — not just the result — is going to outlive the specific implementation, and the holdouts will be the products that quietly add it without crediting where the framing came from.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.