AI's Second Opinion: When Rival Models Disagree

The scarcest resource in a company that runs on AI is no longer analysis or output — those got cheap almost overnight. It is the judgment of the person at the top. Most of what an AI produces in a day doesn't need that judgment at all; a small, load-bearing slice does. The whole problem is telling the two apart.

So I set two AIs from rival labs against each other. Claude Code does the work. Then Claude hands the work to OpenAI's Codex, trained by a different company with its own blind spots, and tells it to find what's wrong. Only what the two of them can't settle between themselves reaches me.

Over a single day of building this website, the setup earned its keep. The pair caught a figure that quietly contradicted the essay it illustrated and found a flawed test that checked stale output rather than a fresh build. And on one question — the color of a diagram — they flatly disagreed in a way neither could win on the evidence. That single deadlock, not the clean catches, is the reason to build the thing: it was the one decision in the day's work that actually needed me.

On most days, the two models trade places; neither is reliably the smarter. Their value is that they fail in different places. Pointed at an ear-training app I'm also building, the same setup found a bug Claude had written and couldn't see in its own work — one that Codex caught in seconds. What you're building for is independence and diversity of thought, not raw intelligence.

The takeaway: A second AI from a rival provider is worth running not because it is smarter, but because its blind spots don't match the first model's. Treat their agreement as evidence, not proof. Treat a genuine, evidence-backed disagreement they can't resolve as the signal worth acting on — it points you to the one spot that actually needs your judgment.

I've written before about the mechanics of this — running a second model as the reviewer of the first, the guardian pattern where a fresh agent checks the work, running one artifact through two models to find where they disagree. None of it is exotic anymore. OpenAI now ships an official plugin that drops Codex into Claude Code as a reviewer. The commodity version of the advice — "don't let an AI grade its own homework, use a second one, it catches more bugs" — is everywhere.

The commodity version is also the shallow version. It treats the second model as a better bug-finder. But pointed at each other, two rival models do something a CEO will recognize: they surface the one place in a day's work where a human still has to decide, and let the rest run.

Independence Is the Asset, Not Intelligence

Auditors have known this for a century. You don't get a second signature on a wire transfer because the second person is smarter than the first. You get it because they're a different person, with a different view, less likely to make the same mistake. Separation of duties, four-eyes approval, the independent audit — these are controls, and what makes them work is decorrelation, not talent.

A model reviewing its own output is the same as an accountant checking their own math. It shares its own assumptions and training data. Self-critique — a model grading itself against written rules — works, but it doesn't bring any different training. Ask it to find its own mistake, and it often just doesn't see it: the blind spot that produced the error is the same one that hides it.

A model from a different lab is a genuinely separate view. Anthropic's Claude and OpenAI's models were trained on different data, tuned by different teams, and fail in different places. When one of them misses something, the odds that the other misses the same thing are lower than for two runs of the same model. That is the entire value: an uncorrelated reviewer. And for catching your own blind spots, uncorrelated beats smart.

For a solo operator, this is the check you structurally lack. A team has the skeptic in the next chair who says, "Wait, are we sure that's right?" A one-person company doesn't — until now. Two frontier models debating each other are the closest a solo founder gets to a team of rivals, at the cost of a second subscription.

This isn't only a solo trick. On a team, the same layer changes what reaches a person at all. Run the rival-model pass before every human review — the pull request before an engineer opens it, the draft before an editor reads it, the analysis before it goes up the chain — and the work that lands on a reviewer's desk has already survived an independent adversary. The routine mistakes are caught and fixed before anyone spends attention on them, so what a human sees is more fully baked: fewer defects left to find, fewer review-and-rework rounds, fewer things that bounce back a week later. Your scarcest reviewers spend their judgment on the calls that need it, instead of catching what a second model would have caught for a few cents.

Treat Agreement As Unverified

When your two models agree, it is tempting to relax. Agreement, by itself, isn't proof. Two models — like two people — can land on the same plausible, confident, wrong answer, and a debate between them can even harden it, each talking the other into a shared mistake.

So don't spend the same rigor on everything. Decide which aspects of quality actually matter for the work in front of you — correctness, data integrity, security, the parts of a product a customer would revolt over — the same call I've written about in defining what quality means for your product. On those dimensions, weigh the models' agreement by its evidence, not its confidence: two converging on the same line, each with its own reasoning and a citation you can check, is a real signal; two both saying "looks fine" with nothing to inspect is not. Where the stakes are highest, give even a confident agreement a spot check — everywhere else, let it run.

The Disagreement Is the Deliverable

An unresolved, evidence-backed disagreement is the exchange working, not breaking down. It marks the exact coordinate where the two most capable tools you own cannot settle the question — which is where your judgment is actually required, and often, the only place it is.

None of this is a new idea; it's how every functioning organization already runs. A CEO doesn't read every email, attend every meeting, or see every detail of a product. You build an organization precisely so that only the decisions that genuinely need you climb to your desk: QA surfaces the real defects and not the typos, the board sees board-level calls and not every operational choice, and a second signature stops the wire the first signer waved through.

A leader who reviews everything has failed to build the system, not succeeded at diligence. Two rival models automate that discipline across your team's work: the easy questions and the easy-to-find defects get resolved in a single pass, so nothing routine waits on a person to notice it. The human's attention is left for the decisions that are genuinely contested.

