Plan Mode: Scoping and Approving Work Before It Starts

The cheapest place to catch a bad approach is before any code has been written. That's what plan mode is for.

What a plan mode does

Instead of immediately editing files, a planning step asks the agent to first explain: what it thinks the task is, which files it expects to touch, and the approach it intends to take, all in plain language, before making a single change. You read that plan and either approve it, or redirect it.

❌ Skipping straight to execution:
"Add search to the FAQ page." → agent immediately starts editing
five files, three of which you didn't expect it to touch.

✅ Plan first:
"Add search to the FAQ page." → agent proposes: add a search input
to FaqOutline.tsx, filter the existing question list client-side,
no new dependencies, no changes to the API. You confirm, then it builds.

What a good plan includes

• Understanding of the goal, restated in its own words, so you can catch a misread requirement immediately.
• Files it expects to touch, so scope creep is visible before it happens, not after.
• The approach, not full code, but enough that you'd know if it picked a bad pattern (e.g. adding a new dependency when the codebase already solves this elsewhere).
• Open questions, a good plan flags ambiguity ("should search be case-sensitive?") instead of silently guessing.

Redirecting a plan is cheap

Correcting a plan takes one sentence. Correcting a 12-file diff that took the wrong approach takes much longer, and by then you've already spent the time reviewing code you're about to throw away. If something in the plan looks off, whether it's touching a file it shouldn't, or picking an approach you don't want, say so before approving it.

When to skip planning

For genuinely tiny, unambiguous changes ("rename this variable," "fix this typo"), a planning step is overhead. Plan mode earns its keep on anything multi-file, anything touching code you didn't write yourself, or anything where you're not 100% sure what "done" looks like yet.