The short version
The highest-leverage prompt in existence is asking for the plan before the code.
01
Say what it is for, not just what to make
Ask for a date field and you get a date field. Ask for a date field so customers can pick a delivery day, noting that it should refuse dates in the past and refuse Sundays because you are closed, and you get something that handles the cases you would otherwise discover from an annoyed customer. The purpose carries the edge cases, and the edge cases are where the work actually is.
02
Ask for the plan before the code
For anything beyond a trivial change, ask it to describe its approach first: how it would build the feature, which existing files it would change, what it would add, and what might break — then wait for your approval. This single habit prevents more structural damage than everything else combined, because it turns invisible decisions into a short paragraph you can actually evaluate.
03
Make it explain itself in plain English
After it writes something, ask it to explain what it just did as though to someone who does not code, including what it assumed and what would make it fail. If the explanation does not match what you asked for, you have caught a problem that would otherwise surface in three weeks. If it struggles to explain its own code clearly, that is information too.
04
Surface the decisions it made for you
The silent choices are the ones that hurt later. Ask directly what it decided that you did not specify, and whether there were reasonable alternatives. You will frequently discover a naming convention, a storage approach or a library choice that you would have decided differently — and it is far cheaper to change at that moment than after twenty files depend on it.
05
Make it argue with itself
Models are agreeable by default, which is a liability when you need judgement. Ask what is wrong with the approach, or what a senior engineer reviewing this code would object to. The critique is often more valuable than the original answer, and it costs one message.
06
Stop saying it does not work
It is the least useful thing you can say and it is what almost everyone says. It sends the model guessing, and its guesses will damage working code. Instead: what you did, what you expected, what happened instead, and the exact error text — all of it, not just the first line. If you have been round the same bug three times, stop and start a fresh session, because the context is now poisoned with its own failed attempts.
Go deeper
This is one chapter of a much longer story
Build Your First Real App is the next step: a 120-page prompting course where you build a mini marketplace one checked feature at a time, plus the Northstar visual kit to build against.
See the course — $29.99FAQs
Quick answers
Do I need to learn to code to build with AI?
Not to build. But you do need to understand what your software does at the level of knowing where submitted data goes, because that is the difference between owning a product and owning a demo.
How long should my prompts be?
Long enough to carry the purpose and the constraints. A short prompt with the reason behind it beats a long one that only describes the mechanics.
What if the AI keeps making the same mistake?
Start a new session and restate the problem from scratch with only the relevant files. Long conversations drift because the earliest parts of the discussion fall out of the model's view.