The expensive model shouldn't be doing the typing

Last night my most expensive AI model didn't write a single line of code. Everything still got built: a mobile layout bug fixed and proven with screenshots, a cancel button added to a search page, a nasty data-loss bug in my dictation app root-caused and patched. The code was written by a model that costs a fraction as much. The expensive one wrote the work orders and reviewed the diffs.

I didn't arrive at this out of wisdom. It started as rationing. The model I like best is the priciest one in the lineup, and I kept burning through my plan's allowance on work that, looking back, was mostly typing. So I got stingy with it, and the stingy setup turned out to work better than the lazy one.

The lazy default

Here is the pattern I see everywhere, including in my own house until recently: pick the best model available, point it at everything, done. At work nobody even asks, the company pays, so every little refactor and every log grep runs on the top-shelf model. At home, people on a 20 dollar plan do the same thing and then wonder why they're out of tokens by Tuesday.

The unspoken assumption is that the best model produces the best result on every task. That's true for the hard ten percent: architecture, tricky debugging, decisions with consequences. For the other ninety percent, the result depends far less on which model types the code and far more on how well the task was specified. A mid-tier model with a tight spec beats a frontier model with a vague one, and it isn't close.

What the split actually looks like

So here is how my setup runs now. The expensive model is the architect. Before any work gets delegated, it reads the actual code, forms its own diagnosis, and writes a work order. Mine always has the same five parts:

1. What happened, in the user's own words, and why it matters.
2. A mandatory read-the-spec-first step, pointing at the project's source-of-truth doc.
3. The facts it already verified in the code, down to line numbers, marked with an explicit instruction: verify these, don't trust me blindly.
4. Numbered required changes, with the judgment calls the implementer is allowed to make labeled as judgment calls.
5. A verification section that spells out what proof must come back: assertions, screenshots, failure-scenario traces, whatever fits the job.

Then a cheaper model does the implementation, runs the verification, and reports raw facts. The architect reads the report, checks the screenshots, and either accepts or sends it back in.

Point 3 is the one that earns its keep. Handing over verified findings gives the implementer a running start. Framing them as claims to re-check keeps it able to catch the architect being wrong, and it does catch things. The report that comes back with "your line number was right but the actual cause was one level up" is the system working, not failing.

Does the quality hold up?

Yes, and I was surprised too. The mobile bug came back with the root cause isolated to a single mis-sized flex element, proof screenshots at phone and desktop widths, and a before-and-after assertion that the page no longer overflows. The dictation app fix came back with three written failure-scenario traces showing exactly what a user sees in each case. I have received worse work from expensive models running unsupervised, because unsupervised is the part that actually costs you, not the model tier.

The clearest demonstration was a translation job. A 300 page book, English to Spanish, for a friend who wanted to read it. I had the mid-tier model chunk it by paragraphs, translate with a fixed glossary so key terms stay consistent across the whole book, stitch it back together, and produce a finished PDF. Thirty two minutes, quality that reads like it was written in Spanish, and it cost me nothing beyond plan quota I had already paid for. Running that through the top model would have produced the same book while eating the tokens I'd rather spend on things that need actual thinking.

The catch, because there is one

The spec is the work. If you hand a cheap model "make search cancellable" you will get a mess, and you'll conclude cheap models are useless. The half hour the architect model spends reading code and writing the work order is real effort that used to be invisible inside "just let the big model do it". You are not saving that thinking, you are moving it where it pays.

And you still review. The architect reads every diff and looks at every screenshot before anything is called done. The one time I let a report through on trust, a Stop button that tested clean left two spinners running forever on the page, and I was the one who found it, on my phone, after telling myself the report looked thorough :)

Review for slop, not just for bugs

There's a second thing the architect's review pass is for, and it might matter more over time than the bug catching. Machine-written code has tells. Comments that restate the line below them. A Manager class wrapping a Handler class wrapping one function. An options object nobody ever passes. The standard library reimplemented because the model didn't look. None of it is wrong exactly, it compiles and the tests pass, but six months of merging that and you own a codebase nobody can read.

So the review step asks a different question than the tests do: could this diff do the same job with less? When the answer is yes, the work order goes back with the specific cuts named, not "make it simpler" but "these two wrappers collapse into one function, this comment goes, this null check is dead". A second model reviewing the first also fixes a quiet problem with letting one model do everything: the author grading its own homework. My commits already go through a security scan and a code review in TerminalNexus before they land, and this simplification pass is the same species of gate, aimed at readability instead of vulnerabilities.

The specific instructions are the point. A cheap implementer told exactly what to cut does it cleanly. A cheap implementer told to "reduce complexity" invents new complexity to manage the reduction :)

So, if you're on a flat plan and hitting limits, or you're the person at work whose team burns API budget like it's free: try the split for a week. Big model writes the spec and reviews, small model types and proves. My experience says you lose nothing you'll miss, and the allowance suddenly lasts the whole week.

Thanks for reading.