Claude Code Plan Mode: Why Your AI Limit Is Really a Direction Problem

Two things go wrong when you use AI for real work.

You run out of limit before lunch. And what comes back still is not right.

Most people treat those as separate problems. They go looking for a bigger plan to fix the first one and a better prompt to fix the second. Go looking and you will find a hundred people selling you both.

They are the same problem.

You Paid For The Job Twice

You asked it to guess. Then you let it do the whole job on that guess.

It picked a direction. You found out after it finished. So you ran it again. That second run is where your limit went, and you are still not happy with the result.

Look at what being wrong actually costs at each stage.

Where you catch it	What it costs
While the plan is still on screen	One line. Ten seconds.
Just after you hit go	Stop, correct, restart. A few minutes.
When the full run finishes	The whole job again. Your time, your limit, your patience.

The question was never whether to plan or just go. It was where you would rather be wrong. Because you will be wrong sometimes. Everyone is.

Plan first and you are wrong on a page. Skip it and you are wrong on a deliverable.

What Claude Code Plan Mode Actually Does

Plan mode is one of Claude Code's permission modes. Claude reads your files and runs commands to explore, then writes a plan. It does not edit your source, and edits stay blocked until you approve.

That is the difference between plan mode and accept edits mode, which is where most people live by default. Accept edits auto-approves file changes so Claude can keep moving. Plan mode does the opposite: nothing gets written until you have read the thing and said yes. Use plan mode while the direction is still in question, and accept edits once it is settled.

If you have not used Claude Code itself yet, the DevWiz team wrote a good ground-level piece on Claude Code as an AI coding agent, covering what it does and where it stops being useful.

That restriction is enforced by the tool rather than by good manners, so it cannot get carried away and start building while you were still thinking.

Three ways in:

• Prefix a single prompt with /plan. Simplest, and it is what I use.
• Press Shift and Tab to cycle the permission modes. The bar reads plan mode on when you land.
• Pick Plan from the mode selector in the desktop app, VS Code, JetBrains or claude.ai.

On Windows, Shift and Tab does not always register, because some Node and Bun runtimes do not enable VT input mode. Use Alt and M instead.

That is the whole technical bit. Everything that matters is in how you talk to it.

Talk, Do Not Type

I dictate. Five to ten minutes, out loud, on what we are doing and why.

Typing makes you terse. You write four lines and think you have been clear. Talking makes you ramble, and rambling is exactly what you want here. You mention the client. You mention the thing that went wrong last time. You mention the constraint you would never have bothered typing.

All of that is context, and context is the whole game. The model knows a little about a lot and nothing about your business. Plan mode is where you hand over the part only you have.

Then finish with this line:

Use the ask_user_question tool. Drill down and ask me everything you need. I do not want to leave any stone unturned.

One word, ask_user_question, no spaces.

Left alone, the model fills the gaps in your brief by guessing. This makes it interrogate you instead. It comes back with multiple-choice questions, usually double or triple what you expected, and it asks about things you had not thought of.

Every gap it finds there is a gap you do not pay for later.

Four Jobs That Always Get A Plan

Not everything needs one. The short answer is anything significant.

1. Starting from scratch. A new build, a new document set, a new system.
2. Designing something. A dashboard, a structure, an architecture. Anywhere the shape matters more than the words.
3. Adding a big feature to something that already works.
4. Fixing something that is wrong across the whole thing. This one gets missed. When I find a mistake repeated everywhere, I do not fix it file by file. I go into plan mode and say: you have not done this properly across all of them, here is how it should be, give me a plan to revise it everywhere.

You also do not have to plan a whole project in one go, and on anything complex you should not. Plan the architecture. Then plan the database. Then plan the mapping. New part of the project, new plan.

If It Comes Back Fast, It Is Thin

This is where most people fall over. They get a plan, glance at it, and say yep, go.

That is the same as not planning.

A real plan takes time. Fifteen minutes is normal, twenty is common, sometimes longer. We got used to instant answers and genuinely useful AI work is not instant. So if a plan lands in thirty seconds, do not accept it. Ask whether it has been thorough and whether that is as detailed as it can go.

You know your business better than it does. Read the plan and mark it up like a junior wrote it: you have missed this, this bit is great, drop that entirely, wrong order.

Get the plan right first. Then hit go. Most of the biggest AI implementation mistakes I see are versions of skipping that step.

Put The Heavy Model Where The Thinking Is

Planning is thinking work. Drafting and volume work is not. The lazy version is to run everything on the heaviest model, and that is the most common way people blow their limit.

Set the model to opusplan. Opus does the planning, Sonnet does the execution, and it switches automatically when you approve the plan.

Worth checking what you are already on. Max, Team Premium, Enterprise pay-as-you-go and the API all default to Opus 5. Pro and Team Standard default to Sonnet 5. If you are on Max and have never touched your model setting, you are running the heavy model for everything, including the work that does not need it.

The Bit That Changes Your Day

Plan mode is slow. That is the feature. But it means you cannot fire a plan at the moment you need the work done.

So do not. Fire them all first thing, before anything else lands.

Three or four tasks, about fifteen minutes of planning each, all running while you get on with something else. By the time the last one is going, the first is ready to read. That is one hour at the front of the day, and it is the difference between opening a project at quarter to four with nothing and opening one with the thinking already paid for.

The full routine, the 10 / 80 / 10 split behind it, and the seven ways people get this wrong are in the guide: Claude Plan Mode: The First Hour That Pays For The Whole Day.

If you are earlier than that and still working out where Claude Code fits at all, start with Claude Code for non-technical founders.

The Last Thing

Burning your limit feels like a pricing problem. Getting slop back feels like a prompt problem.

Neither one is it.

That is a direction problem. Fix the direction while it is still cheap.