Rohit Ghumare · September 17, 2026 · 13 min read

Zed Turned Off Pull Requests. The Merge Gate Has to Go Somewhere.

If agents write most of your changes, the pull request stops being the place where review works: the diff arrives without the reasoning behind it, and the queue grows faster than your reviewers. Zed's answer is to replace the pull request with a thread that keeps the reasoning attached. Take that part, and keep the part a thread cannot replace: a merge gate the remote enforces, which no agent can talk its way past. This essay takes Delta apart and ends with a setup that keeps both.

On September 16 Zed opened the public beta of Delta, a multiplayer environment for coding with agents and reviewing what they build. The week before, the team disabled pull requests on Delta's own repository, and since then 33 of them have landed 570 changes to main without opening one. The claim behind it is bigger than a new review screen: that the thread, the running conversation between people, agents, and the code they edit, should replace the pull request as the unit of work. So the questions are concrete. What does a pull request actually carry, what does a Delta thread carry instead, and when you remove the pull request, where does the thing that used to stop bad merges end up?

What a pull request is made of

Strip the interface away and a pull request is a request object with a fixed set of parts. There is a branch reference and a base. There is the diff between them and the list of commits that produced it. There is a description the author wrote. There are comment threads, each anchored to a line number in a specific version of a file. There are status checks reported by CI, approvals from reviewers, and a merge action that the host refuses to run until branch protection rules are satisfied.

Look at what those parts have in common. Every one of them describes the result. The diff is the end state. The commits are checkpoints the author chose to keep. The description is a summary written after the work, and the comments attach discussion to the code after it was pushed. The path the author took to get there, the options tried and dropped, the reason a lock is a Mutex and not an RwLock, lives nowhere in the object. It lived in the author's head, and for most of the pull request's history that was fine, because a reviewer could ask the author and the author could remember.

You can see the shape from the command line. Ask GitHub for everything it stores about a pull request and the answer is a list of results:

gh pr view 1234 --json body,commits,reviews,statusCheckRollup,files

Field names from the gh pr view manual. Of the five, only body is free text an author can use for reasoning, and it is written after the work.

Agents break both halves of that arrangement. The author of much of the code is now an agent session that ended hours ago, so there is no head to ask. And the volume went up. Zed's post puts it plainly: "with agents generating so much code, the diffs we're asking each other to review have mushroomed." Splitting a big change across a stack of branches makes it easier to navigate, but, as the post says, "the decisions behind the code still need review. Smaller diffs don't supply that context." The reviewer's usual move is to paste the diff into their own agent, which then "has to piece together decisions you already worked through."

What DeltaDB records instead

Delta sits on DeltaDB, which Zed introduced on June 11. Git stores a snapshot at each commit. DeltaDB stores every operation between commits as a fine-grained delta and gives each one a stable identity, so any moment in the code's evolution can be addressed, not only the moments someone chose to commit. A message and the edit it produced are recorded side by side. The worktrees are conflict-free replicated, which is how several people and agents can edit the same files at once from different machines, and the files are real files: agents work in them through a terminal, and you can mount the worktree to disk for your own tools.

The detail that matters for review is anchoring. A pull request comment points at a line number in one version of a file, which is why comments go "outdated" when the code moves. A DeltaDB reference points at a delta. Because the delta has an identity that survives edits, a reference to it survives the code moving underneath it. From a line in an old conversation you can jump to that code as it stands now, or as it stood when the agent wrote it. From a line of code you can find the conversation that produced it. It is git blame with a finer grain and a second column: blame tells you which commit last touched a line, and a delta anchor tells you which operation did and what was said right before it.

The commit does not go away. The Delta announcement is careful on this point: "A commit remains the checkpoint you push, pull, and build from. DeltaDB retains the work between those checkpoints." So the design is an overlay. The Git history you ship is still there, and the thread is extra data laid over it.

