When review leaves the pull request: agent threads vs diff-only review

Zed disabled pull requests on Delta's own repository and now builds Delta inside Delta. According to Zed's public beta post, 33 people have landed about 570 changes to main without PRs.

Reviewers join the original agent conversation and see the same worktrees. They can ask the agent why a Mutex won over an RwLock. They don't have to reverse-engineer a growing diff.

This post looks at where review happens. For the merge-time queue, see how agents raise PR volume.

Zed's case for review without PRs

Zed's point: agents made diffs much larger, and the diff leaves out the decisions behind the code. In their public beta post, they say stacking smaller branches helps you navigate. It still doesn't tell you why the code looks the way it does. A teammate's agent guessing at your reasoning is a weak substitute for the thread where you made those choices.

The New Stack coverage makes the same point. When the reasoning lives in an agent conversation, a pull request shows the result. Much of the path to it stays elsewhere.

Zed doesn't say every team must leave GitHub. Its editor repo stays on GitHub for community issues and contributions. Contributors can share Delta threads alongside PRs. Teammates who never open Delta still see a normal Git repository.

Most teams still review in PRs

Most teams will keep GitHub, GitLab and Bitbucket pull requests for now. In many orgs, PRs are where approval, CI and CODEOWNERS run.

So the useful question is narrower. Which part of the PR model already fails when agents write most of the code?

Diff-only review is what breaks

The PR can stay as the shipping checkpoint. What fails is review that consists only of a diff plus another comment stream.

When an agent writes the change, the intent, tradeoffs and dead ends often live in the thread. Rebuilding them from the patch is expensive. More bot comments on the PR can't restore context that was never in the diff.

Shared agent threads are one fix. Delta also describes review subthreads that carry the original agent context. Both keep the reviewer in the conversation that produced the code.

What review needs on any surface

Thread or PR, your reviewers need feedback grounded in your team's standards and the real context of the change.

AI code review only helps if the tool applies that bar early. Repo-aware review covers what a diff alone misses. This post adds one more need: keep the why when agents write the patch.

Where Revix fits

Revix is built for that gap: feedback grounded in your team's standards and the change's context, on the surface you already use.

A check for your next agent-heavy change

Ask these three questions. If the weak signal matches, your review is still diff-only.

If you want review grounded in your repository's standards on the PRs you already ship, connect a repo at revix.ai. Every team starts with a 14 day free trial, no card required.