⏱️ Lectura: 10 min
Zed, the company behind the Rust-based code editor, opened the waitlist for DeltaDB: a version control system that doesn’t save work only at the final commit, but at every intermediate step.
📑 En este artículo
The pitch is simple to explain and hard to build: capture every operation that happens between one commit and the next, give it a stable identity, and connect it to the AI agent conversation that produced it.
TL;DR
- Zed opened early access to DeltaDB, a new version control system.
- DeltaDB records every operation between commits, not just the final commit.
- Each intermediate operation gets a stable identity and can be retrieved later.
- Every change is linked to the AI agent conversation that generated it.
- The worktree is virtualized: creating a new branch is, according to Zed, effectively free.
- Any point in the history, even mid-way through an agent run, can be a branch point.
- A teammate can join the conversation while the work is still happening.
- Sign-up requires an email and GitHub username at zed.dev/deltadb.
What happened
Zed Industries published an early access page for DeltaDB at zed.dev/deltadb. The form asks for an email and a GitHub username, nothing else: there’s no public download or open technical documentation yet.
The tagline the team chose sums up the bet: “software happens between commits.” The core idea is that git, by recording only explicit snapshots, discards exactly the part of the work where decisions happen: the failed attempts, the backtracking, the back-and-forth with an AI agent before reaching the final result.
DeltaDB proposes capturing that whole process. According to Zed’s own description, the system records every intermediate operation with a stable identity, so any moment in that history can be pointed to and retrieved, not just the points someone decided to freeze with a commit.
Context and history
Zed started out as a Rust-based code editor focused on performance and real-time collaboration. That collaborative origin resurfaces in DeltaDB: it’s not version control designed to just store code, but to store the process of coding alongside an agent.
The motivation behind DeltaDB connects to a problem that became common as AI agents started writing code autonomously inside editors like Zed itself: git’s history shows the result, not the reasoning. If an agent tries three different approaches before converging on one, git only leaves a trace of the last one if nobody committed the intermediate ones.
That’s the gap Zed says it identified: the conversation (the request, the correction, the “no, not like that, try this instead”) is as much part of the work as the final diff, but today it lives in a terminal or a chat that’s lost as soon as the session closes.
Technical details and DeltaDB’s performance
Zed describes four concrete capabilities for DeltaDB on the early access page, without yet publishing a technical specification or performance benchmarks:
- Rewind to any edit. DeltaDB captures every operation between commits and assigns it a stable identity, so you can point to the code exactly as it was at any moment in its evolution.
- Trace code to conversation. Every change is linked to the agent conversation that produced it. From any line you can reach the conversation that originated it, and from any message, the code it touched.
- Branch at any moment. By virtualizing the worktree, creating a new agent branch is, according to Zed, effectively free. Any point in the history, even mid-run, is a valid branch point.
- Share the thread, not the pull request. A teammate can join in while the work is still in progress, talk to the agent that did it, and comment along the way, without waiting for someone to commit and push first.
The difference from git is one of granularity and of what counts as the unit of history. The following table summarizes the contrast as Zed frames it:
| Aspect | Git | DeltaDB |
|---|---|---|
| Minimum unit of history | The commit | Every individual operation between commits |
| Link to AI conversation | None native | Every change linked to the conversation that generated it |
| Cost of a new branch | Copy or reference on top of the existing working tree | Virtualized worktree, according to Zed “effectively free” |
| Collaborating on unfinished work | Requires a prior commit and push | A teammate joins the ongoing conversation |
To understand why this matters, it helps to look at what git stores today. A typical git log only shows the points someone decided to freeze:
$ git log --oneline
a1b2c3d Fix login bug
e4f5g6h Add authentication tests
9f8e7d6 Refactor session module
Between e4f5g6h and 9f8e7d6, anything could have happened: an agent trying four different approaches for the refactor, two of them discarded. Git doesn’t store that process because there was never a commit for those attempts.
What Zed describes for DeltaDB would be something conceptually similar to this (the public CLI hasn’t been released yet, so this is an illustration of the flow, not a real command):
// Conceptual flow described by Zed (no public CLI yet)
// 1. The agent edits code within a conversation
// 2. DeltaDB assigns a stable ID to each intermediate operation
// 3. Any operation in that history can become
// the starting point of a new branch
The following diagram illustrates the underlying idea: a series of operations between two commits, all linked to the same agent conversation, with the option to open a branch at any intermediate point.
flowchart LR
A["Commit A"] --> B["Operation 1: edit"]
B --> C["Operation 2: refactor"]
C --> D["Operation 3: fix"]
D --> E["Commit B"]
B --> F["Agent conversation"]
C --> F
D --> F
C --> G["New branch from this point"]💭 Key point: DeltaDB’s bet isn’t to replace the commit as a concept, but to stop treating it as the only unit of history worth keeping.
How to start testing it
DeltaDB is still in early access: there’s no package to install and no public repository. The only step available today is joining the waitlist with an email and a GitHub username at zed.dev/deltadb.
While access opens up, you can already install and use Zed, the editor Zed Industries builds these ideas on top of. Installation is the same on macOS and Linux:
# macOS and Linux
curl -f https://zed.dev/install.sh | sh
On Windows, Zed distributes a downloadable installer from zed.dev, with nothing to compile. The editor’s full source code, published openly, is at github.com/zed-industries/zed for anyone who wants to check how Zed integrates AI agents today, before DeltaDB arrives.
# Check the installed version of Zed
zed --version
That command confirms the editor is installed and which build is running locally: a reasonable starting point for anyone who wants to be ready as soon as DeltaDB starts enabling waitlist accounts.
💡 Tip: filling in the GitHub username on the early access form isn’t optional in practice; Zed asks for it explicitly alongside the email, so it’s worth having the account you want to associate on hand.
Impact and analysis
DeltaDB arrives at a moment when more and more code is being written with an AI agent operating inside the editor, not alongside it. When a single person is programming, the commit is enough as a unit of work: the person decides when the code is ready to be saved. When the one editing is an agent iterating on its own, that decision becomes less clear, and losing the intermediate process means losing the real reason behind a change.
The feature to share the thread instead of the pull request addresses a concrete review problem: today, reviewing an agent’s work almost always means waiting for it to finish and open a branch or a PR. DeltaDB proposes that a teammate could step in mid-conversation, see why the agent made a decision, and correct course before the work is “done.”
The risk, still unaddressed publicly by Zed, is data volume: recording every intermediate operation of every agent conversation means storing far more than a traditional commit history. Zed hasn’t yet published how it plans to handle that history’s growth or whether there will be any pruning or summarization mechanism.
It’s also unclear whether DeltaDB replaces git or coexists with it inside an existing repository. The early access page doesn’t specify this, and until Zed publishes technical documentation, that question remains open.
What’s next
Zed hasn’t published a general availability date for DeltaDB or a timeline for invitations from the waitlist. The next visible step is for the company to start enabling accounts registered with an email and GitHub username.
When that happens, today’s open questions (interoperability with git, real storage cost, whether DeltaDB is tied to the Zed editor or works with any tool) should start getting answered through public technical documentation.
📖 Summary on Telegram: View summary
If you want to see it as soon as it opens up, sign up with your email and GitHub username at zed.dev/deltadb today: it’s the only step that depends on you right now.
Frequently Asked Questions
What is DeltaDB?
It’s a version control system that Zed Industries introduced in early access. Unlike git, it records every operation between commits and links it to the AI agent conversation that produced it.
Does it replace git?
Zed doesn’t clarify this on its early access page. There’s no public information yet on whether DeltaDB replaces git within a repository or coexists with it.
Can you install it already?
No. There’s only a waitlist at zed.dev/deltadb that asks for an email and GitHub username. There’s no package, CLI, or public technical documentation.
What does it mean for the worktree to be “virtualized”?
According to Zed, it means creating a new agent branch doesn’t involve copying files on disk: that’s why the team describes it as effectively free, and why any point in the history, even mid-run, can be a branch point.
How does this relate to Zed, the editor?
Zed Industries is the same company behind the Zed code editor, written in Rust. DeltaDB extends that bet on real-time collaboration into version control.
Do you need to use Zed to use DeltaDB?
Zed doesn’t specify this on the early access page. The only thing confirmed today is the sign-up process with an email and GitHub username.
References
- zed.dev/deltadb: official early access page for DeltaDB, describing its four main capabilities.
- zed.dev: official site of the Zed editor, Zed Industries’ core tool.
- github.com/zed-industries/zed: open source repository of the Zed editor.
📱 Enjoy this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion
Imagen destacada: Foto de Mohammad Rahmani en Unsplash
0 Comments