Delta AI Coding App: Why Zed Is Rebuilding Version Control for Agents

The Delta AI coding app is Zed’s unusually ambitious answer to a growing problem in agentic software development: once an AI agent has changed dozens of files, run commands, made decisions, and revised its own work, Git commits and a chat transcript rarely explain why the code looks the way it does. Delta attempts to make that reasoning trail part of the development environment instead of an artifact scattered across terminals, pull requests, and disposable chats.

A recent hands-on video walkthrough introduced Delta as a standalone agent workspace built by Zed, rather than a conventional editor with an AI chat sidebar added to it. The important idea is not the interface alone. Delta is built around DeltaDB, Zed’s operation-level version-control system, which records messages, comments, file edits, and worktree changes as they happen. That means a developer should be able to move from a line of code to the discussion and agent activity that produced it—and then move in the opposite direction from a prompt to its resulting changes. (zed.dev)

That is a significant shift in emphasis. Most AI coding products focus on making an agent faster at producing a diff. Delta’s bet is that as agents take on larger, longer-running tasks, the harder and more valuable problem becomes preserving context, ownership, reviewability, and team coordination.

What is the Delta AI coding app?

Delta is a collaborative, agent-focused coding environment from the creators of Zed. It is a separate application with its own desktop and web experiences, designed around threads where people and agents discuss, implement, inspect, and review work together. Zed announced Delta on August 12, 2026 as a private-beta product centered on keeping code and conversations connected. (zed.dev)

The product is now documented as a collaborative agent workspace. In the basic flow, a developer opens a Git repository, creates a thread, describes a task, and lets an agent work on a clone or checkout associated with that thread. The developer can review and bring the resulting changes into their own repository rather than allowing an agent to immediately alter the primary working directory. (delta.dev)

The interface is thread-first, not editor-first

A conventional IDE typically makes the file tree and editor the center of gravity. AI appears in a panel, modal, command palette, or terminal integration. Delta reverses that hierarchy: the thread is the default workspace, while code, diffs, project files, branches, comments, and agent activity become contextual views around the ongoing work.

This approach is not an attempt to eliminate code editing. Delta still includes code views and file navigation. Instead, it treats a development task as a living record containing requests, clarifications, planning, tool calls, edits, test results, commits, and review discussions. For teams already using agents to execute multi-step tasks, this is a more realistic representation of how the work actually happens.

It is built by Zed, but it is not just “Zed with another panel”

Zed already offers an editor-based Agent Panel for interacting with coding agents. Delta is a more opinionated product direction: a dedicated environment for asynchronous and multiplayer agent work, with DeltaDB acting as the shared foundation. (zed.dev)

That distinction matters for buyers and engineering leaders evaluating AI coding tools. Delta is not positioned primarily as autocomplete, inline editing, or a faster way to issue isolated commands. It is designed for work that may need to be handed off, interrogated later, co-authored by several people, or continued by another agent.

DeltaDB is the real product innovation

The standout technical claim behind Delta is DeltaDB, which Zed describes as version control that captures a stream of fine-grained changes rather than only commit snapshots. In Git, commits are durable checkpoints, but the edits and discussion between them are normally external to version control. DeltaDB records those intermediate operations as individually addressable deltas. (zed.dev)

This does not make Git irrelevant. Delta remains designed to work with Git repositories and Git history. The practical difference is that Git can remain the interoperability layer for a repository, while DeltaDB adds a continuous collaboration and provenance layer around work in progress.

From snapshots to an operational history

Git is exceptionally good at distributed source management, branching, merging, and preserving release-ready history. It is much less suited to questions such as:

• Which prompt led to this implementation detail?
• What alternatives did the agent consider before editing this function?
• Who approved the agent’s assumption about an API contract?
• Did the agent make this change before or after a failing test was discovered?
• Which other files were modified as part of the same reasoning step?

Today, answers are often fragmented. The prompt may be in a chat application, the tool output in a terminal buffer, the diff in a pull request, and the decision in someone’s memory. DeltaDB’s proposition is that the code and the conversation should retain a stable relationship even while files continue to change. Zed says its references are anchored to deltas instead of fragile line numbers, allowing users to inspect code as it exists now or as it existed when a message or edit was created. (zed.dev)

Why this matters more with agents than with humans

Human contributors generally have implicit context. They remember why they opened a branch, recognize an unfamiliar commit message, and can explain their intent in a review. Agents can generate substantial code quickly, but their reasoning is ephemeral unless the tooling deliberately captures it.

