I stopped letting one model grade its own homework. The model that writes your code shares every blind spot in its own output, so asking it “is this correct?” is asking the author of a bug to spot the bug. The fix is dumb and mechanical: build with one model, then hand the finished artifact to a different model at high reasoning effort with one job, break it.

This is not “AI code review” in the vibe-check sense where you paste a diff and get back “Looks good, here are some style suggestions.” The build model is invested in its own approach. A second model, running cold against the artifact as a pure critic, has no stake in the design and goes looking for the failure modes the author never imagined because the author would have built around them.

The pattern: build with Claude, review with Codex

The default loop is build with Claude Code, then review the result with codex exec --effort high before anything ships. Codex is not touching the feature. It is reading what already exists and trying to find where it falls over.

The hit rate is the whole argument. On one design sketch for an infrastructure cleanup feature, Codex came back with 2 BLOCKs and 5 majors. All seven were adopted. These were not nitpicks about naming. A BLOCK is “this design is wrong in a way that will hurt you,” and two of them were sitting in a design I had already convinced myself was done.

The reason this works is structural, not magic. When Claude writes a piece of code, the gaps in its reasoning are baked into both the code and its own assessment of the code. Ask the same model to review its work and it re-runs the same reasoning that produced the gap, so it re-confirms the gap. A different model, with different training and different priors, hits the same artifact from a different angle. The disagreement is the value. You are buying a second independent perspective for the cost of one command.

The cascade: Codex first, then Manus

For anything heavier than a code diff, an architecture doc or a multi-system contract, one reviewer is not enough either. The order that works is Codex first, synchronously, then Manus second, asynchronously. The sequencing matters.

Codex runs first and fast. You adopt its findings, which produces a materially stronger draft. Then Manus reviews that stronger draft, not the original. Manus is seeing a starting point that has already survived one adversarial pass, so it can go deeper instead of burning its review re-finding the obvious stuff Codex already caught. Each reviewer raises the floor for the next.

On one architecture spec, that cascade produced 16 Codex findings plus 6 Manus findings, all adopted, and the doc landed structurally different from where it started. A cross-system integration contract went v1 to v3 through the same loop and was not a polished v1, it was a different document. The write-review-adopt-review-adopt-promote loop is not over-engineering. Across three to five revisions on a cross-repo contract, the v5 is genuinely a better design than the v1, not a reworded one.

An internal agent orchestration design ran through the same cascade and is a clean example of why a critic earns its keep. The v1 classified what an agent was allowed to do by risk label: “low risk,” “reversible,” that kind of thing. Codex flagged that risk labels are editorial. Different agents interpret “low risk” differently and there is no principled way to enforce a vibe. The replacement was capability gates: classify by the capability the action requires (read-only, local-write, branch-write, external-write, money-comms-prod), because “needs a network write to a third-party API” is something a system can actually verify. That change made the permission model enforceable instead of aspirational. Codex also flipped the build sequencing. The v1 built the clean reusable primitive first; Codex pointed out that the clean primitive was a proof nobody would feel, and the right first deliverable was the thing that addressed the actual pain. The build model would not have caught either of those, because the build model is the one that found the v1 satisfying.

The climax: 8 false-greens in an all-green production gate

Here is the run that settled it for me.

I had built a production cleanup engine: a state machine with backup and restore, provenance gates, and a queue worker. Its job was to delete production infrastructure records in bulk. It was built. It was deployed. Every check was green. Under any normal definition I was done and could schedule the first live run.

Before I let it touch a single live record, I ran a high-effort Codex review against the gate logic: 165k tokens, four and a half minutes of wall time, pointed at one question. Where does this gate return green when it should not?

It came back with 8 false-green paths. Wrong-record risk the gate did not catch. Missing freshness checks on DNS resolution results, so the gate could approve a delete based on stale resolution. Edge cases in the provenance scan that would let it green-light deleting something it had no business deleting. None of these showed up in normal testing, because normal testing exercises the happy path and the happy path was green. That is exactly the point. The gate was not lying about the cases I tested. It was lying about the cases I did not think to test, which on a production delete state machine are the ones that cost you.

Those 8 paths became the next ticket and the gate got hardened before it ever ran live. The cost of finding them was one command and five minutes. The cost of not finding them was a production record deleted on a false green, with the recovery happening live while customers are down.

If you want to try this before your next live run, pick the one gate in your pipeline that decides whether something ships or touches real data. Hand the finished artifact, not the diff, not the plan, to a different model at high effort, and give it exactly one question: where does this return green when it should not. Read every finding before you dismiss any of them.