Two git remotes connect the thread back to ordinary git. According to Delta & Git, a checkout Delta creates from your project has origin, the shared upstream such as GitHub, and local, which points at your own repository on your machine. Work comes back out through one of them, never through the commit itself: Delta records file edits continuously "without creating Git commits," and an agent's commit lands in the managed checkout's own repository. To hand yourself a branch without a round trip through GitHub:

git push local <branch-name>
git switch <branch-name>

From Delta's Reviewing & Syncing Changes docs, not run here. A clean checkout of the same branch updates in place; git rejects a push that would overwrite uncommitted edits.

Review becomes a fork of the conversation

In a pull request, review is a separate activity performed on a frozen snapshot. In Delta, review is a subthread. You can invite a teammate to pick up your thread where you left off, or open a dedicated review subthread. According to Delta's review docs, opening one asks the agent for a change guide, "a structured walkthrough of the change in the order that explains it best, with focused inline diffs." The review gets its own isolated copy of the parent thread's worktrees, so the reviewer and their agents can poke at the code and try changes without disturbing the original work.

The reviewer finishes with one of two verdicts, Approve or Request Changes. If they fixed something themselves, those edits do not merge back on their own. The author clicks Pull Changes on the verdict, which applies a snapshot of the review's edits as they were when the verdict was submitted. That is a sensible rule: the author pulls a fixed, reviewed state, not whatever the review worktree drifted into afterwards.

The mechanism worth noticing is that the reviewer's questions go to the agent that holds the context. Zed's example is a teammate asking "the same agent why you chose a Mutex instead of an RwLock." In a pull request that question either reaches a human who may not remember, or a fresh agent that reconstructs a plausible answer from the diff. A plausible reconstruction and the actual reason are different things, and a reviewer cannot tell which one they got.

The review surface is driven from the composer. These are the documented entry points:

/review            open a review thread for this thread's changes
/change-guide      write a structured walkthrough of an existing change
/approve           submit an approving verdict, with or without a review thread
/request-changes   submit a changes-requested verdict

Commands from Delta's review and skills docs, not run here. /review is also Cmd+Shift+R on macOS. You cannot review a review; reviews start from a top-level thread.

Teams that stay on pull requests can still ship the reasoning with the change. A pull request template with a short decision log gives the body field a job it was never asked to do. The template below is a pattern, not a GitHub feature; GitHub only supplies the file location.

<!-- .github/pull_request_template.md -->
## What changed
<one paragraph, written for the reviewer>

## Decisions
| Question | Options considered | Chosen | Why |
|---|---|---|---|
| Lock for the cache map | Mutex, RwLock | Mutex | writes dominate; RwLock adds reader starvation risk |

## Agent session
<link to the transcript or Delta thread, if one exists>

## How it was verified
<the commands that passed>

A pattern built for this essay. Keep the Decisions table short: the queue math below shows it pays only when reading it costs less than rebuilding the reasons.

The queue is the real problem

Every review system is a queue. Changes arrive at some rate. Reviewers clear them at some rate. When arrivals exceed capacity for long enough, the backlog grows without limit and the wait for a review grows with it, no matter how nice the diff viewer is. Agents raise the arrival rate. That is the part of the story nobody disputes.

What a reviewer spends per change splits into two parts: reading the change, and reconstructing why it looks the way it does. Better diff tools shave the first part. Delta is a bet on the second. If the reasoning ships with the change, reconstruction gets cheaper, and capacity goes up without hiring. The figure below lets you set both parts and see what happens to a two-week backlog.

Play with the third preset and the honest result appears quickly. Attaching context only helps if reading the context costs less than rebuilding it. That is the objection one commenter raised in the Hacker News thread: "does this mean that along with the burnout I'm feeling with talking to my own agents I now need to try and consume and understand my teammates conversations with agents? Why is this better than a good pr description that distills completed work and explains why it was required?" A raw transcript is long and full of dead ends. Delta's answer is the change guide, a distilled walkthrough the agent writes for the reviewer, with the full thread available when a specific question needs it. Whether that guide is shorter to read than the reconstruction it replaces is the empirical question the beta will answer. Another commenter put the other side: compared to "3k lines of code in a PR with no history with vibes in the description," it "definitely 'feels' like something worth exploring."