This creates a new form of technical debt: provenance debt. A repository may compile, pass tests, and look maintainable while no one can confidently explain why a design was chosen, whether requirements were misunderstood, or where an unsafe assumption entered the system. The bigger the agent task, the more expensive that missing context becomes.

Delta’s thesis is that conversation provenance should be a first-class software artifact. That is especially useful when an agent works across many files, when a teammate needs to resume the work, or when a reviewer needs more than a final diff to assess risk.

How Delta threads, worktrees, and checkouts work

Delta threads are conversations that have access to project worktrees. Each thread can be shared with collaborators, and the system synchronizes the conversation and file history across participants. Delta’s documentation describes the on-disk project folders as “checkouts,” while the shared project state belongs to the thread’s worktree in DeltaDB. (delta.dev)

This terminology is worth understanding because it explains one of Delta’s biggest practical safeguards: agents do not necessarily need to work directly in the folder a developer is actively editing.

Agents can work in isolated clones

In the video walkthrough, the agent worked through a staged implementation process: it inspected the codebase, asked for clarification where the prompt was ambiguous, wrote planning documents, added tests, implemented the requested interface, and committed work as it progressed. The key workflow point was isolation: the agent operated in a Delta-managed clone rather than disrupting the presenter’s main working directory.

Current Delta documentation describes the same broader model. A thread can use a Delta-managed checkout, leaving the existing project folder unchanged, or adopt the developer’s existing checkout when direct editing is desired. The agent can therefore work in an isolated environment by default, with developers choosing when and how to bring results back. (delta.dev)

This is not merely a convenience feature. Isolated agent environments reduce several common risks:

1. Accidental interruption: An agent’s package installation, formatter run, or broad refactor does not immediately collide with local work.
2. Safer parallelism: Multiple agents can pursue different approaches without sharing one mutable folder.
3. Cleaner review: A developer can assess a contained set of changes before accepting it.
4. More reproducible investigation: The thread retains the context around an experimental branch or failed attempt.
5. Less branch anxiety: Developers can delegate exploratory tasks without constantly protecting their current workspace.

Continuous history does not remove the need for review

It would be a mistake to interpret DeltaDB as an automatic correctness system. A perfectly linked prompt and diff can still contain flawed requirements, vulnerable code, broken assumptions, or an agent hallucination. What Delta improves is the reviewer’s ability to reconstruct the path that led to a change.

That can make code review more intelligent. Instead of asking only, “Does this patch look correct?”, a reviewer can ask, “What was the agent instructed to optimize?”, “What did it inspect?”, “Did it run relevant tests?”, and “Where did this design constraint originate?” Those questions are often more revealing than a final patch alone.

Multiplayer agent development is Delta’s second big bet

Delta also treats an AI task as a multiplayer workspace. Collaborators can share a thread, see messages, comments, edits, and agent activity in real time, and steer the same agent from their own machines. Multiple people can edit a draft message before it is submitted, while messages and comments retain author attribution. (delta.dev)

Zed’s underlying collaboration work draws on CRDTs—conflict-free replicated data types—which are designed to help distributed participants converge on shared state even when edits occur concurrently. Zed has used this approach in its collaborative-editor architecture for years, and DeltaDB extends that thinking to agent conversations and worktrees. (zed.dev)

Why shared prompting is more important than it sounds

Most teams still treat prompting as an individual activity. One developer opens a chat, gives an agent direction, and later sends a diff for review. That process is fast, but it loses valuable collaboration opportunities:

• A designer may catch a UX assumption before the agent implements it.
• A staff engineer may add architectural constraints before a broad refactor begins.
• A security reviewer may flag a data-handling concern while the task is still steerable.
• A teammate in another time zone may resume an incomplete agent session with the full prior context.

Delta’s shared thread model makes these interventions more natural. Rather than review only after the agent has committed to an implementation, team members can influence the work during planning and execution.

The trade-off: collaboration can create noise

There is a risk, however. More participants can mean competing instructions, unclear ownership, and context overload. An agent thread with several contributors needs rules just as a busy Slack channel does.

Teams adopting Delta should establish lightweight operating norms: identify a task owner, write constraints before execution, use comments for questions instead of interrupting the main request, and decide who is responsible for final review. The product can preserve context, but it cannot automatically resolve organizational ambiguity.

Delta versus the usual AI coding-agent workflow

The most useful way to understand Delta is not as a direct replacement for every coding tool, but as a different answer to the question: where should agent work live?

