Plan Before Code
Force a planning step before any code so the model surfaces assumptions and architecture you can correct cheaply.
TL;DR
- Ask for a plan before any code; review the plan, then tell the model to implement it.
- Planning surfaces assumptions and design choices while they are still cheap to change.
- This single habit reportedly lifts success on complex tasks from roughly one third to two thirds.
Why Plan First
Cheap CorrectionsFixing a plan is a sentence; fixing a wrong implementation is a rewrite.
Edit one plan step <<< re-do 5 files.Surfaces AssumptionsThe plan makes the model's hidden guesses visible before they harden into code.
"Assumes the API returns ISO dates."
-> you catch it if it is wrong.Big Success JumpA deliberate planning step markedly raises success on complex tasks.
~1/3 -> ~2/3 success on hard tasks
(reported by practitioners).Ask For The Plan
Request StructureAsk for files to touch, the approach, and assumptions, no code yet.
"Before coding, give a plan: files to
change, approach, assumptions. No code."Request OptionsFor design decisions, ask for a couple of approaches with trade-offs.
"Propose 2 approaches with trade-offs
and recommend one."Hold The CodeExplicitly tell the model to stop after the plan and wait.
"Stop after the plan and wait for my go."Review The Plan
Check AssumptionsCorrect any wrong premise before a line of code depends on it.
"Dates are epoch ms, not ISO. Adjust."Check ScopeTrim steps that over-reach or touch files that should stay untouched.
"Do not change the auth module.
Keep it to the reducer."Approve ExplicitlyGive a clear go so the model implements the agreed plan, not a new idea.
"Plan looks good. Implement steps 1-3."Then Implement
Reference The PlanTie the implementation back to the approved steps.
"Implement the plan above, step by step."Checkpoint Long TasksFor big plans, implement in stages and review each before continuing.
"Do step 1, then pause for review."Keep The Plan VisibleA written plan doubles as the spec you verify the result against.
Compare the diff to the plan:
did it do what we agreed?Tips
- Have the plan list files to change, the approach, and any assumptions, so you can catch wrong turns early.
- Approve or edit the plan explicitly before you say 'now implement it'.
Warnings
- Skipping planning on a multi-step task invites the model to commit to a wrong design and build on it.
- A plan you did not read is worthless; the value is in catching the bad step before code exists.
In Practice
A two-message pattern for a feature that spans files. The first message asks only for a plan; after you correct it, the second authorizes implementation.
- Message one forbids code and asks for files, approach, and assumptions.
- You read the plan and fix the one wrong assumption before any code exists.
- Message two approves the corrected plan and scopes the implementation.
- The final diff can be checked directly against the agreed steps.
# MESSAGE 1 (plan only)
Add rate limiting to our Express API.
Before writing code, give me a plan:
- which files you will change
- the approach (algorithm, storage)
- assumptions you are making
Do not write code yet.
# (model proposes in-memory token bucket)
# YOUR REPLY
We run multiple instances, so in-memory
won't work. Use Redis. Update the plan.
# MESSAGE 2 (implement)
Good. Implement the Redis plan, step by step,
and add one test. Pause after the middleware
before wiring it into the app.FAQ
Without it, the model jumps straight to code and bakes in whatever assumptions it made along the way. A plan exposes those assumptions and the intended structure as text, which is far cheaper to correct than a wrong implementation spread across files.
It is a practical form of it. You are asking the model to reason through the approach before producing the answer. The difference is that you review and approve the reasoning, turning it into a checkpoint rather than hidden scratch work.
No. A one-line utility does not. Reach for planning when a task spans multiple files, has design choices, or where a wrong assumption would be expensive, which is most non-trivial work.
Enough to spot a wrong turn: the files or modules affected, the approach, key data shapes, and any assumptions. You do not need pseudocode for every line, just the decisions you would want to veto.