Most disappointing results from AI-assisted development do not come from a bad prompt. They come from asking for something that was never decided in the first place.
You describe an app. The AI produces something plausible within seconds. Then you spend the next hour explaining that no, the list should not reset when the page reloads, and yes, two items can have the same name, and actually the delete button should ask first. Each correction is reasonable. Together they cost more than thinking would have.
The AI did nothing wrong. It filled in the decisions you had not made, quickly and confidently, and it had no way of knowing which of its guesses mattered to you.
Why planning matters more with AI, not less
It is tempting to assume that because implementation got faster, preparation got less important. The opposite tends to be true in practice.
AI removes much of the effort of writing code. It does not remove the need to decide what the code should do. Every gap in your description is still a decision — it is just made by something that cannot ask you what you actually wanted, and that will answer differently next time.
Speed changes the stakes too. Unclear thinking used to surface slowly, while you typed. Now it is built immediately, in volume, and looks finished. By the time the problem is visible, there is a lot more of it.
Planning here does not mean a specification document. It means answering six questions, most of which take a sentence each.
1. Say why this piece of work exists
Start with the outcome you want, not the feature you imagine. One sentence is usually enough.
"Build a task manager" is not a purpose; it is a category of software. "Let me see what I still have to do today, without opening a spreadsheet" is a purpose. It tells you what matters, and it quietly rules things out — you now know that a shared team workspace and a permissions model are not what this is for.
The value of writing it down is that you can check later whether you are still building that, or whether you have drifted into building something adjacent because the AI suggested it and it sounded good.
2. Describe what should visibly happen
Describe behaviour: what someone using the software should be able to do, and what they should see. Resist describing how it works internally — that is the part AI is genuinely good at, and pinning it down early throws away the help.
Compare these two:
- "Implement add functionality with state management."
- "When I type a name and press Add, the item appears at the bottom of the list straight away, and the input box clears."
The second is longer and far more useful. It says what to build and, at the same time, how you will know it worked.
A practical test: could someone else read your description and tell whether the software does it, without asking you any questions? If not, it is not behaviour yet — it is still an intention.
3. Find the decisions you have not noticed you are making
This is the step that saves the most time, and it is the one most often skipped.
Take your behaviour description and look for the questions it does not answer. For a simple list, the usual suspects are:
- What shows before anything has been added?
- Can two items have the same name?
- What happens if the field is empty, or contains only spaces?
- Is there a maximum length? What happens beyond it?
- What order do items appear in — newest first, or oldest?
- Does deleting ask for confirmation?
None of these is difficult. That is the point: they are easy to answer and expensive to leave open. If you do not answer them, they still get answered — silently, by whatever the model considered reasonable at the time, and possibly differently in the next session.
Write your answers down as decisions, not as questions. "Empty input is ignored and the field keeps focus" is a decision you can build and test against. "What should happen with empty input?" is not.
4. Say what must not change
Instructions tell the AI what to do. Constraints tell it where to stop. Both matter, and only one of them tends to get written.
Constraints are things like: do not change the existing styling; do not alter how items are saved; do not add a library for this; do not touch files outside this feature; keep the current behaviour of the edit screen working exactly as it does now.
This is the difference between a change you can review in a few minutes and a change that has quietly rewritten three other things you were happy with. If you have ever asked for a small fix and received a refactor, this is the step that was missing.
5. Cut it down to a first piece that is still useful
The instinct is to describe the whole application. It is a reasonable instinct and it produces poor results, because a large request gives you a large amount of code to verify at once, and no obvious point to go back to when something is wrong.
The useful reduction is not the smallest possible change — it is the smallest change that still does something coherent and can be checked on its own.
So a broad idea like:
Build a simple list application where users can view, add, edit and delete items, with their changes still available when they return.
becomes a first piece of work like:
Display a short list of items when the application opens.
That is unglamorous, and it is the right place to start. It is small enough to read and understand in full, it either works or it does not, and if it goes wrong you have lost very little. Adding, editing, deleting and saving each follow as their own steps, each starting from something that already worked.
6. Decide what "finished" looks like before you build
Write down how you will check the result — before you have a result to be relieved about.
For the first piece above, that might be: open the application; three example items are visible; they are in the order given; nothing else on the page has changed.
This takes a minute and it changes what you accept. Without it, the honest test tends to become "it ran without an error", which is not the same as "it does what I asked". It also gives you something concrete to point at when it is wrong, which makes the correction much smaller.
Putting it together
The whole plan for one small piece of work can be shorter than this paragraph list suggests:
- Purpose — I want to see my remaining tasks for today at a glance.
- Behaviour — When the application opens, my saved items appear in a single list, oldest first.
- Decisions — Empty list shows "Nothing yet". Duplicate names are allowed. Items are never truncated.
- Constraints — Do not change the existing page layout or add any new dependency.
- Check — Open the app: the three example items appear, in order, and nothing else has moved.
That is perhaps two minutes of thinking. It can prevent a long sequence of corrections later.
A reusable checklist
Before your next request, answer these six:
- Why does this piece of work exist?
- What should visibly happen?
- Which decisions am I currently leaving to the AI?
- What must not change?
- What is the smallest version of this that is still useful?
- How will I know it worked?
A fuller version of the same pass, covering what to check when the result arrives and what to do before starting the next piece, is the planning checklist.
Where this fits
Planning is the front half of a cycle. The rest is building the accepted description, testing the result against it, correcting narrowly when it is wrong, and keeping a working version you can return to before you start the next piece.
That full cycle is the PDAID method — Prompt-Driven AI Development — and the steps above are its opening phases in practice. If you want the complete method, with a worked application built increment by increment, it is set out in Build Software Using AI.
One honest caveat. Planning well makes AI-assisted development far more predictable, and it does not make technical judgement unnecessary. As a project grows, and particularly where security, personal data, payments or safety are involved, there is no substitute for someone who genuinely understands what the code is doing — a judgement worth making deliberately rather than by default, and set out in when to get a professional to look at it. Clear thinking gets you a great deal further than it used to. It does not get you all the way, on its own, everywhere.