Skip to content

How Do I Use Plan Mode Effectively With AI Coding Assistants?

Problem

I kept burning through expensive AI tokens on tasks that didn’t need deep reasoning. I’d use Claude Opus for everything—planning, coding, fixing typos—just to make sure the quality stayed high. My monthly bill was out of control.

But when I tried to save money by using cheaper models, the planning quality tanked. Haiku would give me shallow plans that missed edge cases. Sonnet would hallucinate requirements that weren’t in my spec.

I was stuck in a lose-lose situation:

  • Expensive models for everything = high quality but expensive
  • Cheap models for everything = affordable but poor quality

What I needed was a way to use the right model for the right phase of work.

What I Tried First

My first attempt was naive. I thought plan mode just meant “write a todo list before coding.”

I’d open a session with Claude Haiku and say:

My first planning attempt
Help me plan this feature:
I need to add user authentication to my app.
Please create a detailed plan.

The result was useless:

Haiku's shallow plan
1. Create login page
2. Add password field
3. Connect to database
4. Test it

No mention of:

  • Session management
  • Password hashing
  • Token refresh
  • Rate limiting
  • Error handling

I tried the same prompt with Opus and got a completely different result:

Opus's detailed plan
1. Authentication Architecture
- Choose JWT vs session-based auth
- Define token lifetime and refresh strategy
- Plan for multiple device support
2. Security Considerations
- Password hashing (bcrypt, cost factor 12)
- Rate limiting on login attempts
- CSRF protection for session-based auth
- CORS configuration for JWT
3. Database Schema
- Users table with hashed_password, salt
- Sessions table for session-based auth
- Refresh_tokens table for JWT
- Indexes on email and token fields
4. API Endpoints
- POST /auth/register
- POST /auth/login
- POST /auth/logout
- POST /auth/refresh
- GET /auth/me

The difference was stark. But I couldn’t justify running Opus for the entire implementation phase.

The Breakthrough

I found a Reddit thread where developers discussed exactly this problem. The key insight from oxygen_addiction’s comment was simple: “Keep tasks simple and small, clear context over 60-100k.”

This made me realize I was thinking about plan mode wrong. Plan mode isn’t about generating a plan and then implementing it in the same session. It’s about:

  1. Using a high-reasoning model to create a detailed spec
  2. Switching to a cheaper model for implementation
  3. Keeping each phase in its own clean context

The problem with my approach was trying to do everything in one session. By the time I got to implementation, my context was polluted with planning discussion, making the cheaper model confused.

How I Solved It

I restructured my workflow into three distinct phases, each with its own session and model choice.

Phase 1: Planning (High-Reasoning Model)

I start with a spec.md file that captures my requirements:

spec.md
# User Authentication Feature
## Requirements
- Email/password login
- Session-based authentication
- Remember me functionality
- Password reset via email
## Constraints
- Must work with existing PostgreSQL database
- Must integrate with current Express.js app
- Cannot use external auth providers
## Success Criteria
- Users can log in and stay logged in for 7 days
- Password reset completes within 5 minutes
- Login page loads in under 200ms

Then I use Opus to create a detailed plan:

Planning prompt for Opus
Read spec.md and create a detailed implementation plan.
Include:
1. File changes needed
2. Database migrations required
3. API endpoint contracts
4. Error handling strategy
5. Testing approach
Save the plan to plan.md

Opus creates a comprehensive plan.md:

plan.md (generated by Opus)
# Implementation Plan: User Authentication
## Phase 1: Database Setup
### Migration: 001_add_auth_tables.sql
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email VARCHAR(255) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT NOW()
);
CREATE TABLE sessions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES users(id),
token VARCHAR(255) UNIQUE NOT NULL,
expires_at TIMESTAMP NOT NULL,
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_sessions_token ON sessions(token);
## Phase 2: API Implementation
### POST /auth/login
Request:
{
"email": "[email protected]",
"password": "plaintext",
"remember_me": true
}
Response (success):
{
"success": true,
"user": { "id": "...", "email": "..." }
}
Response (error):
{
"success": false,
"error": "Invalid credentials"
}
Error handling:
- 400: Missing email or password
- 401: Invalid credentials (same message for wrong email or wrong password)
- 429: Too many attempts (rate limiting)
- 500: Database error
## Phase 3: Frontend Implementation
...

This planning session costs about $0.50 with Opus, but it saves me from expensive mistakes later.

Phase 2: Implementation (Cheaper Model)

Now I start a fresh session with Haiku. The key is providing clean context:

Implementation prompt for Haiku
I have a plan for adding user authentication. Please implement Phase 1.
Read plan.md for the detailed specification.
Create the migration file: 001_add_auth_tables.sql

Haiku reads the plan and generates the migration:

001_add_auth_tables.sql
-- Migration: Add authentication tables
-- Created: 2026-03-12
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email VARCHAR(255) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT NOW()
);
CREATE TABLE sessions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES users(id) ON DELETE CASCADE,
token VARCHAR(255) UNIQUE NOT NULL,
expires_at TIMESTAMP NOT NULL,
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_sessions_token ON sessions(token);
CREATE INDEX idx_sessions_user_id ON sessions(user_id);
-- Rollback
-- DROP TABLE sessions;
-- DROP TABLE users;

This implementation session costs about $0.05 with Haiku—a 10x savings.

Phase 3: Review (Medium Model)

After implementation, I use Sonnet to review:

Review prompt for Sonnet
Review the authentication implementation:
1. Check migration file against plan.md
2. Verify index strategy
3. Check for security issues
Report any deviations or concerns.

