Technique — plan first, code second
ten lines of text instead of two hundred lines of rework
What it is
The technique is simple: before asking for code, ask for a plan. Let the AI write down what it intends to do — and you check whether that matches what you had in mind.
The benefit is in where the mismatch shows up. A wrong plan is visible in half a minute; wrong code, an hour later, once it is already woven into the project and growing call sites.
What it looks like in code
How to ask
Don't write code. First lay out a plan:
- which files you will touch and what changes in each
- which functions you will add, with signatures
- what could break in the existing code
I'll wait for the plan, then tell you what to adjust.The sentence "don't write code" is needed literally: without it the AI writes both the plan and the code at once, and the point of the technique is lost — nobody reads a plan with a finished solution sitting underneath it.
What to check in the plan
Not everything, four things:
| What we look at | Warning sign |
|---|---|
| The list of files | more files than you expected |
| The signatures | arguments you had not anticipated |
| "What could break" | empty, or "nothing" |
| The order of steps | it starts by reworking something that works |
An empty "what could break" section is the most reliable sign that the AI did not think about consequences but listed its wishes.
What to tell the AI
Adjusting a plan is an ordinary conversation; there is no need to rewrite the whole prompt:
The plan is broadly right, but:
1. don't touch storage.py, leave the subscriptions as they are
2. two functions instead of a new class
3. start with the migration, not with the handlers
Rewrite the plan with that in mind.When the plan is fine, one sentence:
Plan accepted, work to it. If along the way you find the plan
doesn't work, stop and tell me rather than inventing another
solution on the fly.The second sentence matters. Without it the AI, on hitting an obstacle, will quietly turn aside, and you get code that does not match the agreed plan.
When the technique isn't needed
For one-line changes (article 3.3) a plan is wasted time. The technique pays off where more than one file is involved or where rolling back is expensive.
What to look for
A suspiciously smooth plan. Every step simple, no risks, all of it fits in three bullets. Usually that means the difficulty was not found, not that there is none. Ask: "what is the riskiest thing in this plan?"
The code doesn't match the plan. It happens, especially in long sessions. When accepting the work, compare: the same files? the same signatures?
A plan as a way of stalling. If plans are requested three times in a row and reworked each time, the problem is not the plan — the task is not clearly stated. Go back to step 1 of the working cycle.
Cheat sheet
"Don't write code" is a required sentence; otherwise you get both at once.
In the plan, check: files, signatures, what breaks, the order of steps.
An empty "what could break" means consequences were not considered.
"If you get stuck, stop and say so rather than improvising."
Keep the accepted plan next to the task.
For one-line changes the technique is unnecessary.