Skipping plan mode and just letting me change things
In one sentence: for a task that isn't quite trivial, instead of having me enter plan mode to investigate, draft a plan, and wait for your sign-off, you just say "go." I dive down one path, and only after I've changed a pile of files do you notice I misread you. The cost of that rework is far higher than the two minutes it would have taken to glance at a plan.
Symptomโ
Here's how I often see you open: the task isn't small โ "switch auth from sessions to JWT," "add multi-tenancy to this service" โ and you say "start working on it," so I do, immediately. I read a few files, pick what feels like a reasonable entry point, and start changing code, creating files, wiring up interfaces.
Progress looks fast, and you get some quiet. Until you come back to the diff and find that what I built isn't the thing at all: I assumed "multi-tenancy" meant splitting databases by header, but you wanted routing by URL subdomain. I've already touched eight files and written two new modules. Now you either live with it or tear it down and start over.
Why this happensโ
My default impulse is to start producing immediately, not to stop and align first. When you hand me a task, I lean toward putting something visible in front of you as fast as I can โ code, files, a diff. I won't insert "let me investigate, write a plan, and wait for your nod" on my own, because from my side that step looks like stalling, and I'm trained to be eager to respond and eager to deliver.
The trouble is this: for an ambiguous task, my understanding of it is something I guessed, not something you confirmed. The less trivial the task, the more directions it could go, and the more likely my guess is wrong. And once I start changing code, the mistake is no longer "a one-sentence misunderstanding" โ it's a fact on the ground, scattered across multiple files.
Plan mode is built exactly for this gap. In plan mode I only read files, only investigate, and only produce a plan; I don't touch your source. The plan sits in front of you, and I don't act until you approve it. It turns "think it through before acting" from a good habit I'll skip into a gate you control โ and the official workflow is precisely four steps: explore โ plan โ implement โ commit, with the first two done entirely in plan mode.
Consequencesโ
- Rework cost gets amplified. Correcting me at the planning stage means editing a few sentences; correcting me at the code stage means reverting multiple files and discarding logic I already wrote in. The same misunderstanding gets more expensive the later you catch it.
- You lose the window to correct me before I act. A plan is the cheapest snapshot of "how I intend to do it." Skip it, and the first time you see my understanding, it's already an eight-file diff โ and reviewing a plan is far faster than reviewing a pile of code.
- A directional error gets buried in the details. I might have the overall direction backwards while the local code looks perfectly respectable. When you review the diff, it's easy to fixate on syntax and boundary conditions and miss that "this whole thing is pointed the wrong way."
- Exploratory tasks suffer most. When you haven't even decided what you want yet, letting me edit directly is letting me lock in your undecided decisions all at once โ and lock them into the code, no less.
What to do insteadโ
Make "plan before executing" your default collaboration stance: for tasks that are non-trivial, high-risk, or exploratory, enter plan mode first. A few moves you can copy directly:
- Enter plan mode at the start, rather than yelling stop after I've already gone astray. In Claude Code, press
Shift+Tabto cycle to plan mode, or specify it at launch:
claude --permission-mode plan
- Have me give you a plan first, not a diff. In plan mode, let me explore first and then write it up:
(plan mode) Read src/auth and figure out how we currently handle sessions and login. Don't change anything yet.
(plan mode) I want to switch auth to JWT. What files need to change? How are tokens signed and verified? Give me a plan.
-
Correct on the plan, then approve before letting me execute. When the plan is laid out, you can have me keep refining it, press
Ctrl+Gto pull the plan into your editor and edit it directly, and approve once you're happy โ approving exits plan mode and switches to execution. -
Don't make small things hard on yourself. Fixing a typo, adding a log line, renaming a variable โ anything where you could describe the diff in one sentence, just have me do it, no need to wrap it in plan mode, which only adds overhead. The line is simple: if you can describe the final diff in one sentence, skip the plan; if you can't, plan first.
This is two sides of the same flaw as "doing by feel what should have had a spec": both skip alignment where alignment was due. Plan mode is that alignment built into the product as a gate โ so use it.
Exampleโ
Before:
You: Make the user service support multi-tenancy
Me: (start editing immediately; on my own reading of "split databases by header," I change eight files and add two modules)
You: (looking at the diff) โฆ I wanted routing by subdomain, not splitting databases. This all has to be redone.
After:
You: (Shift+Tab into plan mode) Make the user service support multi-tenancy
Me: (only read code, only produce a plan) Here's how I plan to do it: resolve the tenant from the request subdomain โ inject it into the request context โ โฆ these are the files involved.
You: Right direction, but put tenant resolution in middleware, don't scatter it across the handlers.
Me: (revise the plan) Adjusted.
You: (approve, exit plan mode) Go ahead.
Me: (execute the confirmed plan, right the first time)
The difference isn't that I got smarter this time. It's that the directional misunderstanding was seen and straightened out while it was still one sentence โ instead of after it grew into eight files.
When the exception appliesโ
Plan mode exists for "I might guess your intent wrong." When there's no ambiguity at all, or a wrong guess costs almost nothing, skipping it and just letting me go is the right call โ wrapping it in plan mode only adds a round-trip:
- You can describe the final diff in one sentence. Fixing a typo, adding a log line, renaming a variable, a mechanical change to your exact instruction โ intent is unambiguous, and a plan would just restate that one sentence.
- A reversible, tightly-scoped small change. The blast radius is one or two files, a mistake is obvious at a glance, rollback costs near zero โ correcting after the fact is faster than aligning up front, so act first and look.
Conversely, the moment a task is ambiguous, spans multiple files, or carries a directional decision ("switch the auth scheme," "add multi-tenancy"), the exception is off โ back to planning first. The test, in one line: if you can describe the final diff in one sentence, skip the plan; if you can't, plan first.
Tool differencesโ
Gemini CLI (as of 2026-06): Gemini CLI has a first-class Plan Mode too (read-only, write tools disabled; cycle with Shift+Tab or launch with --approval-mode=plan), with the same mechanism described here. The difference is the stance: it's on by default for new users, the opposite of the opt-in posture this entry describes, where you have to enter it deliberately. The good news is that the safer stance sits closer to the default; but however near the gate, people still turn it off by hand to save a step โ and this pitfall's root cause (my default impulse to produce immediately) doesn't vanish just because the default flipped.
Cursor (as of 2026-06): Cursor has a first-class Plan Mode too (Shift+Tab to toggle, the same gesture as Claude Code), with the same mechanism: research the code first, ask clarifying questions, produce a reviewable plan, and don't change files. Two Cursor specifics: the plan is directly editable Markdown (you can add or remove to-dos), and it can be saved into .cursor/plans/ to resume later; for complex tasks Cursor will automatically suggest entering Plan Mode. Like Claude Code, it's opt-in (unlike Gemini's on-by-default).
GitHub Copilot (as of 2026-06): VS Code Copilot has a dedicated Plan agent โ it produces a reviewable, step-by-step implementation plan before touching files, opt-in like Claude Code. The coding agent's checkpoint is structured differently: it opens a draft PR and works in the open, so the "plan / review" gate moves to PR review rather than a mode you enter before acting.
Version notesโ
"Align before acting" is a collaboration principle independent of any specific model. But plan mode as a product capability is a Claude Code mechanism: how you enter it (Shift+Tab cycle / --permission-mode plan / a single /plan prefix), the post-approval options (auto-execute / accept edits / review each edit), editing the plan with Ctrl+G, and similar details evolve across versions โ defer to the official permission-mode docs for the version you're running.