Two-Track Review with Claude and Codex: Surfacing Blind Spots with a Different AI Lineage
Contents
Developing alone, the part I feel least sure about is assuring quality.
Re-reading your own work means re-reading it under the same assumptions you wrote it with. Having an AI write and another AI review sounds like the answer, until two AIs of the same lineage slip past the same blind spot together.
Review within one lineage lines the holes up
AIs descended from the same training share what they are good at and what they are weak at. A defect one misses is a defect the other is likely to miss too.
Figure 1: A different family shifts where the holes sit
Deep dive: adding angles is not enough on its own
Line up reviewers looking from different angles and, within one lineage, the holes stay where they are. What shifts them is not the number of angles but the model's family.
Run five differently-angled reviewers first, then send it to a different lineage
Five reviewers with different perspectives run in parallel on the Claude side, and then the same change goes to Codex. Stacking them in that order changes the direction of the mesh.
Figure 2: Split by angle first, then split by lineage
Deep dive: what each of the five is looking at
Code errors and standards violations; swallowed exceptions and silently failing paths; comments that disagree with the implementation; missing tests and coverage; type design. It is a published plugin's configuration, with each looking from a different angle.
A defect all five missed together was caught by the other lineage
Dropping one argument from a database function, every call on the application side got fixed — but one stale call remained in the SQL that tests the database's behaviour. All five differently-angled reviewers missed it, and only Codex, from the other lineage, caught it.
Figure 3: The one time more angles still missed in unison
Deep dive: it is a double net
A mistake of this kind also turns CI red if it slips through. The finding from the other lineage and the mechanical gate form two nets, and either one catching it is enough to stop the change.
Anything with exactly one right answer goes to the machine
Underneath sits a set of checks that return the same result for the same input every time. None of it varies with anyone's mood, or with how an AI is doing that day.
Figure 4: Three mechanisms that pin down facts
Deep dive: what goes to the machine, what goes to the AI
Judgments of "meaning" — whether a design is good, side effects that were missed, how naming and responsibility are placed — go to the AI, and finally to a person. Confuse the two, and try to measure the quality of prose or design with a proxy like "does it contain the required word", and you will usually miss. Judgments of form and fact go to machines; judgments of quality go to people and AI. That split is the base the whole thing rests on.
Decide what "done" means, machine-checkable, before writing code
Zero hits when you search for it. This condition always true in SQL. This test passing with exit code 0. Writing that down first stops the bar from quietly sliding during implementation.
Figure 5: Define done up front, in numbers and commands
Deep dive: contracts get one notch stricter
Anything touching a "contract" — the shape of what passes between screen and server, the definition of a database column — gets checked directly against the real thing before starting, written into the spec as the single source of truth, and only then implemented. Handing a guessed spec to implementation propagates the mismatch downstream. It is unglamorous, and it cut rework more than anything else.
It doesn't finish in one round; sometimes it takes a dozen or more
For changes that settle a spec or a design, it is not unusual to go a dozen or more rounds before findings converge to zero. One fix generates the next point of discussion.
Figure 6: Each fix produces the next question
Deep dive: being willing to run the loop is itself what works
Being able to run that back-and-forth is what lets one person put a team's worth of eyes on a change. Why the reviews can be run this freely comes down to the cost structure of AI on the development side, which is its own post.
Surface defects by lineage, not by who is better
Two-track review works because it surfaces defects through a difference in lineage rather than a ranking of who is better. Over that sits the mechanical gate of deterministic tests and CI.
Figure 7: Found half a step away, then pinned down
Deep dive: raising solo quality without adding people
Half a step away from the author's own assumptions, and half a step away from any single model's habits, defects get found and then fixed in place. That turned out to be a workable way to raise the quality of solo development without adding people.
- How We Keep AI-Written Code Secure: Defense in Depth for the Age of Generated Code
- What MCP changed: giving AI hands
- How our micro-SaaS tech stack changed in a year
- Posts on our development work (dev category)
Building it under two and three passes of review is how PentaTrail / CTEM came about — a service that uses AI to continuously map the attack surface your company presents to the outside.
Appendix: the reviewers, and the mechanical gates
Table 1: the five differently-angled reviewers
| Reviewer | What it looks at |
|---|---|
| code-reviewer | Code errors and standards violations |
| silent-failure-hunter | Swallowed exceptions, silently failing paths |
| comment-analyzer | Comments that disagree with the implementation |
| pr-test-analyzer | Missing tests and coverage |
| type-design-analyzer | Type design |
Table 2: the checks left to machines
| Check | What it pins down |
|---|---|
| Automatic run per PR | Lint, type check, build and tests; no merge until all green |
| Database tests | Functions and permissions verified directly in SQL; an accidentally opened permission goes red |
| Unit tests | Screens and logic behaving exactly as specified |
Table 3: the split between machine and AI
| Goes to | Scope |
|---|---|
| Machines | Anything with exactly one right answer (form and fact) |
| AI and people | Design quality, missed side effects, naming and placement of responsibility |
Visualize your attack surface with PentaTrail CTEM/ASM
From discovery to vulnerability validation and remediation — all powered by the CTEM framework.
Get Started
