Version Control Was Built for Commits. AI Agents Need a Stream.

Traditional commits compress work into snapshots. AI agents produce a stream of decisions, edits, corrections, and context that needs a different collaboration model.

Traditional version control is designed around the 'snapshot' – a discrete moment in time when a developer decides their work is worthy of sharing. At DataTip, we have lived with the ceremony of the pull request for decades, but as we integrate AI agents into our daily workflows, this boundary is becoming a structural liability. The friction of trading comments on static snapshots is no longer just an annoyance; it is a barrier to the continuous conversation that now defines modern software development. In the era of autonomous agents, waiting for a commit is a fatal bottleneck. We need a system that captures the work as it happens, not just the finished product.
Beyond the commit, we must recognize a fundamental shift: the conversation that generates the code is becoming the true source of our software. This dialogue unfolds continuously and must be cross-referenced to the code as it changes. Git, organized around discrete commits, was never designed to support this level of granularity. We are moving toward a reality where source code is effectively source conversation, and our tooling must reflect that shift. This article explores why the snapshot model is failing and how a new abstraction – built on fine-grained deltas – is required to bridge the gap between human intent and machine execution.

The failure of the pull request ceremony

Traditional pull requests and snapshot-based version control (Git) create friction by separating the conversation from the code. In high-trust, high-velocity environments, the ritual of committing, pushing, and waiting for a code review often happens long after the most critical technical decisions have been made. We found that the real collaboration happens in the worktree, not the PR thread. When we wait for a PR to discuss code, we are essentially performing an autopsy on a decision that was already finalized hours or days ago.
By the time a human reviewer or an agent looks at a snapshot, the context of the original thought process has already drifted. Git forces a synchronous delay on an asynchronous process, making it difficult to manage the AI productivity bottleneck that occurs when tools move faster than our review cycles. The ceremony of the PR was a proxy for trust in a pre-agent world, but today, it simply acts as a buffer that hides the 'why' behind the 'what'. We are essentially trading real-time alignment for a clean history that nobody actually reads.

Why AI agents break the snapshot model

The rise of AI agents has exacerbated the need for tight code-conversation coupling. An agent doesn't just need to see the current state of a file; it needs to understand the intent behind the changes. In a standard Git workflow, that intent is buried in a commit message or a separate chat window. This separation leads to a lack of shared understanding between the human operator and the autonomous agent. When an agent loses the thread of the conversation, it begins to drift from the project's architectural standards.
If an agent is editing your worktree, you shouldn't have to wait for it to finish a 'chunk' of work before you can see or correct its direction. The conversation is the true source of the software. This continuous stream of thought must be cross-referenced to the code as it changes in real-time, ensuring that neither the message nor the edit drifts away from the other. Without this, we are left with a predictability gap where we cannot fully trust that the agent's output aligns with the verbal instructions provided three prompts ago.

Introducing DeltaDB: A stream of fine-grained deltas

DeltaDB is a new version control system built on fine-grained deltas rather than discrete commits. Instead of taking a snapshot every few hours, DeltaDB captures every single operation in the worktree and gives each one a stable, addressable identity. This is not just 'autosave' for Git; it is a fundamental re-engineering of how state is tracked. By moving from snapshots to streams, we achieve a resolution of versioning that matches the speed of thought.
Because every delta is individually addressable, you can point to the code at any specific moment in its evolution. This is a fundamental departure from Git's architecture. It allows us to version a worktree as it evolves, alongside the conversation driving it. You can jump from a line in a past chat to the exact state of the code when that line was written, or vice versa. This level of technical content analysis ensures that the history of the project is a living record, not a graveyard of squash-merged commits. In DeltaDB, the 'undo' stack and the version history become the same thing.

Simultaneous editing via conflict-free replicated worktrees

How do multiple agents and humans work on the same file without the dreaded merge conflict? The system uses conflict-free replicated worktrees (CRDTs) to allow humans and agents to edit the same files simultaneously. This is the same technology that powers collaborative editors like Google Docs, but applied to the entire filesystem of a project. Agents can work via a terminal or through mounted worktrees, allowing you to use your own local tools while the agent operates in the background.
This architecture eliminates the need for 'locking' files or managing complex merge conflicts after a long-running agent task. Multiple participants – human or synthetic – can converge on the same file state without the ceremony of a merge. It transforms the worktree from a private sandbox into a shared, live artifact. When you remove the need to 'commit to collaborate,' a teammate can join a session in progress, talk to the agent doing the work, and annotate the code as it is being written.

When to keep Git: The role of CI and distribution

When should you not use a delta-based stream? It is important to clarify that DeltaDB is not a wholesale replacement for the entire ecosystem. Git and CI remain for external integration and checks. Git is exceptionally good at being the 'protocol of record' for the rest of the world and for running final verification pipelines before a release. You do not want the 'messy' stream of every single keystroke to be your public-facing repository history.
We see DeltaDB as the collaboration layer where the actual work happens, while Git remains the distribution layer. You use DeltaDB to build the software through conversation and fine-grained iteration, then use Git to package that work for the outside world. This separation allows you to maintain a clean Git history while benefiting from the raw, unedited context of the DeltaDB stream during the development phase. Think of it as the difference between a live studio recording session and the final mastered track.

From source code to source conversation

In this new era, every reference is anchored to a delta instead of a line number. This means references survive even as the code moves or changes around them. If an agent writes a function and you discuss it, that discussion stays linked to that specific logic, regardless of where it is refactored later. This solves the age-old problem of 'broken links' in documentation or PR comments that point to code that no longer exists at that line.
This creates a searchable, queryable history of intent. Agents can draw on this context to understand why a specific pattern was used or to 'convene' the prior agents that worked on a block of code to ask for clarification. We are effectively solving the knowledge debt crisis by ensuring that the 'why' is never separated from the 'what.' When code is a liability, as we often say, the only way to manage that liability is to have a perfect record of the conversation that justified its existence.

Technical Trade-offs: Snapshots vs. Delta Streams

While the benefits of delta streams are clear for collaboration, there are technical trade-offs to consider. Snapshot-based systems like Git are highly efficient for storage because they can use delta compression on large chunks of data at once. A stream-based system like DeltaDB must handle a much higher volume of individual operations, which requires a robust database backend to maintain performance. However, for the active worktree of a 10-200 person company, the overhead is negligible compared to the productivity gains of real-time agent collaboration.
Furthermore, the move to CRDTs means that the 'truth' of the file is eventually consistent. While this works perfectly for text editing, it requires careful handling when agents are running compilers or test suites against the worktree. This is why DeltaDB allows you to mount the worktree to disk, ensuring that your existing toolchain – compilers, linters, and debuggers – sees a stable filesystem even as the underlying deltas are being synchronized across the network.

Summary and Next Steps

We started building the foundation for this at Zed in 2021, and we are finally ready to see how it handles real-world workloads. We will begin putting DeltaDB into the hands of early users in the coming weeks. If you are tired of the PR ceremony and ready for a version control system that actually understands how agents work, it is time to move beyond the commit. Software now takes shape in the conversation, not the snapshot.

Next step

Use the article as a technical POV; no sales-heavy CTA needed. Talk to DataTip.