Seoul Labs

Seven passes on a single spec before a single line of implementation code gets written. That's not what the launch demo showed you, and the gap between the demo and this workflow is the real story here: a good prompt and a good plan feels like progress, but the model can produce something internally consistent and completely blind to accessibility, responsiveness, or a race condition it never flagged. So why is one confident pass from Claude, however capable, the wrong unit of trust for anything that ships? That's what I want to walk through.

My Claude Code workflow in August 2026 looks nothing like it did a year ago, and barely resembles what it looked like in January. Here's the core shift: I stopped treating Claude as a single model doing a single pass, and started treating planning as a pipeline with adversarial checkpoints. Sounds like process theater until you watch it catch a race condition in a websocket handler that would have shipped otherwise. After that, it stops sounding like theater and starts sounding like the only sane way to use a model that stays confident even when it's wrong.

Why Seven Review Passes Beat One Good Prompt

The instinct when you first get access to a capable coding agent is to write a good prompt, get a good plan, and move. That instinct is wrong more often than it's right, and the failure mode is specific: the model produces a plan that's internally consistent and completely blind to a category of problem you didn't ask about. Accessibility is the one people skip most. Responsiveness at breakpoints nobody tested. Unresolved decisions that got quietly resolved by the model picking whatever was easiest to generate, not whatever was correct.

In my current setup, a custom command forces the model back through the same spec across several passes, each with a different lens: interaction states, responsiveness, accessibility, error states, edge cases, unresolved decisions, and a final consistency check. Each pass gets scored, and low-scoring passes get fixed inline before the next one starts. By the time a human even looks at it, the spec has already been argued with by itself multiple times.

Here's the part that matters more than any rubric: the value isn't the scoring system, it's the forced re-reading. A model that reads a spec once and generates a plan is doing pattern completion. A model that reads the same spec multiple times, each time hunting for a specific category of failure, is doing something closer to review. The score is almost a side effect. What actually changes the output is repetition with intent.

rough shape of a plan-design-review pass, abbreviated
One Model Reviewing Itself vs Two Adversarial Models

  

    

      

        
SINGLE MODEL REVIEW
        
Same Blind Spots
        
Claude reviews its own plan with the same weights and training biases that produced it. It finds nothing wrong because it misses exactly what it was always going to miss.
      
      

      

        
ADVERSARIAL SECOND PASS
        
Different Blind Spots
        
A fresh Claude subagent or OpenAI's Codex CLI reviews with different training data and different tendencies, catching what the original model treats as obvious.
      
    
  
  

    
Key insight: adversarial by design, not by accident. Two different models catch different failures than one confident model ever will.
  
Source: Based on workflow described in article

claude skill run plan-design-review \
  --spec ./specs/checkout-flow.md \
  --pass a11y \
  --min-score 7 \
  --fix-inline

Verdict: seven passes is overkill for a script you'll run once, and exactly right for anything with a UI a real user will touch. The mistake is applying this ritual to every task instead of reserving it for specs where getting it wrong is expensive. And that same mistake, too much process on too small a task, shows up again once review moves from one model to two.

Solving The Second Opinion Problem With Two Models

Here's a pattern I've watched repeat across a dozen projects: Claude reviews its own plan and finds nothing wrong, because the blind spots that produced the plan are the same blind spots doing the reviewing. This isn't a Claude-specific failure, it's a single-model failure. Any model grading its own homework with the same weights and the same training biases will miss exactly what it was always going to miss.

So the second pass after design review isn't more Claude reviewing Claude. It's either a fresh Claude subagent with no memory of how the plan came together, or OpenAI's Codex CLI, brought in specifically because it has different blind spots. Different training data, different tendencies, different things it treats as obvious. Adversarial by design, not by accident.

The results are uneven in an instructive way. Codex catches type mismatches and edge cases in state management that Claude's plan mode tends to wave past. Claude, in turn, catches structural and narrative problems in specs, places where the plan technically works but doesn't tell a coherent story about why. Neither model is better. They're wrong in different places, and that's the entire value of running both.

second opinion pass, adversarial by design
codex review --input ./specs/checkout-flow.md \
  --mode adversarial \
  --output ./specs/checkout-flow.codex-notes.md

compare notes before merging into final spec
diff ./specs/checkout-flow.md ./specs/checkout-flow.codex-notes.md

One rule stays fixed no matter which model is doing the reviewing: Opus for anything that needs real reasoning, Sonnet for small deterministic execution, and Haiku nowhere near code that ships. This isn't a cost optimization tip, it's closer to a triage rule. Haiku is fast enough that it's tempting to reach for constantly, and that's exactly the trap. Fast and wrong at 2am in a deploy pipeline costs more than the tokens you saved.

Verdict: a second model isn't a luxury step, it's the only thing standing between you and a plan that looks finished because it was reviewed by the exact intelligence that wrote it. Once the spec has survived that adversarial pass, the next problem is turning it into work someone, or something, can actually execute.

Turning A Reviewed Spec Into Tasks That Ship

A spec that scored well across seven passes and survived an adversarial review is still just a document. The gap between a good spec and working code is where most AI-assisted workflows quietly fall apart, usually because the task breakdown is too coarse. "Build the checkout flow" isn't a task, it's a paragraph pretending to be one.

A plan-writing command, run in Claude's plan mode, reads every document generated in the passes above and breaks the spec into small, tightly scoped tasks, each estimated at just a few minutes of work. Every task gets a file path and a test written down before any code exists. That granularity feels almost absurdly small until you watch what happens without it: a model given a vague multi-hour task will wander, and wandering is where context gets lost and half-finished implementations get left behind mid-session.

The parallelization is where this earns its complexity. When tasks don't share state, plan mode splits them into subtrees that can run concurrently instead of sequentially. I've had specs come out as fifty tasks spread across three parallel subtrees, which sounds like overhead until you realize it turns a linear four-hour session into three concurrent ninety-minute ones.

simplified shape of a generated subtree, three way split
subtrees:
 , name: auth-flow
    tasks: 17
    depends_on: []
 , name: checkout-ui
    tasks: 21
    depends_on: [auth-flow]
 , name: payment-webhook
    tasks: 12
    depends_on: []

What most guides skip is how often the dependency graph is wrong on the first pass. Plan mode will confidently mark two subtrees as independent when they actually share a database migration, and you find that out when both subtrees try to write conflicting schema changes in the same session. Reading the subtree graph before you let anything run in parallel isn't optional. It's the one manual check that saves you a merge conflict at 11pm.

Verdict: task granularity at two to five minutes sounds excessive until you've watched a thirty-minute task silently drift off spec somewhere around minute twenty. After that, it stops sounding excessive and starts sounding like the minimum viable unit of trust.

None of this is faster than writing a prompt and hoping. It's slower, on purpose, the same way code review is slower than merging straight to main. The workflow only makes sense once you've shipped something from the fast version and spent longer fixing it than the seven passes would have cost. So here's the answer to the question I opened with: a single confident pass is the wrong unit of trust not because Claude is unreliable, but because no single pass, from any model, can review the blind spots that produced it. Seven passes, a second model, and small tasks aren't process theater. They're what it costs to make that trust earned instead of assumed.