How I Use AI Without Letting AI Make Product Decisions
Using AI to build products means AI owns the how — code, scaffolding, drafts — while I keep the what and why: the problem, outcome, cuts and pricing.
The pitch is that AI will build your product. It won't — it'll build your screens. AI is exceptional at execution and genuinely dangerous as a decider, so the line I hold is narrow and I hold it hard: AI does the how (code, scaffolding, drafts, speed), and I keep the what and why — which problem, what outcome, what to cut, what to charge. That one line is the whole difference between AI as leverage and AI as a demo factory. As fast hands under human judgment, it lets one person ship what used to take a team. As the judgment itself, it produces polished software that solves nothing in particular, because AI optimizes for plausible and a product's whole value is being pointed.
What AI is genuinely great at
I use AI heavily and I'm not precious about it. It's outstanding at the execution layer: scaffolding a feature, writing the boilerplate, drafting copy, turning a clear instruction into working code fast — down to the small interaction patterns like a two-step confirm-before-destroy. That's real leverage. The reason I can ship both Delivery Sheet and Listemizde solo on one Nuxt and Supabase stack is that the how got cheap — the part that used to need a team is now the part I delegate. I lean on it hard, every day.
Where it must not decide
The trouble starts the moment AI drifts from executing my decisions to making them. The product decisions are:
- What problem to solve — and whether it's real.
- What the outcome is — what's true when it works.
- What to cut — the ruthless subtraction that keeps a product sharp.
- What to charge — the model and the number.
These are judgment calls grounded in a lived understanding of a real problem and a point of view. AI has neither. It can inform them — options, drafts, the case for and against — but the call has to be mine. Listemizde ranks nobody for money; that's a decision I made because I'd want it as the user, and no amount of averaging would have produced it.
The line, drawn as a table
If you take one thing from this, take the division of labour. Everything above the line is a judgment call that depends on lived understanding of a real problem; everything below it is execution you should delegate hard.
| Layer | The concrete work | Who owns it |
|---|---|---|
| The what & why | Which problem, the outcome, what to cut, what to charge | Me — AI can argue both sides, but never makes the call |
| The how | Scaffolding, boilerplate, first-draft code and copy, refactors, moving fast | AI — pointed at an outcome I've already decided |
| The catch | "Am I building this because it serves the decided outcome, or because AI proposed it?" | Me — the one check that keeps the line from quietly sliding |
The rows never swap. The moment execution work drifts up into a decision — AI choosing what to build, not just how — you're back to a demo factory.
Why AI decides badly
AI generates the most plausible next thing. A product's value is being pointed — sharply solving one real problem and cutting the rest. Plausible and pointed pull in opposite directions, which is why AI left to decide builds things that look finished and solve nothing.
AI is trained toward the average, the likely, the coherent-sounding. That is the opposite of what a product needs. Products win by being specific and opinionated — one real thing done sharply, everything else refused. Ask AI to decide what to build and it smooths toward the middle and hands you something plausible, coherent, and pointless. That's why so many AI-built apps feel like demos: not because AI wrote the code, but because AI made the decisions.
How I keep the line in practice
The discipline is small but constant. I decide the what and why first — usually written down as the problem and the outcome before I open the editor — and then point AI at that, fast. When it proposes a direction, I treat it as an option to judge, not an answer to accept. The moment I catch myself building something because AI suggested it rather than because it serves the decided outcome, I stop. That catch is the whole skill, and it's easy to miss precisely because what AI hands you always reads well.
What usually goes wrong
- Letting AI choose the what. Building whatever AI generates well, so the product drifts toward generic and pointless.
- Mistaking coherence for correctness. The output sounds right, which makes it easy to accept a decision you should have made yourself.
- Polishing a demo. Iterating an AI-decided app to look ever more finished without it ever being pointed at a real problem.
- Under-using it on execution. The opposite error — so wary of AI you give up the real leverage it offers on the how.
Use AI as the fastest executor you've ever had, keep the product decisions — problem, outcome, cuts, price — firmly human, and stop the second you're building AI's idea instead of your own. That line is what turns AI from a demo factory into the thing that lets one person build real products. It's why my operating system treats AI as hands, never as head.
Part of Building AI Products. See also my product operating system and how I decide whether an AI product idea is worth building. The newsletter sends one practical build lesson every two weeks.
Frequently asked questions
How should you use AI to build a product?
Use AI for execution and keep the product decisions human. AI is exceptional at the 'how' — scaffolding, code, boilerplate, first drafts, moving fast — and it lets one person ship what used to need a team. But it should not make the 'what' and 'why' decisions: what problem to solve, what the outcome is, what to cut, what to charge. AI optimizes for plausible rather than pointed, so left to decide it produces polished software that solves nothing in particular. As a fast executor under human product judgment, it's leverage; as the decider, it's a demo factory.
Why do AI-built apps often feel like demos?
Because AI made the product decisions. AI generates what's plausible and average — the most likely next thing — which is exactly wrong for a product, whose value comes from being pointed at a specific real problem and cutting everything else. When AI decides what to build, you get something that looks finished and coherent but isn't sharply solving anyone's actual problem. The fix isn't less AI; it's keeping the product judgment human and using AI only to execute those human decisions quickly.
What product decisions should a human always keep from AI?
The what and the why: which problem to solve, what outcome defines success, what to deliberately leave out, and how to price. These are judgment calls that depend on lived understanding of a real problem and a point of view — precisely what AI lacks. AI can inform them with options and drafts, but the decision has to be yours, because those decisions are what make a product pointed instead of generic, and pointed is the whole value.