Two-Track Review with Claude and Codex: Surfacing Blind Spots with a Different AI Lineage

Developing alone, the part I feel least sure about is assuring quality.

When I review my own code, I read it carrying the same assumptions I had while writing it. And having an AI write it and another AI review it doesn't fix that: two AIs of the same lineage slip past the same blind spots together.

What worked was a two-track review that sets two AIs of different lineages side by side: Claude (Anthropic) and Codex (OpenAI).

Why different lineages

AIs descended from the same training tend to be good at similar things and weak at similar things. So a defect one misses, the other tends to miss too. Same-lineage review feels reassuring, but the gaps line up.

When the model families differ, those gaps shift: a problem one walks past, the other snags on. Here is how it runs. On the Claude side, I run five reviewers with distinct lenses in parallel, a setup from a public plugin called pr-review-toolkit, each looking from a different angle:

• code-reviewer: errors in the code and convention violations
• silent-failure-hunter: swallowed exceptions and silent failures
• comment-analyzer: comments that disagree with the implementation
• pr-test-analyzer: missing tests and coverage gaps
• type-design-analyzer: the design of the types

Then the same change goes through Codex, of a different lineage.

It happened once. I removed an argument from a database function and fixed every caller on the application side, but in the SQL tests that check the database's behavior, one old call was left behind. All five distinct-lens reviewers missed it; only Codex, of a different lineage, caught it. What same-lineage review keeps missing in unison even as you add lenses, a difference in family scoops up. It is the clearest place two-track review earns its keep.

What goes to machines, what goes to the AI

Still, not all of review goes to the AI. There is a line.

Anything with a single right answer goes to machines. What holds this up is a body of deterministic checks, same input and same result every time, run as tests and automation:

• GitHub Actions: every time I open a PR, the checks run automatically: lint, type checking, build, the test suites. A gate you cannot merge through until everything is green.
• pgTAP: tests the database's functions and permissions directly, in SQL. I can pin down, say, that a given function must not be executable under a logged-in regular customer's privileges, and if a change accidentally opens that permission, CI goes red and stops it.
• vitest: unit tests for screens and logic, checking that a score calculation or a display behaves exactly as decided.

These pin down facts. They do not bend to anyone's mood, or to the AI's. That is why a slip like an old call left behind turns CI red the moment it is missed: the different-lineage AI's findings and the mechanical gate become a double net.

Judgments of meaning go to the AI, and ultimately a human: whether a design is sound, an overlooked side effect, how naming and responsibilities are placed. Get this backwards and try to measure the quality of prose or design with a proxy like whether it contains a required word, and you will usually miss. Form and fact to the machine; meaning to people and AI. That split is the foundation of two-track review.

Decide "done" before you implement

The trick to making that deterministic net pay off is order. Before writing a single line, I decide what done means, in a form a machine can judge.

For instance: this old pattern is gone from every file (a search returns zero), this condition is always true in SQL, this test passes (exit code 0). Writing the definition of done up front, as numbers and commands, keeps the bar from quietly slipping mid-implementation. And the reviewer only has to check whether the work meets the criteria.

Anywhere a contract is involved, the shape of the exchange between screen and server, the definition of a database column, I go a step stricter: before starting, I verify the real thing directly, write it down as the single source of truth, and only then implement. Hand a spec written from guesswork straight to implementation and the discrepancy propagates downstream. It is unglamorous, but this cut rework more than anything.

In practice, it doesn't end in one pass

Review doesn't finish in a single round.

For changes that pin down a spec or a design, it is not unusual to go a dozen or more rounds before findings converge to zero. It doesn't end in one pass because each fix on one side gives rise to the next point of contention. Fix it, another seam shows, fix it again. A plodding back-and-forth, but precisely because I can run it without flinching, one person can bring a team's worth of eyes to a change.

(Why I can run that much review without guilt comes down to the cost structure of development-side AI, which is a topic for a later post.)

Surfaced by lineage, not by person

Two-track review works because it surfaces defects by difference in lineage, not by who is superior or inferior. Over that, the mechanical gate of deterministic tests and CI lays a second layer. Defects get found, and pinned down, half a step away from both the author's assumptions and any single model's quirks. It is a realistic way to lift the quality of solo development without adding hands.

How I assembled this way of building over a year is in How a Micro-SaaS Tech Stack Changed in a Single Year, and the foundation that lets an AI touch real environments is in What MCP Changed. Other posts on how I build are gathered in the dev category.

The micro-SaaS I build under this double and triple scrutiny is PentaTrail, a CTEM service that uses AI to continuously keep track of your company's externally visible attack surface.

See PentaTrail / CTEM