Deep Reasoning for Feature Design

Your PM just dropped a one-line feature request in Slack: “We need multi-tenant support.” No PRD. No technical spec. No discussion of what “multi-tenant” means in the context of your application’s existing architecture. You could spend a week asking clarifying questions and writing design documents. Or you could use Claude Code’s planning capabilities to turn that one-liner into a detailed implementation plan in under an hour.

The developers who get the most value from Claude Code do not jump straight to implementation. They use Plan Mode and extended thinking to explore the problem space, identify edge cases, and design solutions before a single file is modified. This lesson covers that planning workflow.

What You’ll Walk Away With

• The Plan Mode workflow for designing features without modifying code
• Prompts that use extended thinking for complex architectural decisions
• The “interview” technique where Claude asks you the questions you forgot to ask yourself
• A repeatable process for going from vague requirement to detailed implementation spec

Plan Mode: Think Before You Code

Plan Mode is the single most underused feature in Claude Code. When activated, Claude can read your entire codebase but cannot modify any files. This constraint is actually a superpower — it forces Claude to focus entirely on analysis and planning.

Entering Plan Mode

You have three options:

# Start a new session in Plan Mode
claude --permission-mode plan

# Toggle during a session: press Shift+Tab twice
# First Shift+Tab = Auto-Accept Mode
# Second Shift+Tab = Plan Mode

# Run a one-off planning query headlessly
claude --permission-mode plan -p "Analyze our auth system and propose improvements"

The Planning Workflow

1. Explore the current state

   Before planning any changes, have Claude understand what exists. This is where Plan Mode shines — Claude reads extensively without any risk.

   I need to add multi-tenant support to this application.
   Before we plan anything, analyze the current architecture:
   
   1. How is user data currently organized?
   2. What database tables would need tenant isolation?
   3. Where are the main data access patterns?
   4. What external services do we integrate with?
   5. Are there any existing concepts of "organization" or "team"?

2. Let Claude interview you

   This is one of the most powerful techniques in feature planning. Instead of trying to think of every requirement yourself, ask Claude to ask you the hard questions.

   Tip

   Copy-paste prompt for the interview technique:

   I want to add multi-tenant support to this application.
   Interview me about the requirements using the AskUserQuestion tool.
   
   Ask about: data isolation requirements, tenant provisioning,
   billing implications, migration strategy for existing users,
   performance requirements, and edge cases I might not have considered.
   
   Don't ask obvious questions. Dig into the hard parts --
   the things that will bite us in production if we get them wrong.
   Keep interviewing until we've covered everything.

   Claude will ask questions like:

   • “Should tenants share a database with row-level isolation, or does each tenant need its own schema?”
   • “How should we handle users who belong to multiple tenants? Can they switch between tenants, or does each tenant have separate credentials?”
   • “What happens to existing data? Do all current users belong to a default tenant, or do we need a migration that assigns them based on some criteria?”

   These are the questions that, if left unanswered, become bugs in production.

3. Generate the implementation plan

   After the interview, ask Claude to synthesize everything into a structured plan.

   Based on our discussion, create a detailed implementation plan.
   For each phase, include:
   - What changes are needed (specific files and modules)
   - Database migrations required
   - Tests that need to be written
   - Risks and mitigation strategies
   - Estimated complexity (small/medium/large)
   
   Order the phases so each one is independently deployable.
   I want to ship incrementally, not in one big bang.

4. Review the plan in your editor

   Press Ctrl+G to open the plan in your default text editor. Edit it directly — add notes, reorder phases, remove scope you want to defer. When you save and close the editor, Claude picks up your changes.

5. Save the plan as a project artifact

   Write this plan to docs/plans/multi-tenant.md with checkboxes
   for each task. I'll use this as a working checklist across sessions.

Extended Thinking for Architecture Decisions

Some planning tasks require deeper reasoning than a standard prompt allows. Extended thinking gives Claude space to work through complex problems step-by-step before responding.

Extended thinking is enabled by default with Claude Opus 4.6, which uses adaptive reasoning — the model dynamically allocates thinking depth based on the effort level you set.

When to use extended thinking