Where the merge gate lives

A pull request is also a gate. The host will not run the merge until required checks pass and required approvals exist. That enforcement does not depend on anyone's judgment in the moment. It is a rule on the remote, and the person merging cannot talk their way past it.

Delta moves landing into the thread. Choosing Land Changes opens a dedicated Land subthread and runs your project's landing workflow, defined as a skill that, in the docs' words, "defines your checks, merge strategy, and publication steps." If exactly one eligible skill exists, the agent runs it. If there are several, the agent lists them and you pick. If there are none, the agent offers to help write one and asks for approval before writing it. On CI specifically, Zed's post says that for now "an agent can trigger a run with an existing CI provider and check the results before landing the change," and that content-based builds could bring CI-style verification into the thread later.

This is where the sharpest criticism in the thread landed. One reviewer wrote: "Having land as a skill seems weird to me. You could write in your land skill that it should make sure CI is passing, but I wouldn't want to leave it up to the LLM to decide if CI is passing. I'd rather that be a decision enforced by the git remote." The distinction is between an instruction and an enforcement point. A skill tells an agent what to do. A branch protection rule decides what is allowed to happen. An agent following a skill can misread a log, retry a flaky job until it goes green, or run a copy of the skill someone edited in the thread. A remote rule has none of those failure modes, because it is not reading anything.

Run it with only the two instruction gates and most of the bad changes land, because every one of those scenarios is an agent being wrong about something it was told to check. Add the three remote rules and the list collapses to one: the flaky suite that eventually goes green, which no merge gate catches because the check really did pass once. That one needs flake quarantine, not a stricter gate. That is not an argument against Delta. It is an argument about layering. Nothing in Delta's design stops you from requiring passing checks and fast-forward-only merges on the Git remote that sits underneath it, and the commenter's own conclusion was exactly that: set the remote "to only allow fast forward merges with checks passing." Let the landing skill drive the process and let the remote judge it.

Layering starts with the landing skill itself. Delta marks a skill as eligible for Land Changes with one frontmatter field; everything below the frontmatter is yours. Write the body so the skill drives the process and hands the decision to the remote:

---
name: land
description: >-
  Land this project's changes only when explicitly requested.
  Do not use for review, preparation, or skill installation.
metadata:
  delta-action: land
---

1. Push the thread's branch: git push origin HEAD
2. Open the pull request if none exists: gh pr create --fill
3. Queue the merge and let the remote decide:
   gh pr merge --auto --rebase --match-head-commit "$(git rev-parse HEAD)"
4. Report required checks without retrying failed jobs:
   gh pr checks --required --watch --fail-fast
5. Never pass --admin. If a check fails, stop and report its name.

Frontmatter from Delta's Configure a Land skill docs; the steps are ours, built from the gh pr merge and gh pr checks manuals. Not run here. --auto merges only after the branch's requirements are met, and --match-head-commit refuses the merge if the branch moved after the agent looked at it.

The requirements live in a ruleset on the default branch, created once by a person with admin rights:

gh api -X POST repos/OWNER/REPO/rulesets --input ruleset.json

{
  "name": "agent-landing-gate",
  "target": "branch",
  "enforcement": "active",
  "conditions": { "ref_name": { "include": ["~DEFAULT_BRANCH"], "exclude": [] } },
  "rules": [
    { "type": "pull_request", "parameters": {
        "required_approving_review_count": 1,
        "dismiss_stale_reviews_on_push": true,
        "require_code_owner_review": true,
        "require_last_push_approval": true,
        "required_review_thread_resolution": false,
        "allowed_merge_methods": ["rebase"] } },
    { "type": "required_status_checks", "parameters": {
        "strict_required_status_checks_policy": true,
        "required_status_checks": [ { "context": "test", "integration_id": 15368 } ] } },
    { "type": "required_linear_history" },
    { "type": "non_fast_forward" }
  ]
}

Field names from GitHub's repository rulesets REST docs; 15368 is the GitHub Actions app ID (gh api /apps/github-actions). Not applied here. Replace test with your check's name.

Three fields do the work an agent cannot. integration_id pins the check to the app that runs CI, so a status posted from somewhere else does not count. require_last_push_approval means whoever pushed last, including an agent's token, cannot supply the approval. strict_required_status_checks_policy makes the check run against the latest main, which closes the gap where a change passed on a stale base. Then protect the files that turn into agent instructions:

# .github/CODEOWNERS
/.agents/skills/   @your-org/platform
/.agents/prepare   @your-org/platform
/.delta/           @your-org/platform
/AGENTS.md         @your-org/platform
/.github/          @your-org/platform

Syntax from GitHub's About code owners; the paths are the ones Delta's Agentic Safety page says become agent instructions or run on mount. With require_code_owner_review on, an edit to the land skill needs the owning team's approval before it can reach main.

When it goes wrong

Delta is in early access, and its own safety page is blunt about the limits: "Delta does not have an agent permission system," and "Delta does not sandbox agents. An agent has unrestricted access to the device where it runs." Most of the failures worth planning for follow from that and from the thread-as-gate design.

Behaviors from Delta's Agentic Safety, Delta & Git, and review pages, checked September 25, 2026. The safety page says permissions, sandboxing, and worktree trust controls are on the roadmap.

Git is still underneath

The least dramatic sentence in the announcement may be the most important one for anyone thinking of trying it. The zed-industries/zed repository "will remain on GitHub for now because it's where our community finds issues and submits changes." Contributors are asked to share Delta threads alongside their pull requests, and "teammates who never open Delta still see a normal Git repository." Adoption can be one person at a time, and the output is still commits on a branch.

Zed is also open about the ambition. The post calls pull requests "the first part of the GitHub workflow we're leaving behind," names the practice they want in its place "continuous engineering," and says the next target is Git storage in DeltaDB. The team's framing: "Most contenders promise better uptime on top of the same old primitives: branches, commits, and diffs." Delta is free during the beta, with paid plans for individuals and teams promised and a free version kept permanently.

Adopting it without giving up the gate

The order matters, because each step assumes the one before it holds.

1. Put the gate on the remote first. Create the ruleset on the default branch before any agent can land anything. From then on, nothing the thread decides can merge a failing change.
2. Own the files that become instructions. Add the CODEOWNERS entries for .agents/skills/, .agents/prepare, .delta/, and AGENTS.md, so changes to what the agent is told go through a person.
3. Isolate the machine. Until Delta ships permissions and sandboxing, run it where there is nothing an unrestricted agent could damage: no deploy keys, no production credentials in the environment.
4. Write the land skill to queue, not to merge. Push, open the pull request, gh pr merge --auto, watch required checks, never --admin.
5. Review in review threads. Ask for the change guide, put the why questions to the agent that made the choices, submit a verdict, then Pull Changes.
6. Keep GitHub as the meeting point. Zed's own repository stays on GitHub, and Delta can add a thread link when the agent opens a pull request, so teammates who never open Delta still review the same change.
7. Watch the queue weekly. If agent changes arrive faster than your team clears them, attached context will not save you; cap how many agent changes can wait at once.

Teams not moving to Delta can take steps 1, 2, and 7 as they are and replace the review thread with the decision-log template. Zed's bet is that the thread becomes the unit of software work. The part of that bet that holds regardless of who wins is simpler: a change without its reasoning is half a change, and a gate that an agent can misread is not a gate.