Delta, DeltaDB, and the rise of “conversation-native” code reviews

Imagine the moment you stop trusting a pull request diff.

You’ve read the changes, you’ve left a comment, and somehow the author replies with something like “Yeah, that’s not what I meant.” In most workflows, that’s where things get painful: intent lives in a chat thread, while the code review lives in snapshots of code. When the code moves on, your comment starts floating in the wrong timeline.

Delta (and its underlying DeltaDB work) is built around a different assumption: the conversation that generates code shouldn’t be an afterthought. It should be a first-class artifact that stays connected to the exact places in the evolving code where it matters.

That shift has deep technical consequences. It forces new ideas about version control, collaboration, and how “references” survive as text changes.

Why comments “fall off” in traditional code review

A lot of modern review tooling is commit-centric. A commit is a snapshot: “here’s the repository state at this moment.” When you attach a comment to a diff, you’re really attaching it to a versioned location inside that snapshot.

That design works when the unit of work is human-sized and sequential.

But two things break the illusion:

1. Code review is rarely the origin of code. The real origin is a thread of decisions: requirements, rejected approaches, and the little “why” that never makes it into the final commit message.
2. Agents and humans change the same text in complicated ways. Agents can rewrite large regions, and even when diffs are correct, the line mapping between “comment target” and “current code” can become fragile.

So the same underlying question keeps coming up: Why do comments drift out of sync when the code changes? The answer is simple: snapshots don’t update their meaning after the next edit.

What DeltaDB is trying to fix: version the between-commits reality

Git is brilliant at what it does: it records states, then connects states through history.

DeltaDB’s framing (at least conceptually) is that software creation doesn’t happen only at commit boundaries. Real collaboration happens in the messy “between commits” span, where:

• someone edits a file,
• someone else discusses those edits,
• an agent proposes a rewrite,
• and then the team keeps iterating.

If you want conversation and code to stay aligned, you can’t treat a commit as the start and end of meaning. You need a system that continuously captures operations (individual edits and interaction steps), not just finished snapshots.

In other words: instead of “this comment points to line 42 in commit abc123,” you want “this comment points to the specific piece of text and the operation that created it, and that reference remains valid as the document evolves.”

The core technical trick: stable references in moving text

The hardest part of “comment stays anchored” is that the document is mutable.

Line 42 in one moment might become line 37 later. Characters shift. Insertions split existing text. Deletions remove content. If you attach references by numeric offsets, they inevitably rot.

DeltaDB’s problem space is the same problem solved in collaborative editors: multiple users need their local edits to converge to the same final document even under concurrent changes.

That brings us to CRDTs.

A CRDT (Conflict-Free Replicated Data Type) is a data structure designed so that multiple replicas can apply updates independently and still converge without needing a central lockstep schedule. “Conflict-free” doesn’t mean “no conflicts exist.” It means the system’s rules make conflicts resolvable by construction.

In text editing, CRDTs usually require expressing edits in a way that remains meaningful despite shifts—often by giving inserted fragments stable identities.

Stable anchors: (insert id, offset)

One common pattern in CRDT-based editors is:

• every inserted fragment gets a unique identity,
• references refer to an identity plus a position within that fragment,
• edits can split fragments, but the identity stays tied to what was originally inserted.

So rather than “comment at absolute character index 140,” you store something like:

• anchor = (insertion_id, offset_within_that_insertion)
• and the UI re-resolves the anchor as the document evolves.

Once anchors exist, “comments anchored to code lines” becomes “comments anchored to text fragments,” which is far more robust.

How conversation becomes a first-class coordinate system

Connecting conversation to code is more than anchoring comments. The deeper idea is: the agent and humans aren’t acting in separate universes.

When agents are involved, you also have a second stream of events:

• agent prompts and intermediate reasoning,
• tool calls and edits produced from those prompts,
• subsequent human annotations.

If those streams aren’t tied together, the review process becomes archaeology: reconstructing intent by reading transcripts and guessing which change came from which idea.

If they are tied together, the thread becomes navigable.

A useful mental model:

• the thread is an ordered record of decisions and explanations,
• the worktree is the evolving set of files those decisions produce,
• each edit operation is recorded “between” the conversation steps,
• and each comment targets an anchor that resolves to the current state of that same evolving text.

Now review is no longer “what changed?” only. It becomes “what did we decide, and where did that show up?”

Multiplayer isn’t just syncing files; it’s syncing intention

There’s a tempting-but-limited way to do collaboration:

• sync the files in real time,
• rely on users to keep discussion in chat.

That still leaves drift between where people talk and what they meant.

Delta’s direction is to make the collaboration itself feel like a shared document system:

• everyone sees the same evolving worktree,
• everyone sees the same evolving conversation,
• and the mapping between the two remains consistent.

This is why the interface matters as much as the storage engine. If you can’t act on the anchors quickly—jump to the exact target, attach a response at the right place—then the technical correctness won’t change the day-to-day experience.

A concrete data model: deltas as event pairs

To make the idea less abstract, here’s a simplified event schema you might imagine for “conversation-native” versioning.

{
 "thread_id": "t-123",
 "events": [
 {
 "type": "message",
 "id": "m-1",
 "parent": null,
 "author": "user",
 "content": "We need faster parsing for large files."
 },
 {
 "type": "edit_delta",
 "id": "d-1",
 "from_message_id": "m-1",
 "changes": [
 {
 "op": "insert",
 "anchor": {"insert_id": "ins-9", "offset": 42},
 "text": "Use a streaming tokenizer instead of substrings."
 }
 ]
 },
 {
 "type": "comment",
 "id": "c-1",
 "target": {"insert_id": "ins-9", "offset": 42},
 "content": "This sounds good, but how does it affect memory?"
 }
 ]
}

The key field is the target anchor: it survives shifts because it’s tied to inserted identity rather than transient line numbers.

The second key field is from_message_id on edits. That’s how “where the work happened” can be reconstructed as a coherent story.

Why this matters more with agents than with humans

Humans already struggle to preserve intent in a diff.

Agents make it worse in two ways:

• They produce far more text and more edits per minute.
• Their work tends to be iterative: revise assumptions, rewrite modules, refactor names.

Traditional tooling often reacts by hiding complexity:

• collapse diffs,
• truncate transcripts,
• compress review context.

But hiding the very structure you need to understand turns review into a guessing game.

In a conversation-native system, the goal is different: keep the full conversation and full edit trail available, then make it navigable via anchors and thread structure.

That’s how “review alongside the agent” stops being a slogan and becomes a workflow.

Conclusion: the next unit of software is the thread + the edits

For years, commits were the unit of truth.

As soon as agents enter the loop, that unit stops being sufficient. Software is no longer made only at commit boundaries; it’s made in a continuously evolving space where decisions, explanations, and edits trade places rapidly.

DeltaDB’s direction—capture fine-grained operations, preserve stable references, and keep the conversation and worktree synchronized—points to a new center of gravity: the thread.

Once code review targets the story of the code, not just the final snapshot, review becomes less about arguing over diffs and more about aligning on intent that actually survives the journey from idea to implementation.