Why not just ask Claude Code to review its own plan?

Self-review helps with slips — typos, a forgotten null check — but a model reviewing its own reasoning shares the same training, the same priors, and usually the same context that produced the mistake. If the plan rests on a wrong assumption the model finds plausible, the reviewer finds it plausible too. An independently trained model is far more likely to hold a different assumption and flag the conflict.

How do I get a second AI opinion grounded in my actual code?

Use the other vendors’ CLIs in their read-only modes instead of a web chat: claude -p --permission-mode plan and codex exec --sandbox read-only both answer a one-shot question after reading the real repo. That grounds the second opinion in your code without letting the reviewer edit anything.

Does a multi-model second opinion measurably help?

On the DRACO benchmark, a two-model panel with a judge scored 69.0% versus 65.3% for the best solo model, and even fusing two runs of the same model added 6.7 points over a single run. The gains show up on one-shot hard questions — plans, reviews, architecture calls — not on routine codegen.

When is a second opinion not worth it?

For trivial or easily reversible changes — renames, copy edits, a small bugfix covered by tests. A council run costs a few minutes of wall-clock time, so spend it where being wrong is expensive: migrations, architecture decisions, security-sensitive fixes, and plans you are about to approve wholesale.

Guide

Claude Code wrote it — how do you know it's right? Getting a real second opinion

Andrew Mercer July 16, 2026 · 8 min read

Claude Code just handed you a migration plan. It reads well — numbered steps, considered risks, confident tone. And that's exactly the problem: the tone is confident whether the plan is right or subtly wrong. You're now the reviewer of record for a change you didn't design, and "it sounds right" is not a review.

The reflex is to ask the same agent "are you sure? double-check this." That's worth doing — it catches slips. What it can't catch is the failure mode that actually burns you: a wrong assumption the model finds plausible. A model re-reading its own plan brings the same training data, the same priors, and usually the same context window that produced the mistake. If Claude believes your ORM handles cascading deletes a certain way, Claude-the-reviewer believes it too. Same blind spot, twice.

A second opinion is only worth something when it's independent. For AI-written code, independence means a different vendor: a model trained by a different lab, on different data, with different habits. Where errors are correlated, self-review rubber-stamps; where they're not, a cross-vendor check disagrees exactly where you need to look.

The manual way: three chats and an eyeball

The zero-setup version everyone tries first: copy the plan, paste it into ChatGPT and Gemini in a browser, and compare the answers. It genuinely works sometimes — a fresh model will happily point at a step the first one hand-waved. But three problems show up fast:

No repo grounding. A web chat sees only what you pasted. It can't open your schema, so it reviews the plan's internal logic while missing that step 3 references a column that doesn't exist. The most valuable disagreements come from the code, not the prose.
Context is a chore. Real questions depend on a half-dozen files. You either paste until you hit a limit or summarize — and your summary quietly bakes in the same assumptions you're trying to audit.
You're the synthesis engine. Three long answers that 80% agree: is the disagreement in the last 20% material or stylistic? Reconciling that by eyeball is a genuinely hard editorial task, performed at the exact moment you were trying to save attention.

A big step up, still manual: use the other vendors' CLIs instead of their chat windows, because a CLI can read the repo. Both major ones ship a safe one-shot mode:

# Claude reviews without editing anything (plan mode)
claude -p --permission-mode plan \
  "Review MIGRATION_PLAN.md against the actual schema. What breaks?"

# Codex, read-only sandbox, same question
codex exec --sandbox read-only \
  "Review MIGRATION_PLAN.md against the actual schema. What breaks?"

Now the second opinion is grounded in the real code and the reviewer can't touch anything. This is a legitimate workflow and costs nothing extra if you already pay for both subscriptions. What's still on you: running them, waiting on each, and doing the comparison by hand every single time.

One question fans out to your own CLIs in parallel, each grounded in the repo and read-only; a chairman judges the anonymized answers into a single verdict that declares whether the experts agreed.

The automated way: a council with a chairman

Backgrind's Fusion council is that CLI workflow with the manual steps removed. From an agent's decision card — or the council panel directly — you put one question to a panel of your own models. CLI seats run headless and in parallel, inside the repo, in an enforced read-only mode (Claude in plan mode, Codex in its read-only sandbox — seats are only offered where the CLI has a real, verifiable read-only flag); since July 2026, API seats via your own OpenRouter key add any catalog model to the panel — no repo access, stated honestly. Each expert answers independently.

