It worked great on the smart model. Then I ran it on a cheaper one.

My design workflow ran beautifully. Every step behaved, the gates held, the output was clean, and I was feeling pretty good about myself. Then I did a boring, sensible thing. Some of the steps don't need the expensive model, they're just fetching and formatting, so I pointed one of them at a cheaper, faster model to save a bit of money.

It face-planted in about a minute. It skipped a checkpoint it was meant to stop at, referred to a step that doesn't exist, and marched straight past a decision I was supposed to make. Same instructions, same files, completely different behaviour.

The uncomfortable part wasn't the cheap model. It was realising my instructions had never actually been good. The expensive model had been quietly covering for them the whole time, filling every gap I'd left with its own common sense, so I never found out how many gaps there were.

The step it invented was in my own files

I went looking for where the phantom step came from, fully expecting a hallucination. It wasn't one.

My workflow has nine steps. One document confidently said "all seven steps," left over from when it did. The Figma handoff was numbered step 7 in one file and step 9 in another, because it had moved and only some of its references had. The getting-started guide described a wireframe format we'd retired weeks earlier, using a third numbering scheme of its own.

The cheap model hadn't invented anything. It had faithfully executed a contradiction, and then picked a plausible way through, which is exactly what you'd want from something that can't tell which of two documents you meant. The clever model had been silently resolving the same conflicts for weeks and never mentioned it, the way a good colleague quietly fixes your typos and never says a word.

That's the honest version of "it worked on the smart model." It didn't work. It was being covered for.

So I stopped writing for the clever one

The fix wasn't a better model. It was instructions that don't need one. Three changes, in rough order of how much they mattered.

State moved out of prose and into a file. "We're on wireframes and the IA is approved" is a sentence a clever model infers from context and a cheap one loses. So every feature now has a small state file the model reads at the top of every turn:

feature: settings-redesign
step: 5-lofi-wireframes
route: [REQ, RES, STO, IA, WIR, VAL, COP, PRO, CAN]
approved: [requirements, research, user-stories, ia]
awaiting: wireframe round 2 selection
prior_art: projects/settings-redesign (v1, complete)

Not a hint to interpret. A fact to look up. It's also the file that lets me shut the laptop mid-flow and pick up a week later, which I wrote about when I split the workflow into skills.

Every step got a contract. A fixed header at the top of each one saying what must exist before it starts, what it produces, the gate it stops at, its hard rules, and what it is explicitly not for. The clever model never needed it. The cheap one lived or died by it. Same post as above has the full shape.

Cross-cutting rules got stated once and cited by number. The rules that apply everywhere, like recommend-then-ask, or deliver in chunks rather than one wall of text, had been restated in five or six places in slightly different words. Which is how the numbering drift happened in the first place. Now they exist once, with IDs, and every skill cites the ID rather than paraphrasing the rule. A paraphrase is a fork.

There's a fourth, smaller thing that turned out to matter more than I expected: a written precedence order. When two instructions collide, what I say in the session beats the project file, which beats the individual step's file, which beats the team's shared principles, which beat my personal preferences profile. A clever model guesses that hierarchy correctly. A cheap one guesses, full stop.

Then I ran the cheap model again

It read the state file, saw the wireframes were done and signed off, saw the contract for the next step, and stopped at the gate to ask me, exactly the way the expensive one does. It held on a second run too, on a different feature, including the two things it had failed at the first time: it stopped batching everything into one message, and it didn't invent a shell around the prototype.

Nothing about the model had changed. The only thing that changed was that the instructions had stopped assuming it was smart.

The bit that stuck with me is that this made the expensive model more reliable too. Which told me the contract was the real fix all along, and the clever model had just been generous enough to hide that I'd never written one.

If your setup only works on the best model, you don't have a working setup. You have a working model, and your instructions are along for the ride. The cheap model isn't the problem. It's the test.

---

Part of a series on building an AI collaborator for our design team at Xflow. Each post stands on its own.