AI coding tools have moved fast enough that designers, product folks, and solo founders are now building services directly. The gap between outcomes — using the same tool — comes from how the human operates it. Five operating rules we've settled on, from running our own work and from advising others.
1. Plan around user flow, not features
Hand the AI a feature at a time and it does well within that feature only. Hand it the connective tissue — where the user enters, which screens they cross, what state they leave in — and it starts treating the flow as one design unit.
"Build the signup page" pulls less out of the model than "build the path from landing to signup to first use." Direct it by motion, not by screens, and it sees a service for the first time.
2. Lock the scale before you start
Without an explicit ceiling, AI tends to assume a much larger system than you need. 10,000 concurrent users, multi-region, sophisticated caching layers — baseline-by-default. Infrastructure cost gets unrealistic and code complexity inflates along with it. If you're not an engineer, you can't price the gap in advance.
So state the scale, in stages. "MVP at 50 concurrent users, 500 within six months" gives the AI a real constraint, and it picks the simplest structure that fits.
3. Hand over the brand guide upfront
The most common trap in AI design is collapsing into defaults. Purple gradients, rounded cards, modern-but-anonymous interfaces — without guidance, the model converges there.
Pass the brand guide (color, type, voice, base components) in the first turn and the AI works inside those constraints. If you don't have one yet, write at least notes covering the seven areas we list in why a brand guide is non-negotiable before you start.
4. Question every unfamiliar term, on the spot
The AI rarely surfaces every assumption it's carrying. "We'll authenticate with JWT," "we'll cache in Redis," "we'll settle through Stripe Connect" — accept any of those without understanding, and you'll find the bad fit only after code has piled on top of it. Undoing it then costs tens of times what asking the first question would have.
The rule is plain. Stop on every term you don't understand, and keep asking until the answer is clear. The AI doesn't penalize you for it. Demanding clarity tends to lift the quality of what follows.
5. Finish a draft first, refine after
Trying to write a complete spec before any code keeps stretching. Pick three to five core features, ship a working prototype, then iterate from there. A one-page prototype that runs beats a hundred pages of spec.
Two reasons. First, you find what was missing only by clicking through it — what you imagine and what you encounter on screen always diverge. Second, the AI reasons better on top of a running artifact than on a text spec. With a draft, refinement is fast and precise; without one, the team can't even agree on what to refine.
Closing
Solo development with AI isn't a tooling problem; it's an operating problem. All five rules above address the same gap — not "the AI fails," but "the human under-directs." Apply them and the variance in output, with the same tool, drops immediately.