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

Pull requests are not obsolete. The PR as a wrapper around one human-written diff is straining under agent volume, and Zed's Delta is the first serious attempt to replace that wrapper. Zed is right about the problem and premature about the conclusion: change the review unit, the verification and the merge path, but keep a named human owning risky code.

Agents produce many small changes, and a review unit designed for a person's afternoon of work fits them badly. That is the real argument, and it is worth taking seriously before deciding what to keep.

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." Zed says threads "will be the new fundamental unit of software development," 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. Commits remain the checkpoints you push, pull and build from. Zed also reports that 33 of its people have landed 570 changes to main since it turned off pull requests for that work.

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 third-party agent harnesses starting with Claude Code, 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 public zed-industries/zed repository stays on GitHub "for now," 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 smaller units, not faster reading. 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 a control, not a workflow artifact. 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.

Questions people ask

Are pull requests obsolete because of AI coding agents?

No. Agents make the classic pull request, one large human diff waiting on one reviewer, a poor fit, because review latency becomes the bottleneck. The answer is smaller stacked changes, required checks that actually fail, and provenance trailers. Mandatory human approval on auth, billing, infrastructure and CI config still matters, because it is a security control rather than a habit of the old workflow.

What is Zed Delta?

Delta is Zed's multiplayer environment for coding with agents and reviewing what they build. Work happens in threads that keep the agent conversation and the worktree together, backed by DeltaDB, which records incremental deltas between Git commits. It entered public beta on September 16, 2026, runs on macOS, Linux, Windows and the web, and is free during the beta with paid plans announced.

Does Delta replace GitHub branch protection or CI?

Not today. Zed says agents can trigger runs on your existing CI provider, and calls CI-style verification inside the thread a longer-term goal. Zed's own public repository stays on GitHub. Until that changes, keep rulesets, required status checks and CODEOWNERS on your Git host as the system of record, and treat Delta as the place where review conversation happens.

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.

Sources

• Zed blog: Introducing Delta (August 12, 2026)
• Zed blog: Replace PRs with Delta, now in public beta (September 16, 2026)
• GitHub Docs: REST API endpoints for repository rules
• GitHub Docs: About code owners