You would not let a contractor start knocking down walls before telling you which walls. Same reflex here, and for the same reason.
What a plan gets you
Ask for one in words and you get one:
Before changing anything, tell me how you would do this and which files you would touch.
Claude Code also has a for exactly this: it explores the project and proposes an approach, holding back edits until you approve. You switch modes from inside the session — the current key combination is shown in the interface, and /help will tell you what it is in your version.
Either way the deal is the same. It reads, it thinks, it writes down what it intends to do. Nothing changes on disk yet.
How to read a plan in thirty seconds
Not word by word. Look for four things:
- The files. Are they the ones you expected? An unexpected file is either a good catch or a misunderstanding, and both are worth one sentence right now.
- The outcome. Does its description of “done” match yours?
- The unasked-for extras. “I will also update the tests and reformat the module” — do you want that? Sometimes yes. Say so, either way.
- The uncertainty. A plan that admits a gap is more useful than one that does not. If it says “assuming prices are in cents”, check whether they are.
Quick check
The plan is correct in every detail except it lists a file you have never heard of. What now?
Plans are also for you
There is a second, sneakier benefit. Reading a plan forces you to actually decide what you want.
Plenty of vague requests survive right up until someone writes down the concrete steps and you realise you had not decided whether the discount applies before or after tax. The agent did not know either — it was about to guess.
Turn the plan into your checklist
Once the plan is agreed, it doubles as the review list. When the work is done, walk the plan step by step against the actual change. Anything in the change that is not in the plan deserves a look.
When not to bother
Ceremony should scale with damage.
- Skip it for a typo, a copy change, a one-line fix — with the project committed to Git first, so undo is one command.
- Insist on it for anything touching several files, changing data, adding a dependency, or altering how something is stored.
Approving a plan is not the same as approving the result
A plan you agreed with can still be implemented badly. The plan says what was intended; the change says what happened. Review both. Level 2 is where reading the change becomes a habit.
Does asking for a plan slow me down?
What if the plan is right but I do not understand part of it?
Try it yourself
A plan with an assumption buried in it. Read it, question it, or skip the whole thing.