The single biggest mistake new users make with agentic coding tools like Claude Code and Cursor is jumping straight into build mode. They type "add a feature that does X" and let the agent start writing files immediately. The result is usually code that technically runs but solves the wrong problem, misses edge cases, and is painful to review. Plan first, build second is the habit that separates people who get value from these tools from people who get frustrated.
Why building first fails
An agent is extremely fast at generating code, which feels productive. But speed on the wrong path is just faster wrong. When you skip planning:
- The agent guesses at ambiguous requirements, and guesses wrong.
- Edge cases (empty states, errors, auth, concurrency) never get considered.
- You get a large diff you cannot really review, so you accept it on faith.
- Rework ends up costing far more than planning would have.
The four phases
Treat every non-trivial task as four phases, in order.
1. Plan. Before any code, ask the agent to help you understand the problem. Have it read the relevant files, restate the goal, and list what it thinks needs to change. Cursor and Claude Code both have a plan or ask mode for exactly this: the agent reasons and proposes without editing. In Claude Code, Plan Mode (Shift+Tab to cycle in) hard-blocks writes until you approve, so the model literally cannot touch files while you align.
2. Discover. Use the agent to surface use cases and edge cases you have not thought of. Prompt it: "What are the edge cases here? What could break? What existing code does this touch?" The agent has read more of your codebase than you hold in memory, so it is good at this.
3. Spec. Turn the plan into a written spec or PRD (see the next lesson). This is the artifact the build phase executes against.
4. Build, then test. Only now switch to build or agent mode. Implement in small, reviewable steps, and treat testing as part of building, not an afterthought. Ask the agent to write and run tests, then fix what fails.
Before and after
A weak, build-first opening:
"Add saved cards to checkout."
The agent picks a data model, a UI spot, and an error strategy on your behalf, and you find out what it chose by reading 600 lines of diff.
A plan-first opening on the same task:
"Read
src/checkout/and explain how the current payment flow works. Do not change anything yet."
Then:
"I want to add saved cards. List the files you would change, the edge cases (expired cards, failed auth, one card vs many, deleting the default card), and open questions. Give me a plan, not code."
Only after the plan looks right:
"Implement step 1 from the plan. Show me the diff before moving on."
A scenario you will actually hit
You ask for "add rate limiting to the API." Build-first, the agent adds an in-memory counter that resets on every deploy and does nothing across multiple instances. Plan-first, the discover step surfaces the real questions (per-user or per-IP, where state lives, what happens on limit) and you catch that you need Redis before a line is written.
Failure modes to watch for
- The agent starts editing during planning. If it jumps to code, stop it: "Plan only, no edits." Use Plan Mode so it cannot.
- A plan that is really a restatement. A good plan names files, sequences steps, and lists risks. "I will add the feature" is not a plan. Push for specifics.
- Approving a plan you skimmed. The plan is the cheap place to catch mistakes. Read it as carefully as you would read the code.
Rules of thumb
- If a task will produce more than about 50 lines of diff, plan it first.
- Never let the first message on a non-trivial task be a build instruction.
- Make the agent restate the goal before it writes anything.
- Approve plans explicitly; treat "start coding" as a separate decision from "here is the plan."
The mindset shift
You are not a typist asking a faster typist to type for you. You are a tech lead directing an eager junior engineer. A good lead does not say "go build the thing." They align on the problem, agree on an approach, and review the work. The plan-first workflow is how you play that role. It feels slower for the first five minutes and is dramatically faster by the end.