On August 28 a reviewer blocked the same pull request for the third time. An agent in our fleet had been asked to restructure a codebase. It reported success, the build was green, and the diff looked tidy. The reviewer, a separate agent on a different model, opened the files the summary never mentioned and found that about 9,500 lines had been moved into folders named Legacy, with stubs left where the real code used to be. The build stayed green. Nothing worked.
The author would have approved that change. It had already reported it as done. Here is the lesson, stated plainly: when every agent in a fleet pushes as the same identity, an agent approving its own pull request looks exactly like a review. The fix is structural, and it has two parts: an approval counts only when it comes from a session other than the author, and the reviewer runs on a different model and never sees the author's reasoning. By September 1 we had the second part running. The first we had only at the level of GitHub accounts, which is the level where a fleet's authors all look the same.
One account, many authors
Plenty of agent fleets push under one GitHub account: a machine user, or the founder's own login. Ours did. That single choice quietly disables the review rules GitHub already has.
GitHub's documentation is direct about it: "Pull request authors cannot approve their own pull requests" (GitHub Docs, approving a pull request with required reviews). The stricter branch rule requires that the most recent push "be approved by someone other than the person who pushed it" (GitHub Docs, about protected branches). Both rules count accounts. Ten agents on one account are one person to GitHub, so none of them can file a formal approval on another's work.
The review then moves into comments. A reviewer agent writes "Reviewed, no blockers, approve." So can the author, in the same words, from the same account, a minute after it opens the PR. In the pull request timeline the two comments are indistinguishable. And by default "the restrictions of a branch protection rule don't apply to people with admin permissions to the repository" (the same page), which is often the account the fleet runs on. The merge decision ends up resting on a sentence any session in the fleet can post about itself.
The same model shares the author's blind spots
The obvious patch is a second session: same model, fresh context, told to review. The research gives a reason to test a reviewer on a different model before settling for that. The studies below measure models grading answers; whether the effect carries over to code review is untested.
In the MT-Bench study, Zheng and colleagues measured how often a model acting as judge picked its own answers. GPT-4 favored itself with a 10 percent higher win rate than human judges gave it, and Claude-v1 favored itself by 25 percent, though both also favored some other models, and GPT-3.5 did not favor itself (Zheng et al., "Judging LLM-as-a-Judge," arXiv, June 2023). The authors are careful that their data was too limited to call it a settled bias. A controlled follow-up went further. Panickssery, Bowman and Feng found that LLM evaluators score their own outputs higher than others' even when human annotators rate them as similar in quality, and that a model's ability to recognize its own text tracks, linearly, how strongly it prefers it (Panickssery et al., "LLM Evaluators Recognize and Favor Their Own Generations," arXiv, April 2024).
There is also the plain question of whether a model catches its own mistakes when nobody else is looking. Huang and colleagues report that "LLMs struggle to self-correct their responses without external feedback," and that accuracy sometimes drops after a model tries (Huang et al., "Large Language Models Cannot Self-Correct Reasoning Yet," arXiv, October 2023).
Our own evidence is narrower: one pull request, described below. What we can say is that a second session on the same model reads the author's code with the author's habits. If it also reads the author's transcript, it inherits the author's story: "moved the old code to Legacy to clarify the structure" sounds like a plan when you have just read the reasoning that produced it. The reviewer that caught our restructure started from the diff and the repository, on a different model, with none of that narrative.
What the reviewer caught
The restructure on August 28 is the clearest case, because every surface signal said it was fine.
The reviewer blocked it three times on the same question: does the code the features call still do anything? Each time the answer was no. A self-approval would have merged it on the first round.
The honest limits. A cross-model reviewer is a second run, so every PR costs more model time. It can be wrong, and it can block good work; its findings are claims to check, the same as the author's. It caught these problems because it read the files the diff never opened, so a reviewer told to skim the diff would have missed them too. CI still runs on every change. The restructure passed CI, which is the point of the story, and CI still catches the failures a reviewer is worst at.
The two rules
Everything above reduces to two rules. One we ran by September 1; the other we had only in a weaker form.
An approval from the author does not count. What we had on September 1 checks this by GitHub account. Since August 30, our own history shows, a run whose pull request has formal approvals only from the author's login is marked failed instead of finished. That catches an agent that formally approves its own pull request through an admin or token bypass. It misses the case this post is about. It reads only formal GitHub reviews, so a comment that says "approve" never reaches it; when it cannot tell (no formal approval, a failed API call) it lets the run through; and on a shared account the author's login is every agent's login. The rule we are moving to asks which session wrote the pull request and which session approved it, and rejects the approval when they are the same. That is GitHub's own rule, applied at the level where our authors actually differ.
The reviewer is a different session, and preferably a different model or harness, that never saw the author's reasoning. It gets the task, the diff and the repository. It does not get the transcript or the author's summary of what it did. We prefer a different model because the studies above suggest a judge favors work that reads like its own, and because the reviewer that caught our restructure was one.
You could get the first rule from GitHub alone by giving every agent its own machine account, and for a fleet of three that is a reasonable answer. It multiplies the accounts, tokens and permissions you have to manage as the fleet grows, and it still says nothing about which model did the reviewing. Recording the session and the model on every pull request and every approval would answer both questions with the identity the fleet already has, and that record is the next piece we are building.
This is the review variable from Every Agent Demo Hides the Same Number made concrete. In Agents Are Eating the Org Chart I argued that review rate caps what a fleet of agents can produce. A review the author can perform on itself adds no review capacity at all.
Where Rush fits
Rush runs a coding agent as a cloud run in a cloud sandbox. That makes the second rule cheap to follow. The author is one run; the reviewer is another run on another model, in the other harness (Claude Code or Codex), started with what you send it: the pull request, and none of the author's context. Each run's trajectory is kept, so when the reviewer blocks a change you can read what it looked at.
The author is the one party in the loop that already believes the change is correct. Give the approval to someone who has to find that out.
