Deep Dive First, Plan Second

You ask Claude Code to add a feature. It immediately starts writing files. Sixty seconds later you have working code that solves the wrong problem.

The fix isn't a better prompt. It's a sequence: explore, plan, implement, commit.

The Four-Phase Sequence

Not rigid for the sake of rigid. Each phase produces information the next one can't get any other way.

Phase 1: Explore. Plan Mode. Claude Code reads files, traces imports, checks configs. No writing. You're building a model of what already exists before touching anything.

Phase 2: Plan. Still Plan Mode. Which files change? What's the approach? Where are the edge cases? You review the plan before a single line gets written. Ctrl+G opens it in your text editor so you can hack at it directly.

Phase 3: Implement. Normal Mode. Claude Code writes code against the plan, runs tests, checks the build. The plan keeps it from wandering off to solve adjacent problems it noticed along the way.

Phase 4: Commit. Stage, message, commit. Clean rollback point if anything goes sideways.

Exploring and coding are different cognitive modes. Mash them together and Claude Code makes assumptions instead of checking facts.

Why Code-First Fails

Jumping straight to implementation is the single most common mistake with Claude Code.

It looks right but isn't. The code has correct function names, follows your patterns, even has comments. But did it check whether your database schema matches its assumptions? Whether that utility function actually returns what it thinks? Without exploration, the output is a guess in a nice suit.

Reinventing what's already there. Without reading existing code, Claude Code might reimplement something that already exists in a different form. Or add validation in the wrong layer. Or create a new utility when there's a perfectly good one three directories over.

The patch spiral. First attempt misses context. You correct. Claude Code patches. You find another issue. More patches. Third round, you've got a Frankenstein file nobody can follow. Exploration would've caught all of this upfront.

How to Run Each Phase

Exploration Prompts

Start in Plan Mode. Give Claude Code specific exploration tasks, not vague ones.

# Good exploration prompts
"Read the auth middleware and trace how JWT tokens are validated end-to-end"
"Find all places where user permissions are checked and list the patterns used"
"Check the database schema for the orders table and find all queries that touch it"

"Look at the codebase" gets you a surface-level summary. Useless. "Understand how auth works" is too broad. Point Claude Code at specific files, patterns, or flows.

Planning with Intent

Once exploration is done, ask for a concrete plan. Good plans name specific files, describe each change, and call out risks.

## Plan: Add rate limiting to API routes
 
1. Create `lib/rate-limit.ts` with sliding window implementation
2. Modify `middleware.ts` to check rate limit before routing
3. Add `RATE_LIMIT_WINDOW` and `RATE_LIMIT_MAX` to `.env.example`
4. Update `app/api/contact/route.ts` to return 429 with retry-after header
5. Risk: middleware.ts already has auth logic, need to ensure rate check runs first

Review it. Cut unnecessary steps. Add things Claude Code missed. This is your steering wheel. Once you approve, implementation follows the plan closely.

The Interview Pattern

For bigger features, don't dump everything into one prompt. Have a back-and-forth during explore and plan.

"What state management does this app use?"
# Claude Code answers after reading the code
"How are forms currently handled? Any shared patterns?"
# Claude Code investigates and responds
"Given what you found, how would you add a multi-step checkout form?"
# Now Claude Code's plan is grounded in actual code, not assumptions

Each answer builds context. By the time you ask for a plan, Claude Code has accumulated real, verified knowledge about your codebase instead of guesses.

Try It

Open a project you are actively working on. Plan Mode. This exact sequence:

claude
# Switch to Plan Mode (Shift+Tab)
 
# Step 1: Explore
"Read the main layout file and list every component it imports. Then check each component and tell me which ones use client-side state."
 
# Step 2: Plan (still in Plan Mode)
"Based on what you found, create a plan to add a global loading indicator that shows during page transitions."
 
# Step 3: Review the plan, edit if needed, then switch to Normal Mode (Shift+Tab)
 
# Step 4: Implement
"Implement the plan above."

Compare that to just typing "add a loading indicator to my app." The explored version knows your layout structure, knows which components are server vs client, and builds on what exists instead of inventing from scratch.

Enforcing the Methodology

Bake it into CLAUDE.md so you don't have to remind Claude Code every session:

## Workflow Rules
- NEVER start writing code without first reading all relevant files
- When uncertain about approach, use Plan Mode before implementing
- For multi-file changes, always produce a written plan and get approval
- After implementation, run tests and verify the build before committing

These persist across sessions. Claude Code reads CLAUDE.md on startup and adjusts.

Course Correction

Claude Code goes off track sometimes. Your options:

1. Esc to stop and redirect.
2. Esc twice to rewind the last change.
3. /clear to nuke the context and start fresh.

Rule of thumb: if you've corrected Claude Code twice on the same task and it's still wrong, stop patching. /clear and restart with better exploration. Two failed corrections almost always means the context window is polluted with conflicting instructions. A fresh start beats fighting a losing battle.

Verification Targets

"Make sure it works" is not a verification target. Get specific:

"After implementing, run the test suite and confirm all tests pass"
"Build the project and verify zero TypeScript errors"
"Check that the new endpoint returns a 429 status when rate limit is exceeded"

These turn "I think this works" into "I proved this works."

Explore, plan, implement, commit. That order, every time. Code-first fails because Claude Code assumes instead of checking, and you end up debugging plausible-looking output that doesn't match your actual setup. Specific exploration prompts and the interview pattern build real context before any code gets written. Put the workflow rules in CLAUDE.md so you don't have to remember them. And if you've corrected Claude Code twice and it's still wrong, stop. /clear. Better exploration. Fresh context wins.