Skip to content
BSWEN
Blog

Why Has Claude Code Plan Mode Gotten Worse With Shorter Plans?

Cowrie
Cowrie
Dev @ Bswen

Why Has Claude Code Plan Mode Gotten Worse With Shorter Plans?

I’ve been using Claude Code’s plan mode for months, and recently I noticed something frustrating: the plans were getting worse. Much worse.

They went from detailed architectural discussions with trade-offs and reasoning to… bullet-pointed TODO lists. No context. No explanation of WHY. Just “do this, then do that.”

At first I thought I was imagining it. Then I found I wasn’t alone.

The Problem: Plans Without Context

Here’s what a typical plan looks like now:

Current Claude Code Plan Output
Plan for authentication refactor:
- Add OAuth2 dependencies to package.json
- Create OAuth2Service class in services/
- Update AuthController to handle OAuth2 callbacks
- Modify database schema for OAuth2 tokens
- Update frontend to show OAuth2 login button


[Would you like me to:
1. Implement this plan
2. Modify the plan
3. Get more details
]

That’s not a plan. That’s a TODO list.

A real plan should answer:

  • Why this approach?
  • What alternatives were considered?
  • What trade-offs exist?
  • What could go wrong?

When I asked on Reddit, others reported the same issue:

“Plans are super short and to the point leaving out a lot of context and discussion around the intent”

“It literally now just bullet points all the line changes and doesn’t really extrapolate the whys”

“Makes it way harder to use the plan with a clear context”

This wasn’t a gradual decline. It felt like something changed in the system prompt.

The Root Cause: Efficiency Directives Applied Everywhere

After investigating, I found the culprit: output efficiency directives.

The system prompt now includes instructions like:

  • “Go straight to the point”
  • “Be extra concise”
  • “Avoid lengthy explanations”

These directives make sense for execution mode - when you’re writing code, you want clean, efficient output. But they’re disastrous for plan mode.

Planning inherently requires:

  1. Deliberation - weighing options
  2. Comparison - discussing alternatives
  3. Explanation - justifying decisions
  4. Context - enabling evaluation

When you apply “be concise” to planning, you get bullet points without reasoning.

Before vs. After: What Changed

What Plans Used to Look Like

Old Plan Mode Behavior
# Authentication Refactor Plan


## Architectural Analysis


**Current State:**
- Local authentication only (email/password)
- Session-based auth with JWT tokens
- ~50 endpoints require authentication


**Proposed Approach: Hybrid OAuth2 + Local Auth**


### Why This Approach:
1. Maintains backward compatibility for existing users
2. Allows gradual migration (users can choose OAuth or local)
3. Reduces risk of lock-in to single OAuth provider
4. Preserves our user data ownership model


### Alternatives Considered:


**Option A: OAuth2 Only**
- Pros: Simpler codebase, no password management
- Cons: Locks out users without OAuth providers, data privacy concerns
- Rejected: Limits user choice, privacy concerns


**Option B: OAuth2-First with Local Fallback**
- Pros: Encourages OAuth adoption, still supports local
- Cons: Complex UX flow, dual code paths
- Rejected: Adds unnecessary complexity


**Option C: Hybrid (Recommended)**
- Pros: User choice, backward compatible, privacy-friendly
- Cons: More complex initial implementation
- Selected: Best long-term flexibility


## Risk Analysis


1. **OAuth Provider Outages**
   - Mitigation: Fallback to local auth, status page monitoring


2. **Token Refresh Race Conditions**
   - Mitigation: Implement refresh token queue with mutex
...

This was valuable. I could evaluate whether the plan was correct. I could learn from the reasoning. I could adapt it to my specific context.

What Plans Look Like Now

Current Plan Mode Behavior
Here's the plan:
- Add OAuth2 dependencies to package.json
- Create OAuth2Service class in services/
- Update AuthController to handle OAuth2 callbacks
- Modify database schema for OAuth2 tokens
- Update frontend to show OAuth2 login button
- Add OAuth2 configuration to environment variables
- Write tests for OAuth2 flow


[Forced interaction with multiple choice]

No architectural discussion. No alternatives. No trade-offs. No reasoning.

Just a checklist.

Why This Matters

For Individual Developers

  • Can’t evaluate correctness - Without reasoning, I can’t tell if the plan is sound
  • Miss learning opportunities - I don’t understand WHY certain choices were made
  • Harder to adapt - Without context, I can’t modify the plan for edge cases
  • Reduced trust - I’m implementing blindly without understanding

For Teams

  • Plans are useless for code reviews - Reviewers can’t assess the approach
  • Junior developers don’t learn - No reasoning to study
  • Mistakes slip through - No context to catch errors before implementation
  • Discussions suffer - Nothing to discuss without trade-offs to debate

