The Simplest Claude Code Tip: Make It Plan Before It Writes Any Code
Most bad Claude Code sessions are not a model problem. They start when Claude guesses your intent, picks an approach, and writes 200 lines before you ever see where it was heading. The fix is almost embarrassingly simple: make it show you the plan first, approve it, and only then let it write code.
TL;DR: Before Claude Code writes anything, ask it to explain its plan in plain English: which files it will touch, the approach it will take, and what it will leave alone. Read the plan, correct it if needed, then say "go." You catch a wrong approach in ten seconds instead of reviewing a wrong diff.
Why does plan-first work so well?
When you give Claude Code a task, it has to fill in a hundred small decisions you never spelled out: which file owns this logic, whether to add a new function or extend an old one, how much of the surrounding code to refactor along the way. If it writes immediately, all of those guesses are baked into a diff before you can see them. Reviewing that diff means reverse-engineering its reasoning from the code, which is slow and easy to get wrong.
A plan exposes those decisions while they are still cheap to change. One sentence like "I will add this to a new helper file" tells you instantly whether it understood the task. If it picked the wrong file or the wrong approach, you correct one line of plain English instead of unwinding a finished change.
How do I actually do it?
You have two easy ways, and both work.
-
Just ask. End your request with something like: "Before you write any code, explain your plan: which files you will change, your approach, and what you will not touch. Wait for me to confirm." That single sentence is enough.
-
Use plan mode. Claude Code has a built-in planning mode that researches and drafts a plan without editing files, then waits for your approval before it touches anything. It is the same habit with guardrails so it cannot start coding early.
Either way, the loop is the same: ask, read the plan, correct or approve, then build.
What a good plan should tell you
You are not looking for an essay. A useful plan answers three questions in a few lines:
| The plan should say | Why it matters |
|---|---|
| Which files it will change | Catches it editing the wrong place before any code is written |
| The approach in one or two sentences | Lets you spot a wrong pattern or over-engineering early |
| What it will leave alone | Stops "helpful" refactors and scope creep you never asked for |
If a plan is vague on any of these, that is your signal to push back before it codes, not after.
Won't this slow me down?
It feels like an extra step, but it is faster on anything bigger than a one-liner. Ten seconds reading a plan beats five minutes reading a diff that took the wrong approach, then asking for a redo that carries the same wrong assumptions. The only time you can safely skip it is a trivial, unambiguous change where there is genuinely only one way to do it. For everything else, plan-first is the cheapest insurance you will ever add to your workflow.
This is the kind of small, high-leverage discipline ClockedCode bakes into a setup you paste in once: a tuned global CLAUDE.md, a curated toolset, and the working habits that make Claude Code reliable instead of hit-or-miss. The tip above is free; the rest of the setup is done for you.