Claude Code Code Review Needs a Non-Claude Model [2026]

A Claude Code code review that agrees with your design is not evidence the design is good. It is evidence the reviewer shares your priors. Same model family, same training, same blind spots, so a Claude Code code review of a plan you produced is grading its own reflex.

I now send every load-bearing design to two decorrelated non-Claude models before building, with one instruction: attack this. The two are fugu --ultra from Sakana AI and grok-build from xAI. Four times so far a design I was confident about did not survive. The anti-groupthink lens system behind this lives in primeline-ai/quantum-lens.

Why does a Claude Code code review agree with you?

Because a Claude subagent grading a Claude-authored plan is the same distribution twice, not an independent check.

I had noticed the softer version of this and written about structural divergence with cognitive lenses: give each reviewer a different frame and you surface more than N identical reviewers do. That works. But it has a ceiling. Seven lenses inside one model family still share whatever the family gets wrong. Diversity of prompt is not diversity of prior.

What moved my hit rate was crossing the model boundary. Fugu and grok-build get the same packet and are asked to refute rather than review. The lens definitions are in primeline-ai/quantum-lens if you want the in-family version first.

The design that died before I wrote any code

I wanted to measure whether my agent follows its own always-loaded rules, so I designed a trap suite: 8 prompts that put a rule under pressure, run headless against the live rule surface, plus a no-rules control arm.

To keep it honest I pre-registered a kill rule: discard any trap where the no-rules arm does not violate at least 20 percentage points more than the live arm. It felt like rigor.

Both models called it fatal

Independently, for the same reason, with different proofs. If the pathology is rules contradicting each other, the live rule surface can be worse than no rules at all. That trap has a negative gap, so my filter deletes it, removing the only evidence that would justify the cleanup the project existed to justify.

It also discards high-base-rate failures where both arms fail. What survives is "does the file load" house-style checks, where the live surface already sits at the floor.

Then the arithmetic

A floor-selected suite of 5 traps at a 0.05 base rate never exceeds 25% statistical power at any effect size, because a rate near zero cannot fall further.

I would have run it, gotten a null, and reported "measured: no change."

What convergence and divergence each tell you

Two models give you two signals, not one, and the second is the valuable one.

Where they converge, the question is settled. Both found the kill rule fatal, and both derived that my stated resolution was wrong: I claimed 10 to 15 points detectable, three derivations put the floor near 20. One argued from degrees of freedom, one from the standard error of a difference, and my own simulation agreed afterward.

Where they diverge, you get coverage. The divergence was additive:

Neither model found all three. That is the argument for always running both.

Why is one model not enough for a cross-check?

Because a single reviewer, even a non-Claude one, kept missing things I then caught myself. Four times in one cycle. So the rule hardened to both models, always, never one.

Anthropic applies the same reasoning to its own instructions. Their context engineering guidance describes cutting roughly 80% of Claude Code's system prompt after finding conflicting messages inside single requests, and it was only safe because evaluations existed first. A reviewer is an evaluation you can run before the build.

Reading zero as safety

The flip I should not have made

I moved a component from observe mode to live because its observe window had recorded zero problems. Both models returned the same verdict when I asked: premature. Zero out of four is not a precision estimate, and with n=4 the rule of three puts the upper bound near 75%. I reverted the flip the same session, so net code change was zero.

The shape both cases share

I was reading absence of evidence as evidence of absence, and a same-family Claude Code code review let me. That failure mode is invisible from inside.

Where in the process the cross-check pays

Timing is most of the value. The design above was killed before the build, so the cost was one document. The three earlier refutations landed after I had built something.

Step 3 is the one people skip. A model asked "is this good?" tells you what is good about it.

How to run this without my setup

Two browser tabs and a pasted design document get most of the benefit. Automate only once you are doing it weekly.

Steal the structure, not the tooling

Distinct frames per reviewer, refutation as the default instruction, and a written rule that convergence settles a question while divergence expands it. That is what primeline-ai/quantum-lens encodes as seven cognitive lenses, and it works inside one model family too.

One tuning note for reviewers inside Claude Code

Severity filters cost you recall. The Opus 5 prompting guide warns that a Claude Code code review prompt saying "only report high-severity issues" is now followed literally, so the model investigates fully and then reports less. Ask for everything with a confidence score and filter downstream. The effort setting is the other lever: accuracy holds at lower effort, so a cheap fast pass plus a thorough one later is affordable. Related: why "done" is not done and why your CLAUDE.md rules expire.

Honest scope

n=4 refutations, one developer, my own designs, no control arm. I cannot tell you what fraction a same-family Claude Code code review would also have killed, because I never ran that arm. The claim is narrow: four designs I was confident about were refuted by Fugu and grok-build, three after I had already built something. That is a strong enough prior to keep doing it, not a measured effect size.