The split

The failure I kept repeating

I used to hand a whole feature to one strong model and read the result. It worked until it did not. The failures were always the same three:

• The model decided something I would have decided differently, and I only found out after the diff.
• The model said it was done. It was not. Nothing checked.
• The work was expensive because the strongest model did the boring parts too.

None of those are model problems. They are shape problems. One agent was doing three jobs at once: deciding, building, and judging its own work.

The three jobs

Deciding is what to build, in what order, and what done means. This is judgement. It stays with one brain, and that brain is expensive on purpose.

Building is turning a written spec and a red test into green code. This is labour. It can be cheap, as long as the scope is small and the test is real.

Checking is proving the claim. A builder cannot do this for its own diff. It has no distance. A separate agent, with no authorship, catches what the builder structurally cannot.

Why a lane is the unit

I call one unit of building a lane. A lane has four properties, and if it is missing one it is not a lane yet:

• A red test that already fails, for the right reason.
• A scope list: the exact files, and often the exact functions and line ranges.
• Its own git worktree, so two lanes never touch the same working tree.
• A runner that executes the tests itself after the agent exits.

That last one is the whole trick. The lane's own report of green is a claim, not evidence. The runner runs the tests outside the agent's sandbox, and its exit code is the fact.

What this buys

Once the work is lanes, several things stop being hard. Cost drops, because only the hard lanes need the expensive model. Speed rises, because lanes run in parallel in separate worktrees. Quality holds, because the gate is the same for every lane whatever built it.

And one more: I can measure a model. Same lane pack, same pre-fix commit, different model, scored by the same validator. That is module 7.

Set it up

1. Pick one feature you would normally hand over whole. Write down, in one sentence, what "done" means as something observable.
2. Split it into pieces that can each be tested on their own. If a piece needs to watch another piece run, it is not split yet.
3. For one piece, write the failing test first. Run it. Confirm it fails because the feature is missing, not because of a typo.
4. Note which pieces are genuinely hard: an editor, concurrency, crypto, a shared contract. Those stay with the expensive model. Everything else is a candidate for a cheap one.
5. Decide who merges. It is you. Never a lane.

What you can do now

You can describe any feature as a list of lanes, each with a red test and a scope list.

Next module

Module 2 hires the brain: Claude Code, the orchestrate skill set, and the model policy that keeps subagents off the expensive tier.