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.

How I Use AI Without Letting AI Make Product Decisions

AI is exceptional at execution and genuinely dangerous as a decider — so the line I hold is simple: 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). This is the single rule that separates AI as leverage from AI as a demo factory. Used as fast hands under human product judgment, AI lets one person ship what used to take a team. Used 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, exploring options, turning a clear instruction into working code fast. This is real leverage — most of why a solo builder can now run a small studio of products is that the how got cheap. I lean on it hard, every day.

Where it must not decide

The trouble starts when AI drifts from executing 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 makes a product sharp.
What to charge — the model and the number.

These are judgment calls grounded in lived understanding of a real problem and a point of view. AI has neither. It can inform them — options, drafts, pros and cons — but the decision has to be mine.

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's the opposite of what a product needs. Products win by being specific and opinionated — by doing one real thing sharply and refusing the rest. Ask AI to decide what to build and it will smooth toward the generic, giving 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 — often written down as the problem and the outcome before I open the editor — and then I use AI to execute that, fast. When AI proposes a direction, I treat it as an option to judge, not an answer to accept. The moment I notice I'm building something because AI suggested it rather than because it serves the decided outcome, I stop. That catch is the whole skill.

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. AI's output sounds right, which makes it easy to accept decisions 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 — being so wary of AI that 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 moment you're building AI's idea instead of your decision. 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.