Claude Code Plan Mode (Measure Twice, Let It Cut Once)

I grew up working construction with my dad.

He had this thing he would say when I was hustling to get a cut done so I could go do literally anything else. Measure twice, cut once. Because a 2x4 does not have an undo button, and neither does the money that paid for it.

I think about him every time I watch somebody brand new fire up Claude Code, point it at a project they actually care about, and tell it to start cutting.

Because here is what a lot of beginners do not realize until it costs them an afternoon. Claude Code is not a chatbot that talks about your project. It is an agent with its hands on your actual files. Which is the whole reason it is useful... and the whole reason you want it to measure first.

That is what plan mode is. The measuring. And it might be the highest-leverage habit in the entire tool, because it costs you two keystrokes and it saves you the worst afternoons this hobby has to offer.

What Plan Mode Actually Is

Claude Code has permission modes, and plan mode is the careful one.

Inside a session, hit Shift+Tab to cycle through the modes. Two taps from the default and you are in plan mode, and the little indicator at the bottom of the terminal confirms it. If you already know a task is chunky, you can start there from the jump.

claude --permission-mode plan

In plan mode, Claude is read-only. It will open your files, search the project, trace how things connect, and think hard about the problem. What it will not do is edit a single thing. Instead it comes back with a proposed plan, in plain English, and waits for you to say yes, no, or "not like that."

Approve the plan and it shifts gears and starts building, with the plan as its marching orders. Reject it, or push back on a piece of it, and you are just... talking. About an approach. To a project that has not been touched. Read that sentence again if you have ever spent a night un-breaking something.

It is not a separate feature you visit on special occasions. It is a posture. Research first, touch nothing, show your work.

Why Beginners Should Live in It

Here is a line I have said before and will keep saying, because it is the entire mental model. A chatbot gives you bad advice. An agent with file access ACTS on bad advice.

When Claude misunderstands you in a chat window, you lose nothing but a moment of your life. When it misunderstands you with edit permissions, you get to watch it confidently rework a pile of files off a guess you never made... while you flip a sh*t in real time.

Plan mode converts that entire category of disaster into a paragraph. A bad guess in plan mode is just a plan you read, frown at, and correct. Nothing to revert, nothing to untangle, nobody crying into their keyboard.

And for those of us who did not come up through code, there is a second reason that matters even more. You might not be able to review a diff. You CAN review a plan. Plans are written in English. "I will modify the checkout page to also update the inventory count" is a sentence any operator on earth can evaluate, because you know your business better than anyone, degree or not.

That makes plan mode the great equalizer. It moves the conversation to the one place where you are the expert in the room. It is a big part of how I get away with building real products without coding experience, and it is the piece I wish someone had shown me in week one instead of month two.

There is a sneaky third benefit too. Reading plans is how you learn. Every plan quietly teaches you what the pieces of your project are called and how they hang together, and after a few dozen of them you start catching problems before Claude does. Nobody sat me down and taught me architecture. The plans did.

My Workflow. Plan First, Poke Holes, Then Build

Here is how this actually runs at my desk, on anything bigger than a trivial fix.

First, I describe the job in plan mode with the same detail I would give a subcontractor. What I want, who it affects, what already exists that it should not disturb.

Then Claude comes back with its plan, and this is where most people go wrong. They skim it, feel a warm sense of progress, and hit approve. Do not do that. The plan is not a formality. The plan is the product at this stage.

So I poke holes in it. Out loud, in the session.

"What files are you going to touch, and why each one?"

"What are you NOT going to do here?"

"What could this break that neither of us is thinking about?"

"Is there a simpler version that gets me ninety percent of this?"

Claude answers, and the plan gets sharper every round. Sometimes it catches its own bad assumption. Sometimes I catch it, usually on the business side, because it cannot know that a certain client is grandfathered on old pricing or that the "unused" field is the one thing three automations hang off of. That is knowledge only the operator has, and the plan review is where it gets injected. Either way, the cost is minutes, not an evening of reverting commits.

On the really big jobs, I add one more move. I have Claude write the final plan to a file in the project before we start. If the session dies, drifts, or runs long enough to get foggy, the blueprint is sitting on paper where a fresh session can pick it right up.

THEN I tab out of plan mode and let it build. And here is the part nobody warns you about... the build phase gets boring. It just executes the thing we already agreed on, step by step, and boring is exactly what you want from the phase where files are being edited. Boring builds ship.

I put 800 to 900 hours into building my CRM with Claude Code, and an embarrassing chunk of the early hours were cleanup from letting it act on a guess I never checked. The plan-first habit is the single biggest reason the later months went faster than the early weeks. It slots straight into the read, plan, act, verify loop I walked through in how to use Claude Code, and it is the step beginners skip most.

When to Skip It

Now the honest other half, because I am not trying to hand you a ritual.

Skip plan mode when you are just asking questions. "What does this file do" and "explain how login works" touch nothing, so there is nothing to protect.

Skip it for one-line fixes you will see plainly in the diff. A typo, a color, a copy change. Planning a typo fix is measuring a board four times and never cutting.

Skip it for throwaway experiments in a scratch folder, or when you have made a Git save point and genuinely want to see what happens if you just let it rip. With a save point behind you, the worst case is a rollback and a shrug.

Plan mode is a seatbelt, not a religion. My rule of thumb is blast radius. If I can predict everything the change touches and eyeball it in one look, I let it work. The moment I cannot, we plan.

And remember the modes are a dial, not a door. If you are mid-build and something starts feeling off, tab back into plan mode right there in the session and make it think again before it keeps cutting.

One Last Thing (My Dad Was Right)

Measure twice, cut once was never about being afraid of the saw. My dad loved the saw. It was about respect for the material, because the material was expensive and the cut was permanent.

Your project is the material now. Plan mode is the tape measure, and it is sitting right there, two taps away, every single session.

So let Claude think out loud before you hand it the saw. Poke holes in the plan like it is a bid from a contractor you just met. And then, once the plan survives your questions, get out of the way and let the thing build.

Measure twice. Then let the robot cut.