Notes from building an AI design collaborator · part 9
It worked great on the smart model. Then I ran it on a cheaper one.
· 3 min read
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, invented 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 cheap model had no spare common sense to lend me. It just did exactly what the words said, and the words said less than I thought.
So I stopped writing for the clever one
The fix wasn't a better model. It was instructions that don't need one.
Two things changed. First, I stopped keeping the state of the project in prose. "We're on wireframes and the IA is approved" is a sentence the clever model infers and the cheap one loses. So that moved into a little file the model reads at the top of every turn. Not a hint to interpret, a fact to look up.
Second, every step got a plain contract at the top. What you must have before you start, what you produce, the gate you stop at. The clever model never needed it. The cheap one lived or died by it.
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. 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.
Part of a series on building an AI collaborator for our design team at Xflow. Each post stands on its own.
- ai
- agents
- prompting
The rest of Notes from building an AI design collaborator
- 1. I stopped describing my product to AI. I just gave it the HTML.
- 2. I gave the AI my design process, not my design decisions
- 3. I turned my design process into a dozen small skills, not one giant prompt
- 4. I built a free tool that gives your AI your real product
- 5. I taught the AI to push designs into Figma. Then it quietly stopped.
- 6. We rebuilt our Figma design system out of the code, not the other way round
- 7. We ran our design process on itself, and it broke in useful ways
- 8. How do you teach an AI your taste?
- 10. The AI told me our brand colour with total confidence, and it was wrong
- 11. A screen list lies. I found a whole feature I didn't know we shipped.
- 12. Our documentation updates itself, because updating it is the AI's job
- 13. I sat down to turn my workflow into a swarm of agents. Most of it refused.
- 14. Every modal in our app shared one URL. Our analytics couldn't tell them apart.
- 15. My AI's rules only worked because one tool bothered to read them
- 16. Six designers, one GitHub account, and a script that saves us from ourselves
- 17. "Out of scope" usually means "we'll repaint this in six months"