Getting Started with Plan Mode
A practical guide to using AI planning modes effectively. Stop treating your agent like a magic wand and start treating it like a junior engineer.
2025-11-05
Loading content...
A practical guide to using AI planning modes effectively. Stop treating your agent like a magic wand and start treating it like a junior engineer.
I once watched an agent rewrite my AuthService before it understood we use Clerk. Plan mode fixes that: the model proposes steps and diagrams first, and only edits after you agree.
I asked Cursor to add org switching to a Next app. It opened by replacing AuthService with a hallucinated passport.js setup from 2019. Nothing in our repo uses Passport. Sharper prompts might have slowed the damage. What actually helped was making it plan before it touched a file.
Most AI editors now ship a plan-first mode (Cursor's planning flow in Composer, Claude Code's plan-heavy runs, similar ideas elsewhere). Same contract: read the repo, outline the approach, wait for your okay, then edit.
If I wouldn't hand a new hire a Jira ticket and walk away, I don't hand the whole task to the agent in one shot.
Plan mode is the supervision step. I want the file list, the risks, and the order of operations before anything merges.
My default prompt style is "fix bug." Plan mode wants the opposite.
These context windows are huge. You have 200,000+ tokens to work with. Do you know how much text that is. That is roughly the length of A Court of Thorns and Roses. You are not going to overflow the buffer by chatting.
Be messy. Be verbose. Paste the rough notes, the Slack thread, the worry. "Avatar upload must not block the main thread" is the kind of line I used to edit out of a tidy prompt. In plan mode it belongs front and center.
I talk faster than I type. Two minutes into the mic about session cookies beats a polished one-liner that hides the constraint.
The model also does not know about your internal wiki from last week or the API bump you installed yesterday. If the answer lives in a doc, paste the chunk into the plan. I dump puzzle pieces first, then ask for the assembly plan.
Bullets hide race conditions. I often ask for a Mermaid sequence diagram:
Draw how the user, API route, and database interact for this checkout fix.
When the arrows look wrong, I catch it before code exists.
The first plan is never the final plan. I push back on missing timeout handling, over-engineered state, wrong folders. Five minutes of argument in plan mode has saved me hours reverting a bad Composer run.
I make the agent spell out proof, not just implementation:
npm run build passesIf it is not in the plan, it usually does not happen.
After an hour debugging checkout, the context is full of noise that poisons the next task. Before I plan a new feature, I clear the thread or start fresh.
When the plan is solid:
That is the workflow I use when brainstorming has already polluted a run. Plan in one session, build in another.