• Architectural decisions with multiple valid approaches and non-obvious tradeoffs
• Migration planning where the order of operations matters and mistakes are expensive
• Performance design where you need to reason about data flow, caching, and scaling
• Security design where missing an edge case means a vulnerability

Adjusting effort level

Use the /model menu to adjust effort level (low, medium, high). High effort means Claude allocates more thinking tokens to reason through your problem before responding.

/model
# Select effort level: high

Then ask your question:

We need to decide between three approaches for tenant isolation:
1. Shared database with tenant_id column on every table
2. Schema-per-tenant in a shared database
3. Database-per-tenant

Our constraints: 500 tenants expected in year one, growing to 5,000.
Average tenant has 10,000 rows in the largest table. Some tenants
are "enterprise" with 10M+ rows. We run on managed PostgreSQL.

Analyze each approach against: query performance, operational complexity,
cost, data isolation guarantees, and migration difficulty from our
current single-tenant schema. Recommend one.

With high effort and extended thinking, Claude will reason through each approach systematically before giving you a recommendation. Toggle verbose mode with Ctrl+O to watch the reasoning process.

Pattern: The Spec Document

For complex features, have Claude produce a formal spec that becomes the source of truth for implementation.

Tip

Copy-paste prompt for spec generation:

Write a technical specification for the multi-tenant feature.
Structure it as:

## Overview
One paragraph summary of what we're building and why.

## Data Model Changes
New tables, modified tables, new columns. Include SQL DDL.

## API Changes
New endpoints, modified endpoints. Include request/response shapes.

## Migration Strategy
Step-by-step plan for migrating existing data. Include rollback plan.

## Security Considerations
Tenant isolation enforcement, access control changes, audit logging.

## Testing Strategy
What needs unit tests, integration tests, and manual QA.

## Open Questions
Anything we still need to decide before implementation.

Save it to docs/specs/multi-tenant-spec.md.

Planning Across Multiple Sessions

Complex features often require multiple planning sessions. Claude Code’s session management makes this natural.

# Name your planning session
# (inside Claude Code, use /rename)
/rename multi-tenant-planning

# Later, resume the session
claude --resume multi-tenant-planning

If the session gets too heavy with context from exploration, start a fresh session and point it at your saved artifacts:

Read docs/specs/multi-tenant-spec.md and docs/plans/multi-tenant.md.
These are the spec and implementation plan from our planning sessions.
I'm ready to start implementation. Which phase should we tackle first?

Using Sub-agents for Research

When planning requires understanding multiple parts of the codebase, delegate research to sub-agents so your main planning context stays focused.

Before we finalize the plan, use sub-agents to research:

1. Check every database query in the codebase that would need
   a tenant_id filter. List them by file and line number.

2. Find all API endpoints that return data which would need
   tenant scoping. Group by router/controller.

3. Identify all background jobs and cron tasks that would need
   tenant awareness.

Report the findings so we can update the implementation plan
with accurate scope.

When This Breaks

Claude’s plan is too high-level to be actionable. Push for specificity: “For each task in the plan, name the exact files that need to change and describe the change in one sentence.” If Claude cannot name specific files, it has not explored the codebase deeply enough — send it back to investigate.

The interview goes in circles. Claude sometimes asks redundant questions. If this happens, say: “You’ve already asked about X. Move on to areas we haven’t covered: [list specific areas].”

Extended thinking produces overthought answers. For simpler planning tasks, high effort is overkill. Drop to medium effort for straightforward feature additions. Reserve high effort for genuinely complex architectural decisions.

The plan does not account for existing code patterns. Explicitly tell Claude: “This plan must follow the existing patterns in the codebase. Don’t introduce new frameworks or patterns. Look at how we implemented [similar feature] and follow that approach.”

Session context fills up during planning. Run /compact Focus on the implementation plan and key decisions to free context while preserving the important parts. Or save the plan to a file and start a fresh session.

What’s Next

You have a detailed plan. Now it is time to turn it into working code.

Implementation Execute your plan with the explore-plan-implement-commit workflow

Codebase Analysis If you need to understand more of the codebase before planning, start here