It's the same posture I take with clients: diagnose before you prescribe, and spend your effort where the real uncertainty lives, not where the work merely looks busy. Two rival models handle the questions made certain by their context and surface the important decisions for your review.

To make that concrete: earlier, while wiring the diagrams for another essay on this site, Claude and Codex deadlocked on a color. Codex insisted that a diagram stroke failed a contrast standard and had to be darkened. Claude argued that the color was the established brand accent and that changing it would break consistency across the site. Both were right about their own half, and neither could win on the evidence — one was citing an accessibility rule, the other a design system. So it came to me, and I made the call — a darker "diagram ink" that met the contrast rule without touching the brand's conversion color. The two models didn't solve it, because it's a judgment call their context doesn't cover. They left the decision up to me, and then updated the context with the new information.

The reviewer gets things wrong, and that's the point. In the same batch of work, Codex insisted that two of the figures were already broken; Claude checked and showed they rendered fine, and Codex withdrew the claim on the next pass. It took three passes before the review settled — each round confirming the last round's fixes and surfacing something new the changes had exposed, down to a stale rule buried in the project's own style guide that now contradicted itself. All of that argument ran without me; only the color deadlock did. That back-and-forth is the mechanism working, not failing. A reviewer you can't argue with is just a second author. The one worth wiring in will press a claim, concede when it's shown wrong, and hold firm when it isn't.

Codify It, Don't Improvise It

The version of this that changes how much you get done is not "sometimes I ask the other model." It's turning the habit into a tool that runs the same way every time — so I built one. A skill, in the Claude Code sense: a short, reusable procedure the agent invokes on command, the way I've written about capturing the systems your team builds instead of re-deriving them each session.

Three principles do the real work. First, the reviewer is told to refute, not review — agreeableness is the enemy, and its job is to find what's wrong. Second, and most important, every finding it returns must include evidence: a line number, a named standard, and a reproduction. That one rule is what keeps the exchange from decaying into two models trading opinions, and it's what lets me adjudicate by weighing proof instead of vibes. Third, nothing the reviewer flags is trusted until it's checked against the real artifact — the reviewer is a source of leads, not a source of truth.

Around those principles, the mechanics are deliberately dull, which is the point — the discipline lives in the principles, not the plumbing. The tool hands the second model the work under review, collects a structured verdict, and routes only the substantiated deadlocks to me. Fittingly, I built and hardened it the same way it now works: each model reviewing the other's work on the tool itself.

A companion skill covers the other half of crossing model boundaries: the capability that the first model lacks. Claude Code can't render an image; Codex can. The illustrations across these essays were made that way — Claude directing, Codex drawing. Useful, but that's routing, not judgment. The governance value lives in the criticism.

What It Caught

Specifics, because this is easy to nod along to and hard to believe until you see the receipts.

In the ear-training app, the catches that justified the second opinion weren't the typos — a linter finds those. They were the errors the author was too close to see. It caught a data-loss bug in cloud sync, where a naive "highest revision wins" merge silently dropped a device's offline progress; the fix was a proper conflict-aware merge. And once it left the code entirely and flagged a feature's framing as musically unsound — vibrato is an oscillation whose center matters, not a pitch to be scored moment-to-moment — which reshaped the feature, not just the implementation. A second model that extends beyond syntax into the domain provides value in the same way a new human perspective can.

It also cleared things — it confirmed suspected blockers were harmless, and downgraded a backlog item from "blocker" to "enhancement" on its own. A reviewer that only ever finds problems is one you learn to ignore; one that will also tell you an alarm is false is one you can trust to triage.

None of these were exotic. Each was caught for the price of a second API call — the kind of independent check that used to take a second hire.

What It Costs

This has real costs, and pretending otherwise would undercut the point. You pay two bills now, and a real review-and-revise loop burns tokens. The setup has friction — wiring one agent to call the other reliably takes work. And the whole thing is only as good as the independence you protect; collapse the two models into the same prompt and the same style, and you've spent money to agree with yourself more confidently.

The tools themselves are also still rough. While writing this very essay, the reviewing model's long-form responses stalled out repeatedly — healthy service, fast on short answers, but hanging for minutes on anything long. The fix was mundane: diagnose it as not an outage, cap the requests, and fall back on my own judgment when the second opinion wouldn't come. A pattern you depend on needs a plan for the day it's slow. Build the fallback before you need it.

None of that changes the shape of the win. The value is real — and so is the discipline to listen hardest when the two models can't agree.

Where to Start

• Add one rival. If you build with Claude, wire in an OpenAI model as the reviewer, or the reverse. Two providers, not two runs of one.
• Tell the second model to refute, with evidence. "Review this" invites agreement. "Try to break this, and cite a line or a rule for every claim" invites the disagreement you're paying for.
• Sort the output by evidence, not by conclusion. Independent convergence with citations, you trust. Matching "looks fine" with no reasoning, you don't. Substantiated deadlock, you escalate.
• Escalate the deadlocks to yourself, and only those. Don't review everything. Review the handful of places two capable models genuinely can't agree. That list is your real to-do list.
• Write the procedure down. A habit you have to remember is a habit you'll skip under deadline. Make it a skill the tools run the same way every time.

You're not buying a better answer. You're buying a map of where you still have to think — and whether you run a company of one or one of five hundred, that map is worth more than another increment of model intelligence. The executive's job was never to do all the work. It is to build the system that routes the real decisions to the person who has to make them.