A model reviewing a model is not verification
Pointing a second model at the first one's output feels like a control. It is a filter with correlated blind spots, and the confidence it manufactures is the dangerous part.
The proposal arrives in every organisation eventually, usually from someone smart and usually within a week of the review queue becoming visibly unsustainable. Reviewers cannot keep up. Models are cheap. Put a model on the review side and let it approve what it finds clean.
I want to be careful here, because there is a version of this that is genuinely useful and a version that is a governance disaster, and they look identical on a slide.
My position: a model reviewing a model is a filter, not a verifier. Use it to reduce what reaches a human. Never let it discharge the gate. The distinction is not pedantic, it is the difference between a control and a ritual.
Independence is what makes a check a check
The reason two engineers reviewing each other’s work catches things is not that there are two of them. It is that they are wrong in different directions. Different experience, different scars, different mental model of the system. The value of the second look is the non-overlap.
Two models drawn from similar training distributions, prompted with the same repository context, reasoning in similar ways, do not have that property. Where the first is confidently wrong, the second is disproportionately likely to be confidently wrong in the same place, because the error came from a shared prior rather than from a random slip.
This is the whole argument, and everything else is a consequence of it. A check whose failures correlate with the thing it is checking provides much less assurance than its pass rate suggests. Worse, it provides that reduced assurance while looking like a full check, which is the specific shape of hazard I care about.
Context blindness is the clearest example. An agent produces output that is internally coherent, references an API that does not exist in this repository, and violates a local convention that was never written down. A reviewing model reads that same repository, forms roughly the same impression of what the conventions are, and finds the change unobjectionable. The failure and the check share a cause.
What model review looks like
- A second opinion
- An independent check
- A reviewer that never tires
- Verification at scale
What it is
- A correlated opinion
- A check sharing the author's priors
- A tireless filter with a fixed blind spot
- Triage at scale, which is still worth having
What a second model is genuinely good at
I do not want this read as dismissal, because the useful applications are real and I would deploy them.
Mechanical defects. Off-by-one, unhandled null, resource not closed, a branch that cannot be reached. These are local, they do not require intent, and a model finds them faster and more consistently than a tired human at 4pm on a Thursday.
Local inconsistency. This function returns an error and the three beside it throw. This module logs at debug and the rest of the package logs at info. A model comparing a change to its immediate neighbourhood does well.
Missed cases. What happens when the list is empty, the timezone crosses a boundary, the string contains a character the parser does not expect. Enumeration is a strength.
Criteria conformance. Given written acceptance criteria and a diff, asking whether the diff plausibly satisfies each criterion is a well-shaped task with a checkable answer. We build this in GroundTruth and I will say plainly what it is: it raises a signal, and I do not think it should be the last thing standing between a change and production on a path that can hurt you. A verifier built on the same substrate as the author is a strong hint, not an independent witness.
None of those are the question review exists to answer, which is whether this change should exist in this system in this form.
Independence you can actually get
If correlated judgement is the problem, the answer is checks that do not share the author’s substrate at all.
Execution is the strongest one available. Tests that run, a type checker, a build, a migration applied against a copy of production shape, a property test with generated inputs. These are not opinions. They fail for mechanical reasons and their failures do not correlate with the model’s priors because they are not derived from priors at all.
Static analysis has the same property. So does a contract test against a real dependency. So, in a different way, does a canary that exposes the change to a small share of traffic and watches error rates, which substitutes empirical evidence for prediction entirely.
The ordering I would argue for is: mechanical evidence first, model filtering second, human judgement last and only on what survives.
The confidence is the harm
Here is the part that worries me more than the missed defects.
Stack Overflow’s 2025 survey found developer trust in AI output fell from roughly 40 percent to 29 percent. That fall is people calibrating correctly after looking closely. Now introduce a green tick from an automated reviewer on every pull request. What that tick does, reliably, is restore the trust that the falling number represents people having earned their way out of.
A reviewer who opens a change and sees “automated review passed, no issues found” reads less carefully than one who sees nothing. That is not a character flaw, it is how attention allocation works. So the intervention that was supposed to increase assurance decreases the assurance provided by the step it was meant to support, and the net can easily be negative.
If you deploy model review, I would present its output as findings and never as a verdict. A list of three things to look at is useful. A green tick is a sedative.
Where this breaks down
Correlation is an assumption, not a measurement. I have asserted that two models share blind spots. Different architectures, different training data and adversarial prompting genuinely reduce the overlap, and I do not know by how much. If somebody measured it and the correlation turned out to be modest, a good chunk of my argument weakens. Nobody has published the measurement I would want.
Human reviewers are correlated too. A team that hired from the same background, trained each other, and shares a house style has substantial overlap in what it fails to notice. Independence is a matter of degree everywhere, and I am holding model review to a standard human review does not meet either.
A correlated check still catches uncorrelated errors. A model that misses every convention violation may still catch the null dereference, and that is a real defect prevented. My argument is about how to read the pass signal, not about whether the check has value. It has value.
For some teams the alternative is nothing. A four-person team with an unmanageable queue is choosing between correlated review and unreviewed merges, not between correlated review and rigorous human review. In that comparison the filter wins easily, and telling them it is not real verification is technically correct and practically unhelpful.
And blocking on execution has its own cost. Tests, canaries and migration rehearsals are the independent checks I am recommending, and they are slow, flaky and expensive to maintain. Teams reach for model review partly because the mechanical infrastructure they should have built is missing or rotten. That is the actual problem in a lot of shops.
The takeaway
Two systems that share a prior agreeing with each other is not verification. It is one opinion, expressed twice, with a confidence interval nobody computed. The value of a second look comes from the non-overlap of failure modes, and that non-overlap is exactly what a second model does not provide.
Deploy it as a filter that reduces what reaches a human, backed by execution-based checks that fail for reasons unrelated to anybody’s priors. Present its findings, never its verdict. The green tick is the part that costs you.
If you take one thing into next week: look at how automated review results are displayed in your pull requests. If the dominant visual is a pass badge rather than a list of concerns, change the display before you change anything else.