In a typical agent workflow, developers may use an IDE, terminal-based coding agent, Git worktree, issue tracker, documentation tool, pull request system, and chat application. Each tool has a purpose, but the history is fragmented. Delta aims to unify the active portion of that workflow.

Delta is not trying to make Git disappear

Git remains central to modern software delivery because ecosystems—from GitHub and GitLab to CI systems and deployment pipelines—depend on it. Delta’s own documentation explicitly starts from Git repositories, imports their files and history, and records a distinct layer of deltas around thread activity. (delta.dev)

The more accurate framing is that Delta tries to fill the gap between “uncommitted local work” and “reviewable Git snapshot.” In that gap, agents increasingly perform the most consequential—and least easily explained—work.

Where terminal agents may still be better

A thread-first interface will not fit every developer or task. Terminal-native workflows remain compelling for engineers who want direct control, simple automation, remote-server access, minimal UI overhead, or composable scripts. A one-line fix may not require a fully shareable provenance graph.

Delta is likely most compelling for tasks with more ambiguity, larger blast radius, multiple stakeholders, or a need for handoff. That includes feature implementation, migrations, architecture investigations, UX-heavy work, broad refactors, incident follow-up, and onboarding work where context has lasting value.

Models, subscriptions, and cloud execution

The original walkthrough highlighted Delta’s support for multiple model providers and the ability to use hosted models or personal provider credentials. Current Delta documentation confirms that users can connect supported providers through their own API keys, while hosted model access is governed by Zed plans, credits, and spend limits. (delta.dev)

For builders, this flexibility matters. Model availability, privacy preferences, latency, cost ceilings, and task type can vary substantially. A team may want one model for complex planning, another for rapid code edits, and a separate provider for policy or procurement reasons.

Cloud runners extend the async workflow

Delta can run an agent on a participant’s machine or on a cloud machine Delta provisions. Its documentation says cloud execution is rolling out and may not be available to everyone; cloud machines run Delta-hosted models, while threads using a developer’s own API keys run locally. (delta.dev)

The practical promise is straightforward: work need not stop because a laptop is closed. For founders, product teams, and distributed engineering organizations, asynchronous execution can turn a long agent task into something closer to a queued job with a reviewable outcome.

But cloud execution also raises the stakes for approvals and security controls. Teams should be clear about which repositories are eligible, what credentials agents can access, what commands they may run, and when a human must approve changes.

The security and data-governance questions teams should ask

Delta’s provenance model creates real value, but it also means it can retain more than a traditional local agent session. According to Delta’s data-storage documentation, the service stores repository contents and history, thread and worktree deltas, and relevant metadata to support synchronization and sharing. It says stored data is encrypted at rest, and that agent conversations—including code quoted in them—are sent through Zed Cloud to the selected model provider. (delta.dev)

That is not a criticism unique to Delta; all serious cloud-enabled agent platforms require teams to understand where code and prompts travel. But Delta’s persistent, shareable thread model makes that review especially important.

A practical adoption checklist

Before connecting Delta to a production repository, engineering and security teams should answer the following:

• Which repositories can be added to a cloud-synchronized agent workspace?
• Are secrets, customer data, private keys, or proprietary prompts excluded from agent-accessible folders?
• Which model providers are approved for source-code processing?
• Who can share a thread, invite collaborators, or use organization-wide access?
• Does “anyone with the link” match the organization’s threat model?
• Are agent credentials limited to least privilege?
• What retention and deletion requirements apply to thread history?
• What review gates remain mandatory before merge and deployment?

Delta supports sharing controls ranging from invited participants to organization members and, where allowed, signed-in users with a link. Its documentation warns that a link-accessible thread should be treated as sensitive because a recipient can pass it on. (delta.dev)

The sensible default is to treat an agent thread like a source-code collaboration artifact, not a casual conversation. The fact that it looks like a chat does not reduce the sensitivity of its contents.

What the video demonstration gets right about agent quality

The video’s most persuasive observation is not that an agent can scaffold a polished web page. Many coding agents can do that. It is that a well-designed agent workflow should handle ambiguity before it starts producing code.

In the demo, a vague request to “make it faster” triggered clarifying options rather than immediate implementation. The agent proposed directions, asked what sort of homepage was desired, then moved through planning, test definition, implementation, and validation. This resembles disciplined engineering practice: narrow the problem, document decisions, establish an acceptance contract, then build.

Good agent UX should expose uncertainty

The best AI coding tools do not simply maximize autonomous action. They make uncertainty legible and give people efficient moments to intervene. In practice, an agent should ask before making product, architectural, or operational decisions that are expensive to unwind.

