All posts

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

Zed Delta disabled PRs on its own repo and landed about 570 changes in shared agent threads. Why diff-only review breaks when agents write most of the code, and what still matters on any surface.

Oscar Estudillo
Title card reading Context, not comments. Schematic of an agent thread becoming shared context that arrives with the change at review.

Zed just disabled pull requests on Delta's own repository. They now collaborate on Delta inside Delta.

Since then, 33 people have landed about 570 changes to main without PRs. Reviewers join the original agent conversation. They see the same worktrees. They can ask the same agent why a Mutex won over an RwLock, instead of reverse-engineering a growing diff.

That is a different surface from the merge-time queue we wrote about when agents raise PR volume. Here the bet is about where review happens.

What Zed is arguing

In their public beta post, Zed says agents made diffs mushroom. Stacking smaller branches helps navigation. It still does not supply the decisions behind the code. A teammate's agent guessing how you got there is a weak substitute for the thread where those choices were made.

The New Stack coverage puts the same point in industry terms: when reasoning lives in a conversation with an agent, a pull request shows the result and leaves much of the journey elsewhere.

Zed is not claiming every team must leave GitHub tomorrow. Their own 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 of us still live on PRs

GitHub and Bitbucket pull requests are not going away for most teams tomorrow. PR-native review is still how approval, CI, and CODEOWNERS work in a lot of orgs.

So the useful question is not "delete PRs this week." It is what part of the PR model is already failing when agents write most of the code.

Diff-only review is the broken part

A pull request can still be the shipping checkpoint. The weak step is review that is only a diff plus another comment stream.

When an agent produced the change, the intent, tradeoffs, and dead ends often lived in the thread. Reconstructing that from the patch is expensive. Adding more bot comments on the PR does not restore the context that was never in the diff.

Shared agent threads are one answer. Dedicated review subthreads with the original agent context, as Delta describes, are another shape of the same idea: keep the reviewer in the conversation that produced the code.

What still matters on any surface

Whatever surface wins, thread or PR comment stream, you still need feedback grounded in your team's standards and the real context of the change.

What is AI code review only helps if the tool applies that bar early. Day-one team standards is about teaching the bar without a hand-maintained rule list. This post is about not losing the why when agents author the patch.

That is the gap Revix is built for. Feedback grounded in your team's standards and the real context of the change, on the surface you already use.

A simple check for your next agent-heavy change

QuestionWeak signal
Where did the decisions for this change happen?Only in a private agent chat the reviewer never saw
What does the reviewer get first?A large diff with no path through the tradeoffs
What would fix a stuck review?More comments on the PR, with no more context

Are you still reviewing agent output mainly as a diff, or as a thread?

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.

Frequently asked questions

Delta puts collaboration in shared agent threads. Reviewers join the original agent conversation and worktrees instead of reconstructing intent from a growing pull request diff.