Why Your Reviewer Should Work for a Different Vendor

This isn't a hypothetical failure mode. It's the well-documented reason safety-critical engineering stopped trusting single-source redundancy decades ago, and it's directly applicable to how coding agents get reviewed today.

The Experiment That Started This

In the 1980s, John Knight and Nancy Leveson ran an experiment that reshaped how the software industry thinks about redundancy. The premise of "N-version programming" was simple and appealing: have several independent teams build the same system from the same specification, run the versions in parallel, and let them vote on the answer. If one version has a bug, the others outvote it.

Knight and Leveson found that independence rarely held. Teams working from the same specification, in the same era, with overlapping training and reference material, tended to make the same mistakes on the same inputs. The specification itself was the shared root cause - wherever it was ambiguous or silent, independently-built versions misinterpreted it in correlated ways. Redundancy without genuine diversity didn't eliminate the failure. Instead, it made the failure show up in multiple places at once.

What Actually Works: Dissimilar Redundancy

Aviation took the lesson further than software did, because aviation couldn't afford not to. Airbus's flight control computers run on different processors, from different vendors, using different software written by different teams in different languages - the A320 uses five dissimilar computers running four dissimilar software packages. Boeing's 777 primary flight computers each contain three different processors manufactured by three different companies. The point isn't redundancy for its own sake; a triple-checked answer from three copies of the same design still fails the same way three times. The point is that a defect baked into one vendor's silicon or one team's interpretation of the spec has no reason to also exist in a different vendor's silicon or a different team's interpretation.

That's dissimilar redundancy, and it's a stronger property than redundancy alone. Cross channel monitoring only catches a fault if the fault doesn't already appear identically on every channel being monitored.

Same-Model Review Is Correlated, Not Independent

Ask a model to review code it wrote - or code written by a sibling instance of the same model - and you're running the software equivalent of N-version programming with a single version doing all N votes. Whatever the model systematically misunderstands about a pattern, a security implication, or an edge case, it misunderstands identically at write time and at review time. The training is the same. The defaults are the same. The things it doesn't know to ask about are the same things it didn't know to ask about thirty seconds earlier. A second pass through identical reasoning finds typos and obvious slips. It structurally cannot find the failure modes that came from how that model reasons in the first place.

A different vendor's model has a different training mix, different safety tuning, different defaults, and different blind spots - not necessarily better ones, but different ones, which is the entire property that matters. It's more likely to ask "why is this endpoint unauthenticated" precisely because it wasn't the one that decided the endpoint didn't need authentication.

Building the Diversity In, Not Bolting It On

The practical version of this is narrower than it sounds. It doesn't require a committee or a vote across five models - it requires one thing: the reviewer isn't the builder, and isn't running the builder's model either. One independent review conversation, from a different vendor where one is available, with findings resolved in that same conversation and the conclusion recorded where the change lives. That's the whole mechanism. It costs one extra model call and buys back exactly the failure mode that same-model review cannot see by construction.

The aviation industry didn't add dissimilar computers because triple redundancy felt more thorough. It added them because the math on correlated failure is unforgiving, and the only way to break the correlation is to break the shared origin. Code review is smaller stakes than flight control, but the mechanism is identical: diversity of origin is what makes redundancy actually redundant.