Sonnet catches issues Haiku missed:

Sonnet's review output
Review Results:
ISSUES FOUND:
1. Missing index on sessions.expires_at
- Queries will scan full table when cleaning expired sessions
- Recommendation: Add CREATE INDEX idx_sessions_expires_at
2. No password_hash constraint
- Should add CHECK (length(password_hash) > 60)
- Prevents accidental storage of plaintext passwords
3. Session cleanup not addressed
- Need scheduled job or trigger to delete expired sessions
- Not in original plan but recommended
OVERALL: Implementation follows plan.md.
Security issues are minor but should be addressed.

The AGENTS.md Configuration

For tools like OpenCode CLI or Claude Code, I also create an AGENTS.md file to guide model behavior:

AGENTS.md
# Agent Configuration
## Planning Agent
- Model: claude-opus-4 (highest reasoning)
- Task: Read spec.md, create detailed plan.md
- Output: Comprehensive implementation plan with file changes, API contracts, error handling
- Session: Separate from implementation
## Implementation Agent
- Model: claude-haiku-3.5 (fast, cheap)
- Task: Read plan.md, implement specific phase
- Output: Working code files
- Session: Clean context, single phase at a time
## Review Agent
- Model: claude-sonnet-4 (balanced)
- Task: Compare implementation against plan.md
- Output: Deviation report, security issues, missing features
- Session: After implementation complete
## Context Rules
- Maximum context per session: 60k tokens
- Keep planning and implementation in separate sessions
- Clear context between phases
- Reference spec.md and plan.md, don't copy content

This configuration tells each agent its role and model choice.

The plannotator Tool

For complex projects, I use plannotator to structure my planning workflow:

Using plannotator
# Initialize planning structure
plannotator init
# Add requirements
plannotator add-requirement "User must be able to reset password"
# Generate plan from requirements
plannotator generate --model claude-opus-4
# Export plan for implementation
plannotator export --format markdown --output plan.md

Plannotator helps by:

  • Organizing requirements in a structured format
  • Tracking which requirements are addressed
  • Managing multiple plan versions
  • Integrating with CI/CD for plan validation

Why This Works

The three-phase approach works because it matches model capability to task complexity.

Opus for planning provides:

  • Deep reasoning about edge cases
  • Understanding of system-wide implications
  • Ability to see connections between components
  • Comprehensive error handling

Haiku for implementation provides:

  • Fast, accurate code generation
  • Following detailed specifications
  • Low cost for high volume

Sonnet for review provides:

  • Balanced analysis
  • Catching issues Haiku missed
  • Reasoning about security implications

The key insight is that planning and implementation require different types of intelligence. Planning needs creativity and holistic thinking. Implementation needs precision and following instructions.

Common Mistakes I Made

Mistake 1: Everything in one session

WRONG: Single session approach
[Using Opus for everything]
Plan the authentication feature...
[Opus generates plan]
Now implement it...
[Opus implements]
Review your work...
[Opus reviews]
Total cost: $3.00

This works but wastes money on tasks Haiku can do.

Mistake 2: No spec.md file

WRONG: No specification
[Using Haiku]
Implement user authentication for my app.

Without a spec, Haiku makes assumptions that Opus would catch:

  • Stores passwords in plaintext
  • No session expiration
  • No rate limiting

Mistake 3: Overloading context

WRONG: Too much context
[Session has 150k tokens of discussion]
Now implement the login page.

At 150k tokens, even Opus gets confused. The relevant information is buried in conversation history.

Mistake 4: Skipping the review phase

WRONG: No review
[Haiku implements]
[Me: Looks good, let's ship it]

Haiku follows instructions well but doesn’t catch security issues. I once shipped a login page that returned the user’s password hash in the response.

Cost Comparison

Here’s what I learned about costs over a typical feature:

Cost breakdown per feature
OLD APPROACH (Opus for everything):
- Planning: $0.50
- Implementation: $1.50
- Review: $0.50
- Total: $2.50
NEW APPROACH (Three-phase):
- Planning (Opus): $0.50
- Implementation (Haiku): $0.15
- Review (Sonnet): $0.25
- Total: $0.90
Savings: $1.60 per feature (64%)

Over a month of development, this saves me about $50-100 depending on how many features I ship.

When to Break the Rules

The three-phase approach isn’t always right.

Use Opus for implementation when:

  • The code is security-critical (authentication, encryption)
  • You’re exploring a new architecture
  • The plan has many undefined areas
  • You’re debugging a complex issue

Use Haiku for planning when:

  • The feature is trivial (adding a field to a form)
  • You already have a similar plan to reference
  • The requirements are extremely clear
  • You’ve implemented this exact pattern before

Skip review when:

  • The change is cosmetic (CSS, text updates)
  • You have comprehensive automated tests
  • The feature is low-risk (internal tools)

Summary

In this post, I showed how to use plan mode effectively by separating planning and implementation into distinct phases with appropriate models.

The key point is: high-reasoning models (Opus) for planning, cheaper models (Haiku) for implementation, and medium models (Sonnet) for review. Keep each phase in its own session with clean context, and always start with a clear spec.md file.

This approach reduced my AI costs by 64% while maintaining quality. The planning phase catches issues early, when they’re cheap to fix. The implementation phase is fast and affordable. The review phase catches what the cheaper model missed.

The biggest mistake I made was trying to do everything in one session. Plan mode works best when you treat planning and implementation as separate workflows, each with its own context and model choice.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments