Zed Delta and the Pull Request: Obsolete, or Just Overloaded?

Pull requests are not obsolete, but the pull request as a wrapper around one human-written diff is straining, and Zed's Delta is the first serious attempt to replace the wrapper. We think Zed is right about the problem and premature about the conclusion. Agents produce many small changes, and a review unit designed for a person's afternoon of work fits them badly. What has to change is the unit, the verification, and the merge path. What must not change is that a named human owns risky code before it lands.

What Delta actually is, and what Zed claims#

Zed announced Delta on August 12, 2026 as "a multiplayer environment for coding with agents and reviewing what they build," and moved it to public beta on September 16 under the headline "Replace PRs with Delta." The fundamental unit is a thread, not a branch and a pull request. You invite teammates into a conversation with an agent, and Zed says collaboration "doesn't depend on committing and pushing code." Under it sits DeltaDB, which Zed describes as extending Git's content-based versioning with incremental versions based on deltas, capturing edits and conversations between your commits.

Review happens in the thread. Reviewers can comment on the conversation or any line of code, comments stay anchored as the code evolves, and a review can get its own subthread with an isolated copy of the parent's worktrees. A reviewer can request a revision or fix it with an agent. Delta runs on macOS, Linux, Windows and in a browser, connects to Claude Code and other agent harnesses, and is free during the beta, with paid plans promised and a free tier guaranteed to remain.

The limits matter as much as the pitch. Zed's own repository stays on GitHub, because that is where its community files issues, and Delta is meant to work alongside it. On CI, Zed says agents can trigger a run with an existing provider, and that content-based builds bringing CI-style verification into the thread are a longer-term goal. Delta does not claim to have replaced your pipeline. The details here come from Zed's own posts.

The pull request was built to gate human diffs#

A pull request assumes a scarce author. Someone spent hours on a branch, so a reviewer spending twenty minutes reading it is a fair trade, and the PR page is where discussion, approval and status checks meet. That economy breaks when an agent opens twelve changes before lunch. Review latency becomes the bottleneck, reviewers skim, and approval turns into a rubber stamp on diffs nobody read closely.

Zed is attacking the right layer. Moving review into the place where the change was made, with the conversation attached, gives a reviewer the intent that a bare diff lacks. We think that is a real improvement, and it is the part of Delta we would watch.

Smaller units and stacked changes beat bigger reviews#

The fix for volume is not faster reading, it is smaller units. Ask agents for one concern per change, and stack them so each is reviewable alone and lands in order. You can do this with plain Git today, and it works whether or not you adopt anything new.

# one concern per branch, each based on the previous one
$ git switch -c agent/rename-config main
$ git commit -am "Rename Config to Settings"
$ git switch -c agent/use-settings-in-api
$ git commit -am "Use Settings in API handlers"
$ git push --force-with-lease origin agent/rename-config agent/use-settings-in-api

A thread that mixes idea, implementation and review does not by itself produce small, revertible units. That discipline is yours.

Verification has to replace reading#

You cannot read your way through agent volume, so make the machine do more of the gating. Required checks should be the real acceptance test: unit tests, type checks, linters, and for risky areas contract or integration tests. If an agent change can merge on a green build alone, the build is your reviewer, so it had better be a good one. This is also where running agents inside CI pipelines gets its value: the agent proposes, the pipeline decides.

Provenance belongs here too. Record which agent and which prompt produced a change, in a commit trailer at minimum, so a bad batch can be found and reverted as a batch. Zed's announcements do not claim to solve this.

Keep the gate: rulesets and CODEOWNERS#

Here we disagree with the "obsolete" framing. Human approval on risky paths is not a workflow artifact, it is a control. Payments, auth, infrastructure and CI config should require a named owner regardless of who or what wrote the diff, which is the same instinct behind treating agent access as a security boundary.

# .github/CODEOWNERS
/infra/          @acme/platform
/.github/        @acme/platform
/services/auth/  @acme/security
/services/billing/ @acme/payments

Then enforce it with a repository ruleset, not a convention:

$ gh api repos/acme/shop/rulesets --method POST --input - <<'JSON'
{
  "name": "protect-default",
  "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": true } },
    { "type": "required_status_checks", "parameters": {
        "strict_required_status_checks_policy": true,
        "required_status_checks": [ { "context": "test" } ] } },
    { "type": "required_linear_history" }
  ]
}
JSON

Which platform hosts this matters less than people think, as the GitHub Actions and GitLab CI comparison shows: both can express the same gates. The point is that the gate lives in the platform, not in anyone's memory.

The decision, concretely#

• Should you adopt Delta today? Try it on a side project or an agent-heavy prototype, since it is a public beta with pricing still to come. Do not move a regulated codebase onto it.
• Should you drop pull requests because agents write the code? No. Keep them, or an equivalent gate, on anything customer-facing, and shrink the unit instead.
• What should replace reading every diff? Required checks that actually fail, plus small stacked changes and provenance trailers.
• Which paths keep mandatory human approval? Auth, billing, infrastructure and CI config, enforced by CODEOWNERS and a ruleset.

The call we'd make#

Treat Delta as a useful experiment in where review should live, and keep your existing Git host as the system of record until Zed shows its verification story, not just its collaboration story. Whatever tool you use, shrink the unit of change, put your trust in required checks, and keep a named human on the paths that can hurt you. The wrapper may change. The gate should not.