Three AI code reviewers, same 18 PRs: two mostly found a subset of the third

A common argument for running several AI reviewers on one pull request is coverage: each model notices different things, so together they catch more. We expected to see that when we ran three reviewers on the same 18 pull requests.

We mostly did not. One reviewer raised 40 findings. The other two raised 7 and 2. Almost everything the two smaller reviewers found, the largest one found too.

This post separates what we observed directly from what depends on judging whether findings were right. The main result needs no judgment about whether findings were correct, only about which findings describe the same issue.

The setup

We took 18 merged public pull requests from Flask, Requests, Fastify, Got, Laravel and Gin, covering Python, TypeScript and JavaScript, PHP and Go.

Three reviewers ran on each one: claude-opus-5, gpt-5.5-2026-04-23 and gemini-3.1-pro-preview. All three received the same prompt for each pull request, built once. Context retrieval ran once, so every reviewer saw the same surrounding code.

What we observed directly

These numbers are counts. They do not depend on deciding whether any finding was correct.

That is a twentyfold difference in volume on identical input.

To measure overlap, findings that describe the same defect on the same pull request were grouped into one issue. Grouping is a judgment about whether two findings are the same, not about whether either is true. Two independent groupings came out at 40 and about 42 distinct issues. We use the first below.

• 8 of the 40 issues were raised by more than one reviewer.
• 1 was raised by all three: Got's tests had started depending on live network access to example.com.
• All 9 findings from the two smaller reviewers were issues the largest reviewer also raised. Under the stricter grouping, 2 of the 9 were not, so the two smaller reviewers added at most 2 issues.
• 32 of the 40 issues came from the largest reviewer alone.

So "agreement is rare" is true from one side only. From the largest reviewer's side, most of what it said went uncorroborated. From the smaller reviewers' side, nearly everything they said was corroborated.

This is not the shape every comparison finds. A public four-tool study of 146 merged pull requests reported 93.4% of 617 locations caught by exactly one reviewer. Different tools, different code, a different result. Overlap is something to measure on your own changes, not assume.

Where they overlapped, they did not always agree

Overlap means two reviewers looked at the same thing. It does not mean they reached the same conclusion.

In one Laravel pull request, two reviewers flagged array_last(). One said it might not exist on supported PHP versions. The other said it was undefined and rated that high severity. Both claims can be checked against the repository: array_last() is native in PHP 8.5, the repository polyfills it (composer.json, line 61), and it is used throughout the codebase, including inside Arr::last(). A majority vote between those two reviewers would have sent someone to fix working code.

In a Got pull request, two reviewers pointed at the same line of timed-out.ts and described opposite failures.

Those disagreements were more informative than the agreements. They marked exactly the claims worth checking.

What depends on adjudication

The rest of this section relies on judging findings, so treat it with more caution. The method and its weaknesses are below.

Of the 49 findings, 45 were judged accurate, 2 plausible but unproven and 2 wrong. Accurate is not the same as worth a developer's time. Against a strict definition (a demonstrated failure under a supported contract, shown by a reproduction or a full code trace), two judges agreed on 7 issues. All 7 were raised by the largest reviewer; 2 of them were also raised by another reviewer.

That suggests the same thing as the raw overlap. On these pull requests, extra reviewers did not surface important issues the largest one missed. It also says most accurate findings on mature, already-reviewed code are not worth stopping for. We do not read anything here as a ranking of the models: two of them made too few findings to rank, and finding count is not quality.

What this means for multi-reviewer review

On these 18 pull requests, the second and third reviewers bought little coverage. What they did provide was a cross-check. Where they agreed, a finding had independent corroboration, which still is not proof. Where they disagreed, they pointed at the claim to verify first.

That matches how Veridu uses its two reviewers. A finding can block a merge only when both report the same defect at the same place and both rate it serious enough to block. Findings from one reviewer are still shown, because in this corpus that is where most of the important issues were. Each finding is asked to state what it checked and what it concluded, so a claim like the array_last() one can be verified in seconds.

Coverage of the code that matters came from somewhere else. In our first post, both reviewers missed a bug that shipped in Laravel until we gave them the subclass that the change broke, from a file the pull request never touched. We did not test whether more reviewers without that context would have found it. Adding the context let both of the reviewers we had find it.

Method and limits

• Adjudication was done by a model, not by independent humans. Findings were judged blind, with reviewer names removed and order shuffled, against the code at each pull request's commit. The judge was one of the models under test. A different model independently re-checked the claims that could change the result and overturned one. The two materiality judges were also models; they agreed on 84% of findings (Cohen's kappa 0.61). None of this is equivalent to human validation. The overlap results above do not depend on it.
• The sample is small. 18 pull requests; two reviewers made 2 and 7 findings.
• The pull requests were merged, mature open-source changes. Code still in progress, especially private code, may produce more findings and a different overlap. That is the next thing worth measuring.
• Reviewer-assigned severity skewed low: 24 low, 22 medium, 3 high and no critical findings. That makes the corpus weak for measuring missed bugs and better for measuring noise.
• Models change. These were the versions available in September 2026.

Try Veridu on your own pull request, or see a real review first.