Plan before you prompt
The difference between a demo and a product is not a better model. It is whether you broke the work into pieces before you asked for it.
The first time you watch a coding agent build a screen from one sentence, it feels like magic. You think, this is insane! This app is going to build itself. Describe the thing, get the thing.
It works for a while. Then, somewhere around the fourth or fifth feature, it stops working. The agent changes something you did not ask it to change. A feature that worked yesterday is broken today. You find yourself writing longer and longer prompts to steer it, and spending more time reading its output than you would have spent writing the code.
This is not a model problem. It is a planning problem, and it is the same one every software team has had since before AI.
read the rest, free
Enter your email to unlock the article. You will also get the AI Builder's Newsletter, practical notes on building & shipping products with AI from the team at PO2 Studio.
No payment, no card, nothing else to fill in. Unsubscribe any time.
By continuing you agree to receive the PO2 newsletter. We use your email for that and nothing else. Privacy policy.
Decide before you prompt
"Build me a booking app" is a wish. It leaves every real decision to AI: What gets booked, by whom, what happens when two people want the same slot, what the owner sees, what an email says. A human developer would come back with twenty questions. An agent will answer them for you, silently.
The fix is to make any crucial decisions before you ask, in writing, in pieces small enough that each important feature can be built and checked on its own.
Break it into issues
The way we do this is to break the product into features and write each one up as an issue before any code exists.
An issue is short. It says what the user can do once the feature exists, what it should look like roughly, and what "done" means. "A visitor can pick a date and a time from the slots that are still free, and sees a confirmation with the details" is enough. It does not say how, so AI can still decide on the best way to do the hard parts.
Review the plan, not the code
Here is the part most people skip. Before the agent builds an issue, ask it to write an implementation plan for that issue. Which files will change, what new pieces are needed, how it will check its own work.
Then read the plan. Not the code, the plan. You can read a plan in two minutes and you will catch the wrong assumption, the missing case, the thing it was about to change that it should not touch. Correcting a plan costs you a sentence. Correcting the code afterwards costs you an evening.
Only when the plan is right do you say go.
Ship early, test often
With the work in issues and each issue planned, the build itself is mostly just watching AI work, which is what you want. Agents can run on your laptop or on a cloud machine while you do something else, and let you know when they need a decision.
Deploy early, to a real URL, before the product is finished. Make sure to test each big change manually before moving on to the next.
Clarity is the new bottleneck
The leverage has moved. The bottleneck used to be finding someone who could build the thing. Now the bottleneck is being clear about what the thing is, one piece at a time.
That’s good news, because clarity about what you want is the part founders were always supposed to focus on.
Plan first, prompt second, and the agent becomes the fast, tireless executor that will do exactly as you want.