Delta’s thread-based design is well suited to that behavior because the questions, answers, and eventual changes share one durable context. If a team later wonders why the agent built a landing page instead of a full watchlist feature, the answer can be attached to the implementation rather than buried in an old chat.

Planning artifacts become review artifacts

There is also value in agents committing plans, test contracts, or design notes before changing application code. These documents are not automatically useful just because they exist; teams should avoid creating process theater. But for nontrivial work, they can make review much faster.

A reviewer who sees a test contract and concise implementation plan can evaluate whether the agent solved the intended problem before reading every CSS declaration or component change. Delta’s linked history provides a natural home for those artifacts.

Who should try Delta first?

The ideal early Delta user is not necessarily the developer who wants the fastest autocomplete. It is the person or team already feeling the limits of unstructured agent work.

Strong use cases

Delta is especially promising for:

• Founders building quickly with agents: Preserve decisions while features evolve rapidly.
• Small product teams: Let engineers, designers, and product leads steer implementation in one place.
• Platform and infrastructure teams: Maintain context around migrations, configuration changes, and risky refactors.
• Agencies and consultancies: Create a clearer handoff record for client work.
• Open-source maintainers: Give contributors context for an agent-assisted change before it becomes a pull request.
• Engineering managers: Review not only outputs, but the process used to reach them.

Less compelling use cases

Delta may be overkill for a developer handling tiny, solo changes in a stable codebase. It may also be difficult to introduce where teams have strict requirements to keep all source code, prompts, and tool execution inside an existing controlled environment.

Its early-stage status is another reason to start with a noncritical repository. The correct adoption motion is a pilot: select a contained project, define acceptable tasks, test sharing and permissions, measure review quality, and compare the result with the team’s existing terminal-agent or IDE-agent workflow.

The larger trend: software development is becoming conversational

Delta is part of a wider transition in developer tooling. The center of development is shifting from manually authored lines of code toward a loop of intent, delegation, inspection, revision, testing, and integration. Code remains the shipped artifact, but more of the work that determines that code now happens in conversations with models.

Zed articulates this directly in its DeltaDB announcement: as agents create code through ongoing exchanges, the conversation becomes a meaningful source artifact rather than disposable interface chrome. (zed.dev)

The industry question is whether teams will accept a conversation-first workspace as the primary place to direct development. Some will prefer editors and terminals indefinitely. Others will adopt a hybrid model: use familiar tools for direct coding, then use threaded agent environments for larger delegated work.

Either way, Delta identifies a genuine weakness in today’s AI coding stack. Faster agents increase the amount of code produced between meaningful checkpoints. Without better provenance, teams can gain output while losing understanding.

The bottom line: Delta makes traceability the feature

The Delta AI coding app is interesting because it does not treat AI-generated code as just another diff. It treats the entire chain of intent, implementation, testing, discussion, and revision as something worth preserving and sharing.

That could make Delta particularly valuable in the phase after the novelty of coding agents wears off—when teams are no longer asking whether an agent can write code, but whether they can safely review, maintain, audit, and extend what it wrote. Git will remain indispensable, but DeltaDB’s operation-level history points toward a future where commit history alone is no longer enough to explain a codebase.

For creators and engineering teams, the practical takeaway is simple: evaluate AI coding tools on more than raw generation quality. Ask how they isolate work, expose uncertainty, support collaboration, preserve provenance, and fit your review process. Delta’s answer to those questions is more structural than most, which is precisely why it is worth watching.

FAQ

What is Delta by Zed?

Delta is a collaborative, thread-first workspace for coding with AI agents. It connects conversations, comments, code edits, worktrees, and review context through Zed’s DeltaDB system. (zed.dev)

Does Delta replace Git?

No. Delta works with Git repositories and adds a continuous history of messages, edits, and worktree activity around normal Git-based development. Git remains the repository and ecosystem compatibility layer. (delta.dev)

Can an agent change my main working directory in Delta?

Delta can use an isolated, Delta-managed checkout so an agent works separately from your existing project folder. It can also adopt an existing checkout when direct editing is intentionally chosen. (delta.dev)

Can teammates collaborate in the same Delta agent thread?

Yes. Shared threads allow participants to see messages, edits, comments, and agent activity, collaborate on draft prompts, and steer the agent. Access depends on the thread’s sharing settings. (delta.dev)

Is Delta suitable for production repositories?

Potentially, but teams should start cautiously. Review Delta’s provider, data-storage, sharing, retention, credential, and approval settings before using it with sensitive or production-critical code. (delta.dev)