The Additional Friction Problem

Beyond brevity, plan mode now adds friction:

  1. Forced tool calls to leave plan mode
  2. Multiple choice questions at the end of each response
  3. Unnecessary interactions that interrupt workflow
Forced Interaction Example
[Would you like me to:
1. Implement this plan
2. Modify the plan
3. Get more details
]

This is annoying because:

  • I’m forced to make choices without full context
  • The interaction doesn’t add value
  • It interrupts my workflow
  • I can’t just read the plan and decide on my own

The Fix: Override Brevity Explicitly

I discovered that you can still get detailed plans, but you have to explicitly override the brevity directives.

Solution 1: Request Detailed Planning

Prompt for Detailed Planning
Create a detailed plan that explains:
1. The architectural approach and why you chose it
2. Alternative approaches considered and why they were rejected
3. Trade-offs for each major decision
4. Risks and how they'll be mitigated
5. Step-by-step implementation with context for each step


Do NOT compress into bullet points. I need to understand the approach.

Solution 2: Request Design Trade-offs Explicitly

Prompt for Trade-off Analysis
Before planning, analyze the problem and discuss:
- At least 2 different architectural approaches
- Pros and cons of each approach
- Your recommendation and why


Then create the implementation plan with reasoning for each step.

Solution 3: Override Brevity for Complex Tasks

Prompt Override for Complex Planning
This is a complex task requiring careful planning.
Take your time, explain your reasoning for each decision,
and don't compress the plan into bullet points.
I need to understand the approach, not just see the changes.

Real-World Example: OAuth2 Refactor

Let me show you the difference with an actual prompt.

The Wrong Way (What I Used to Do)

Ineffective Prompt
Plan a refactor of the authentication system to support OAuth2

Result: Bullet points, no reasoning.

The Right Way (What I Do Now)

Effective Prompt for Detailed Planning
I need a comprehensive plan for refactoring authentication to OAuth2.
Do NOT just list steps to execute.


Before planning, analyze:
1. At least 3 different architectural approaches
2. Pros and cons of each approach
3. Specific trade-offs for our codebase context
4. Risks and how to mitigate them


Then create a plan where each step includes:
- What to do
- Why this approach
- What alternatives exist
- What could go wrong


Take your time. Detail is more important than brevity.

Result: Comprehensive plan with reasoning, alternatives, and trade-offs.

What This Means for AI Development

This issue reveals an important insight: planning and execution require different types of output.

Planning vs Execution Requirements
+------------------+-------------------+-------------------+
| Aspect           | Execution Mode    | Plan Mode         |
+------------------+-------------------+-------------------+
| Goal             | Do the task       | Understand task   |
| Output needed    | Code/results      | Reasoning/context |
| Brevity helpful? | Yes               | No                |
| Needs why?       | Sometimes         | Always            |
| Needs alt views? | No                | Yes               |
+------------------+-------------------+-------------------+

Applying the same “go straight to the point” directive to both modes fundamentally misunderstands the purpose of planning.

Common Mistakes to Avoid

Mistake 1: Accepting Plans Without Context

Problem: Implementing without understanding Fix: Always ask for reasoning and alternatives

Mistake 2: Not Explicitly Requesting Reasoning

Problem: Assuming the plan will include context Fix: Override brevity directives in your prompt

Mistake 3: Treating Plans as TODO Lists

Problem: Missing the strategic value Fix: Remember that plans are for evaluation, not just execution

Mistake 4: Accepting Forced Interactions

Problem: Workflow interruption without value Fix: Provide feedback or use alternative prompting strategies

Best Practices for Teams

If your team uses Claude Code, consider:

  1. Create plan mode prompt templates that override brevity
  2. Establish review processes that reject context-free plans
  3. Document this behavior for all Claude Code users
  4. Consider alternative tools for complex planning tasks
  5. Share effective prompts that produce detailed plans
Team Prompt Template Example
# Plan Mode Template (copy-paste this)


When planning, provide:
1. Architectural analysis (current state, proposed state)
2. At least 2 alternative approaches with pros/cons
3. Specific trade-offs and why chosen approach wins
4. Risk analysis with mitigations
5. Step-by-step implementation with reasoning


Do NOT compress into bullet points without context.
Each step should explain WHY, not just WHAT.

The Future: Mode-Specific Prompting

The real solution requires mode-specific prompting from Anthropic:

  1. Plan mode should default to deliberation and reasoning
  2. Execution mode can remain concise and efficient
  3. Users should be able to configure verbosity per mode
  4. Forced interactions should be optional or removed

Until then, we have to work around the current behavior with explicit prompting.

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

Tags: