Shift+Tab Is a Trap: Why Your AI Plan Ignores Half Your Codebase

Last time I wrote about why I never read the first plan. Today I’m going further: even a plan that looks good can be significantly better. It depends on how it was created.

What Shift+Tab Does

You press Shift+Tab, Claude Code switches to plan mode. You describe a task, Claude generates a plan. Steps, files, sequence. Looks professional.

And plan mode is genuinely not bad. Claude looks at the code, reads relevant files, tries to understand context. But there’s a difference between looking and systematically analyzing. Plan mode produces a reasonable plan based on what it manages to read. But it doesn’t walk through your codebase methodically — it doesn’t actively search for existing abstractions, doesn’t test conventions, doesn’t map dependencies.

It’s like the difference between a colleague glancing at your code and going through it with a checklist.

An Example That Shows the Difference

Say you want to add a notification system. Shift+Tab generates a plan:

1. Create NotificationService
2. Add notifications table to database
3. Create API endpoint /api/notifications
4. Add NotificationBell frontend component
5. Connect via WebSocket for real-time updates

Looks reasonable. Claude read a few files, understood the basic structure. You approve. Claude starts coding. And then:

• It discovers you have an EventBus that could handle notifications — but the plan didn’t account for it, because Claude missed it during a quick scan.
• It creates a new NotificationService even though you have a BaseService with built-in error handling — because it didn’t systematically search for one.
• It names endpoints slightly differently from the rest of your API — because it didn’t review all your routes, just a few samples.
• It adds a migration in a slightly different format — because it didn’t find your migration pattern.

None of these are catastrophic. But each problem costs an iteration. And iterations cost time and context. Plan mode gives a reasonable plan. But “reasonable” and “the best possible” are very different.

What /feature-dev Does Differently

/feature-dev from the feature-dev plugin is a completely different approach. Before giving you a plan, it goes through 7 phases:

1. Codebase exploration — reads relevant files, understands project structure.
2. Existing code mapping — finds utilities, services, patterns you can reuse.
3. Convention identification — how you name files, structure components, handle errors.
4. Dependency analysis — what depends on what, where changes might break things.
5. Architecture design — only now does it propose a solution, with full context of your code.
6. Implementation — codes according to a plan that respects project reality.
7. Validation — verifies the result fits with existing code.

The same notification system with /feature-dev:

1. Extend existing EventBus with notification channel
2. Add NotificationHandler extends BaseService
   (reuse logging and error handling from BaseService)
3. Add migration in Knex format (matching existing migrations)
4. Add endpoint POST /api/v2/notifications
   (preserve naming convention from routes/v2/)
5. Extend existing HeaderBar with NotificationBell
   (reuse useWebSocket composable)

See the difference? This isn’t a plan from thin air. It’s a plan that comes from your code.

/writing-plans: A Plan That Accounts for What Can Go Wrong

/writing-plans is a skill from superpowers, focused on structured planning. Instead of writing a list of steps and hoping it works out:

• Automatically considers edge cases — what if this operation fails? What if the data is inconsistent?
• Creates checkpoints — after each step, defines how to verify everything is fine.
• Defines acceptance criteria — not vague “done”, but specific: “endpoint returns 200, test covers happy path and error case”.
• Maps risks — where’s the greatest chance something will break.

This is the difference between a plan and a wishlist. Shift+Tab gives you a wishlist. /writing-plans gives you a plan.

”But Shift+Tab Is Fine for Me”

And often it is! For simple to medium tasks, plan mode is excellent. Add a component, fix a bug, add an endpoint — Shift+Tab handles it.

But once a task crosses 3 files or spans multiple layers (API + database + frontend), the difference between “took a look” and “systematically explored” starts showing. You’ll notice it when Claude is halfway through implementation and starts rewriting his own code because he found an existing abstraction the plan didn’t account for.

Every extra iteration costs tokens, time, and context. And context is precious. It fills up with wasted attempts instead of useful work. Then you run /compact, Claude forgets half the context, and quality drops. Investing in a better plan upfront pays off many times over.

Complete Workflow

This is how I work on every non-trivial task today:

# 1. Plan — not from memory, from code
/feature-dev Add notification system for...
# or
/writing-plans I need a plan for migrating from...

# 2. Validation — parallel agents review the plan
/replan

# 3. Implementation — Ralph delivers
/ralph-loop:ralph-loop "Implement according to plan..."
  --max-iterations 20

# 4. Verification — agents compare result with plan
/recheck

Four steps. The plan comes from code (/feature-dev), gets validated (/replan), implemented (/ralph-loop), and verified (/recheck). No dead ends, no extra iterations, no “oh wait, that function doesn’t exist”.

But That’s a Lot of Plugins…

Yes. You need three plugins: feature-dev (for /feature-dev), superpowers (for /writing-plans), and claude-replan (for /replan and /recheck). Installation:

/plugin install feature-dev
/plugin install superpowers
/plugin marketplace add kojott/claude-replan
/plugin install claude-replan

Four commands, once. And then you have a workflow that consistently delivers better results. Not 10% better. Dramatically better. The difference between a plan where Claude took a quick look and a plan where it took the time.

Summary

• Shift+Tab gives a reasonable plan — Claude looks at the code, but doesn’t do systematic analysis.
• /feature-dev gives a thorough plan — 7 phases of codebase exploration before a single line of code.
• /writing-plans adds structure — edge cases, checkpoints, acceptance criteria, risks.
• Combined with /replan and /recheck — the plan is validated before implementation and verified after.
• For simple tasks, Shift+Tab is fine. For anything non-trivial, the upgrade is worth it.

Next time you press Shift+Tab on a bigger task, pause. Try /feature-dev instead. The difference in first-version quality will surprise you.

— Jirka

You might also like

• Why I Never Read the First Plan from Claude Code
• Cognitive Debt — The Hidden Cost of AI Speed
• Skills vs. Agents: When a Recipe Is Enough and When You Need a Chef
• Your Team Generates Code Nobody Reads: The Workslop Problem