charles forson

I make a different model argue with mine before anything ships

3 min read

When the model that wrote something also reviews it, the review inherits the same blind spots as the writing. That sentence sounds obvious once it's stated, but I didn't actually act on it until I noticed how often a review pass from the same model that did the implementation produced approval, not scrutiny. Same training data, same reasoning tendencies, same things it's confidently wrong about. Asking it to catch its own mistake is asking it to notice something it structurally doesn't notice.

The fix I use now is deliberately cross-vendor, not just cross-instance. A different model, from a different lab, reviews the work before anything high-stakes merges. The independence is the entire value, not the second model being smarter. A model trained by a different team, on a different mix of data, with different reasoning habits, catches things precisely because it doesn't share the first model's assumptions. That's a genuinely different mechanism from spinning up a second instance of the same model, which mostly just re-runs the same blind spots at extra cost.

I don't run this on everything, and that restraint is most of the point. Cross-model review earns its cost on roughly two conditions, and I look for both before summoning it. First, correctness has to be genuinely expensive to get wrong: architecture decisions, anything security-adjacent, a plan that a large amount of downstream work depends on. Second, the error class has to be one a cheap deterministic check can't catch. If a test or a linter or a type checker would catch it, that's a thousand times cheaper than a second frontier model, and I run that instead. The overlap of those two conditions is genuinely narrow. Most work I do is either low-stakes enough that a miss is easily reversible, or checkable by something that costs almost nothing, and cross-model review on either of those is just an expensive way of confirming what a cheaper check already told me.

The single highest-leverage place to spend a review, and the one I underused for a long time, is before any code gets written at all. Reviewing a plan is the cheapest round there is, and it's the round that catches the most expensive class of error: a bad plan executed well is still a bad outcome, and catching it before implementation saves the entire cost of the implementation. I treat plan review as close to mandatory on anything non-trivial, and treat post-implementation review as the second, more expensive line of defence for whatever the plan review missed.

The mechanical setup matters less than it sounds like it would. I don't run a bespoke pipeline; I use the equivalent of an installed reviewer app that runs the second model's review in its own infrastructure, summoned by a comment on the actual piece of work under review, authenticated through my existing subscription rather than a metered API key. No custom orchestration, no separate billing to track. Buying the integration instead of building it turned out to be the right call for exactly the reason it usually is: this problem was already solved well by people whose whole job is that integration, and building my own version would have been reinventing a wheel to save an afternoon of setup a subscription already covers.

The part I had to enforce on myself, more than the model choice, was a hard cap on how many rounds this runs. Two to three rounds, then stop and escalate rather than keep iterating. Without that cap, the loop degrades in a predictable way: the critic's context goes stale round over round, both models start thrashing on genuine stylistic disagreement rather than real defects, and the cost compounds for diminishing signal. The failure mode is that the review kept going long after it had already told me everything useful, and I kept paying for more rounds because stopping felt like giving up too early. Capping the loop and escalating to a human at the cap is the discipline that actually makes this worth running at all, more than picking the right second model in the first place.

None of this replaces judgement on the things that actually need a person: anything touching authentication, secrets, or genuinely irreversible decisions still gets my own eyes on it regardless of what either model says. Cross-model review complements that floor. It doesn't get to lower it.

Building the same things I write about — see what I'm working on in Projects, or get in touch.