Plan before you build: getting the most out of plan mode

The most expensive thing an agent can do is confidently build the wrong thing. It writes across a dozen files, you realize the approach is off, and now you are unwinding real changes instead of correcting a paragraph. Plan mode exists to stop exactly that. It makes Claude Code research the task and propose an approach first, then wait for you to approve it before it changes anything. It is the single cheapest habit in this whole series, and here is how I use it.

What plan mode does

In plan mode, Claude Code works read-only. It can look at your files, search the codebase, and think through the task, but it cannot edit, create, or run commands that make changes. Instead of diving in, it comes back with a plan: what it intends to do, in what order, and which files it will touch. Nothing happens to your code until you approve that plan and let it proceed.

You get to catch a bad approach while it is still just words on the screen, which costs nothing to fix, instead of after it is spread across your working tree.

How to turn it on

• In a session: press Shift+Tab to cycle through the permission modes until you land on plan mode. Ask your question, and Claude will plan instead of build.
• At launch: start Claude Code in plan mode when you already know the task is big enough to warrant it.

Either way, the flow is the same: you describe the task, Claude proposes a plan, you read it, and you either approve it or send it back for changes.

Getting a good plan

A plan is only as good as what you put into it. A few things make a real difference:

• Sharpen the request first. A vague ask produces a vague plan. This is where meta-prompting pays off: get the request clear, then ask for the plan.
• Read the plan like a reviewer. Does it touch files it should not? Does it miss a case you care about? Is the order sensible? This 30-second read is the whole return on the technique.
• Push back before you approve. "Do not change the public API," "leave the tests alone," "do the smallest version first." Correcting the plan is free; correcting the code is not.
• Approve, then let it run. Once the plan is right, the build tends to go straight through, because the thinking already happened.

Why it saves money, not just mistakes

Every redo loop, build, notice it is wrong, re-explain, rebuild, is tokens spent twice and a context window filling up with false starts. Those false starts are exactly what drags a session toward context rot and cache-miss cost spikes. Planning first collapses that loop: you spend a little to get the approach right once, instead of a lot to discover it through failed attempts. It is the front-loaded-clarity idea from managing context, applied to the approach itself.

When to use it

• Anything that touches more than a file or two. The bigger the change, the more a wrong turn costs to unwind.
• Unfamiliar code. When you are not sure how something is wired, let Claude map it and propose an approach before it edits.
• When correctness matters more than speed. A migration, a refactor, anything you would hate to get half-wrong.

For a small, obvious edit, plan mode is overkill, just make the change. But for real work, planning first is the habit that most reliably keeps a Claude Code session out of the expensive redo loop.