Then the part you were doing by eyeball: a chairman model gets the anonymized answers — Expert A, B, C, no vendor names, so no brand favoritism — and judges them against a rubric: where's the consensus, where do they contradict each other and who's actually right against the repo, what did only one expert catch, what did they all miss. Not "merge the texts" — judge them. The verdict leads with a machine-checked contract:

AGREEMENT: consensus | split
CONFIDENCE: high | low

That contract drives the notifications, which is the detail that makes this usable while you're doing something else: a confident consensus lands as a quiet toast — glance, move on. A split or low-confidence verdict actually pings you, because models disagreeing about your migration is precisely the moment a human should look. And when the verdict is good, "Send to agent" pastes it straight into your working session — the council deliberates, your normal agent builds.

Does the panel-plus-judge shape actually beat one strong model? The public numbers say yes, for this class of question: on the DRACO benchmark, a two-model panel with a judge scored 69.0% against 65.3% for the best solo model. More surprising: even self-fusion helps — two runs of the same model plus a judge beat a single run by 6.7 points — so a council pays off even if Claude Code is the only CLI you have. Independent vendors just widen the blind-spot coverage further.

When not to bother

An honest second-opinion habit needs a "no" rule, or it becomes its own babysitting. Skip the council for:

Trivial or reversible edits. Renames, copy changes, a bugfix your test suite already covers. The blast radius of being wrong is a git revert. Just ship it.
Routine codegen. Fusion research is consistent on this: panels help one-shot hard questions, not the boilerplate the model was going to get right anyway.
Mid-loop agent work. Nobody should fuse every tool call — latency and cost multiply per turn and the value doesn't. The council answers with text at decision points; the agent executes between them.

Where it earns its minutes: plans you're about to approve wholesale, architecture calls, data migrations, security-adjacent fixes, and any bug where the fix rests on a claim about how a library behaves. The tell is simple — if being wrong costs more than five minutes of council wall-clock, get the second opinion.

The cost story: you already paid for the council

The standard objection to multi-model fusion is that it multiplies token cost 3–5× per question — true if you're paying per token through an API. But this council runs on the CLIs you already have, under the subscription auth you already pay for. Your Claude plan, your ChatGPT/Codex plan, your Cursor seat: the members bill against flat rates that are sitting mostly idle anyway. There's no extra metering and no middleman reselling you model access — the marginal cost of asking your own subscriptions to argue with each other is zero. (That's also why this is a BYO feature by design: the panel members are yours, and what they read in your repo never routes through anyone's server.)

Frequently asked questions

Why not just ask Claude Code to review its own plan?: Self-review catches slips — typos, a forgotten null check — but a model reviewing its own reasoning shares the training, priors, and usually the context that produced the mistake. If the plan rests on a wrong assumption the model finds plausible, the reviewer finds it plausible too. An independently trained model is far more likely to hold a different assumption and flag the conflict.
How do I get a second AI opinion grounded in my actual code?: Use the other vendors' CLIs in their read-only modes instead of a web chat: claude -p --permission-mode plan and codex exec --sandbox read-only both answer a one-shot question after reading the real repo. That grounds the second opinion in your code without letting the reviewer edit anything.
Does a multi-model second opinion measurably help?: On the DRACO benchmark, a two-model panel with a judge scored 69.0% versus 65.3% for the best solo model, and even fusing two runs of the same model added 6.7 points over a single run. The gains show up on one-shot hard questions — plans, reviews, architecture calls — not on routine codegen.
When is a second opinion not worth it?: For trivial or easily reversible changes — renames, copy edits, a small bugfix covered by tests. A council run costs a few minutes of wall-clock time, so spend it where being wrong is expensive: migrations, architecture decisions, security-sensitive fixes, and plans you are about to approve wholesale.

Where Backgrind fits

The manual CLI workflow above is real and free — start there if you want to feel the value first. Backgrind makes it a reflex instead of a chore: the Fusion council lives in the same overlay that runs your agents, opens pre-filled from the exact decision an agent is blocked on, runs your own CLIs read-only in parallel, and only interrupts you when the experts split. It's one layer of the broader pattern we lay out in the multi-agent coding setup for 2026 — agents for the volume, a council for the judgment calls, and your attention reserved for the verdicts marked split. See it in the live demo.