Who should plan, and who should build?

01 · The question

Can a cheap model build what an expensive model plans?

AI models that write code come in price tiers. The expensive ones think longer; the cheap ones are fast. One way to use both: let an expensive model write a plan so detailed that a cheap model only has to follow it.

These trials test that idea on real code for Navo, a file manager for Windows. Three roles, three questions: who should write the plan, who should check it, and who should build it? And does a plan written at Opus's highest effort, xhigh, pay for itself over the cheaper high?

1. 1Plan

   Who writes a plan detailed enough to follow blindly?

2. 2Check

   Who reads the plan and catches its mistakes?

3. 3Build

   Who turns the plan into working code for the least money?

02 · The method

One plan, two traps: a good builder treats them differently.

Same task, same plan, many builders. Each builder got the identical plan and worked alone on a fresh copy of the code. Then we checked what it delivered: did it build, did the tests pass, did it follow the plan?

In trials 1 and 2 the plan held two traps. One is a real bug: a safety hole. The other is a false alarm: a number in the plan that is simply wrong and does no harm. A good builder stops on the first and carries on past the second.

1. 1Plan

   Opus writes a step-by-step plan: files, code, tests.

2. 2Copy

   Each builder gets the same plan and a fresh copy of the code.

3. 3Build

   The builder works alone. It may stop and report a problem.

4. 4Judge

   We check the result, the price, the time and the tokens.

rust357pub(super) fn is_gitignore_file(entry: &FsEntry) -> bool {358    entry.kind == EntryKind::File && entry.name.as_str() == Some(GITIGNORE)359}360 361fn load(folder: &Path) -> Option<Gitignore> {362    let mut bytes = Vec::new();363    File::open(folder.join(GITIGNORE))T1364        .and_then(|file| file.take(RULES_LIMIT).read_to_end(&mut bytes))365        .ok()?;366    let lossy = String::from_utf8_lossy(&bytes);367    let text = lossy.strip_prefix('\u{feff}').unwrap_or(&lossy);368    let mut builder = GitignoreBuilder::new(folder);

277### Step 5a: new file `crates/navo-fs/src/find/walk/gitignore.rs`...354Free functions in the same file:356```rust357pub(super) fn is_gitignore_file(entry: &FsEntry) -> bool {358    entry.kind == EntryKind::File && entry.name.as_str() == Some(GITIGNORE)359}360 361fn load(folder: &Path) -> Option<Gitignore> {362    let mut bytes = Vec::new();363    File::open(folder.join(GITIGNORE))T1364        .and_then(|file| file.take(RULES_LIMIT).read_to_end(&mut bytes))365        .ok()?;366    let lossy = String::from_utf8_lossy(&bytes);367    let text = lossy.strip_prefix('\u{feff}').unwrap_or(&lossy);368    let mut builder = GitignoreBuilder::new(folder);...26- **D5:** only a regular file named exactly `.gitignore` is read (kind `File`, not a link).

03 · Trial 1

Only one build stopped on the bug, and it was the cheapest.

Task: Find in files honours .gitignore: ignored files and folders are skipped; the git:off token searches them too.

Opus wrote the plan twice: once at high effort, once at xhigh. The xhigh plan carried both traps. Nine builds followed, split across the two plans.

Builders on the same plan wrote the same code.

04 · Trial 2

Nine out of ten got it wrong, in two opposite ways.

Task: Find in files honours .gitignore: ignored files and folders are skipped; the git:off token searches them too.

This is where the builder matters. Same task and the same Opus xhigh plan as trial 1, with both traps left in; only the builder changes. Ten models from three vendors got the identical plan and the same instructions.

205### Step 3: walk tests first (7 must fail, 2 must pass)...265Run `cargo nextest run -p navo-fs find::tests::gitignore`. On Linux it must report266**9 tests: 7 failed (1, 3, 4, 5, 7, 8, 9) and 2 passed (2, 6)**. Any other result means stop and report.T2

Only one model out of ten could tell the real bug from the false alarm.

05 · Trial 3

The cheaper plan gave the better code.

Real production code for Navo: the part of folder sync that plans which files to copy, keep and recycle. No traps were planted this time. The question is simpler: does the Opus xhigh plan, at 73% more, give better code?

Opus high and Opus xhigh each wrote a plan. Then five builders implemented each one.

Plan gaps reach every build, so catch them before building.

06 · What we learned

Plan with Opus high, check the plan, then build cheap.

Across three trials the same picture keeps coming back: the plan decides the code. Here is the recipe we use now.

The recipe

1. 1

   Plan

   Opus high

   About $3 per plan, 60% of xhigh. A review closes the gaps either way.

2. 2

   Check the plan

   Terra xhigh + a senior review

   Plan gaps reach every build, so catch them before building.

3. 3

   Build

   Sonnet medium, or DeepSeek off-peak

   Sonnet scored best at $0.6; DeepSeek nearly as good at $0.1.

How we will work from now on

Plans decide the code, so the money goes into the plan and two cheap checks, not into the builder.

Four lessons

1. 01

   The plan decides the code

   Same plan, same code. Plan mistakes end up in every build.

2. 02

   Opus high is the better buy for plans

   xhigh won once, high won once, and high costs about 60% as much. A plan review closes the gaps either way.

3. 03

   GPT stops on every warning

   Real bug or false alarm, it stops. Only Terra xhigh tells them apart.

4. 04

   Claude and DeepSeek always finish

   But they copy bugs from the plan.

Based on 3 trials: two on find in files, one on folder sync.