The self-review problem
Published July 28, 2026 · by the AQ team
The self-review problem is what happens when the person who prompts an AI coding agent is also the only person who reviews what it produced. The work merges with one set of eyes on it, and that set of eyes belongs to the least objective reviewer available: the person who told the agent what to do, watched it do it, and expects the result to be correct. As of July 2026 this is not a hypothetical: a LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs, the same developer both reviewed and modified the agent's contribution. Only about one in eight agentic workflows involved more than one human at all.
The same analysis found the isolation runs deeper than review: in 70 percent of the projects studied, fewer than one in five contributors participated in any agentic workflow. Agents were sold as tireless new teammates. Measured in the wild, they are mostly a private tool, used alone, reviewed alone.
How the loop closed
Nobody decided to remove the second reviewer. It happened structurally, in three steps:
- Coding moved into a private loop. An agent session lives in one person's terminal. The prompts, the corrections, the failed attempts, the moment the agent went down the wrong path and got pulled back: all of it happens in a place exactly one person can see.
- The PR became the only shared artifact. The one thing that escapes the private loop is the finished diff. Everything that would let a second person evaluate the work in context stays behind.
- The prompter became the reviewer. When you asked for the change, watched it being made, and skimmed the output as it streamed by, "reviewing the PR" feels redundant. So in four out of five cases, nobody else does it.
Reviewing your own agent's PR is close to reviewing your own code, with an extra trap: you know what you asked for, so you see what you expect. The characteristic agent failure is code that looks plausible and does something subtly different from the request. The person least equipped to catch that is the person who made the request, because their reading of the diff is contaminated by their memory of the prompt.
Why the obvious fix misses
The reflexive response is policy: require a second approver on agent PRs. It helps at the margin and it is better than nothing, but it stacks process on the wrong artifact. A second reviewer staring at the same diff still cannot see:
- What was actually asked. A correct-looking diff implementing the wrong interpretation of the ticket is invisible at the diff level.
- What the agent tried and abandoned. Dead ends are signal: they mark the parts of the codebase the agent found confusing, which is where the surviving code deserves the closest reading.
- What the operator overrode or ignored. The moment a person waves the agent past a warning is precisely the moment worth a second opinion, and it leaves no trace in the diff.
- Whether the code was ever run. A diff does not show whether anyone clicked the feature.
The decisions that determine whether agent work is good live in the session, not in the diff. A review process that cannot see the session is auditing the residue of the work rather than the work.
What actually works: review the session
The fix is to make the run itself reviewable, a practice worth naming: session review. Concretely, three changes:
- Sessions happen in a shared place. If the agent runs where a teammate can open it (live or after the fact), the private loop opens. Watching how a colleague scoped the task, corrected the drift, and decided when to stop is also how agent skill spreads through a team, which is the "team-level learning over solo experimentation" the LeadDev piece argues engineering leaders should be driving.
- A second person is the default on agent PRs, with the session as context. Not as a checkbox on the diff, but as someone who can read the brief, skim the scrollback, and run the result. Review effort concentrates where the session shows the agent struggled.
- Behavior gets reviewed, not just text. Someone other than the operator uses the running result before it merges. Most plausible-but-wrong agent code fails within a minute of someone actually exercising it.
Where AQ fits
AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. It is, structurally, the shared place the fix requires. Every agent session runs in a workspace its owner can open to the whole team or share with specific people: the terminal is the live session record, scrollback included, the editor shows the working tree, the live preview lets a reviewer click the feature, and the PRs the agent opens are tracked on the workspace that produced them. The review pattern this enables is described in reviewing AI agent work, and the category it belongs to in multiplayer coding agents.
The self-review problem is not a discipline failure, and it will not be fixed by asking individuals to try harder, because it is a structural property of where agent sessions live. Move the session somewhere shared, and the second set of eyes has somewhere to look.
Frequently asked questions
What is the self-review problem?
It is the pattern where the person who prompts an AI coding agent is also the only person who evaluates its output. The measured shape of it, per a July 2026 LeadDev analysis of 25,264 agent-generated PRs: in 79 percent of agentic pull requests the same developer both reviewed and modified the agent's contribution, with nobody else in the loop.
Is reviewing your own agent's PR really riskier than reviewing your own code?
It carries the same objectivity problem plus one more: expectation bias. You know what you asked the agent for, so you read the diff as confirmation. The characteristic agent failure, plausible-looking code that does something subtly different from the request, is exactly the failure that bias hides.
Does requiring a second approver on agent PRs solve it?
It helps, but a second reviewer limited to the diff cannot see the original brief, the agent's dead ends, or what the operator overrode mid-run, and those are where agent work goes wrong. The stronger fix is session review: giving the second person access to the run itself, not just its residue.
What should a second reviewer look at besides the diff?
Four things: the original instruction (does the diff implement what was actually asked), the session scrollback (where did the agent struggle or get corrected), anything the operator skipped past, and the running behavior of the result. In a shared workspace all four are one link away.