Two BLOCKs and five majors on a design we thought was finished

Codex came back with 2 BLOCKs and 5 majors on an infrastructure cleanup design we had already convinced ourselves was done. All seven were adopted. A BLOCK means “this design is wrong in a way that will hurt you,” and none of the seven were nitpicks about naming.

We got there by no longer 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 mechanical. Build with one model, then hand the finished artifact to a different model at high reasoning effort with one job: break it.

That differs from the vibe-check kind of AI code review, 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 has no stake in the design, so it goes looking for the failure modes the author never imagined, because the author would have built around them.

Build with Claude, review with Codex

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

The reason this works is structural. 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 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 another angle. The disagreement is the value, and it costs one command.

Codex first, then Manus

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

Codex runs first and fast. We adopt its findings, which gives us a materially stronger draft. Then Manus reviews that stronger draft instead of the original. It starts from something that has already survived one adversarial pass, so it can go deeper instead of spending its review re-finding the obvious problems 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 came out as 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 a better design than the v1.

What the critic changed in an agent orchestration design

An internal agent orchestration design went through the same cascade, and it shows what a critic is for. 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. We classify by the capability the action requires: read-only, local-write, branch-write, external-write, money-comms-prod. “Needs a network write to a third-party API” is something a system can verify, so the permission model became 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 these, because the build model was the one that found v1 satisfying.

Several false-greens in an all-green production gate

This is the run that settled it for us.

We 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 and deployed, and every check was green. By any normal definition we were done and could schedule the first live run.

Before it touched a single live record, we ran a high-effort Codex review against the gate logic. It was a long pass, 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 several false-green paths. There was wrong-record risk the gate did not catch. There were missing freshness checks on DNS resolution results, so the gate could approve a delete based on stale resolution. And there were 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. The gate told the truth about the cases we tested and lied about the cases we did not think to test, which on a production delete state machine are the ones that cost you.

The false-green paths became the next ticket, and the gate was hardened before it ever ran live. Finding them cost one command and a few minutes. Missing them would have meant 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 to a different model at high effort, not the diff and not the plan. Give it exactly one question: where does this return green when it should not. Read every finding before you dismiss any of them.

dxdev LESSON · paste into your AI coding agent
LESSON: Separate Your Build Model From Your Review Model
SOURCE: dxdev.com/blog/separate-build-model-from-review-model-codex
WHAT HAPPENED: A production gate was fully built, deployed, and showing all-green checks. Before it ran against live records, a second AI model was run against the gate logic at high reasoning effort as a pure critic. It returned several false-green paths: stale DNS resolution results treated as fresh, edge cases in provenance scanning that would approve deletions the gate had no business making, wrong-record risk that normal happy-path testing never exercises. The build model could not have caught these because it was the model that found the original design satisfying.
THE RULE: Build with one model, then run the finished artifact through a different model at high effort with one job: find where it fails.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Is the same model that generated this artifact also the one being asked to verify or gate it?
  2. Are there any correctness gates (approval checks, green-light conditions, state-machine guards) that are only exercised on the happy path and never on adversarial edge cases?
  3. Is any time-sensitive external state (DNS resolution, cache reads, freshness checks) used in a gate decision without an explicit staleness bound?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.