Hands-On: Extended Thinking in Practice
This lesson is mostly practice. You've learned what extended thinking is, when to use it, and how to write prompts that work well with it. Now you'll apply those skills across three realistic scenarios — each chosen because they represent the categories of tasks where extended thinking provides the most value.
For each scenario, you'll see the setup and a prompt to study, then complete an exercise applying the approach yourself.
How to Use This Lesson
For each scenario:
- Read the setup and study the example prompt structure
- Notice what makes the prompt work well with extended thinking
- Complete the exercise — write your own prompt for a related task
- Use the playground at the end to experiment freely
Scenario 1: Complex Debugging
Debugging is one of the strongest use cases for extended thinking. The internal reasoning phase is particularly valuable when a bug has multiple plausible causes and the correct approach is systematic elimination.
The setup:
A Next.js application is exhibiting intermittent 502 errors in production. The errors occur roughly 3-5 times per hour during peak traffic, last 10-30 seconds, and then resolve without any intervention. The app uses a PostgreSQL connection pool, Redis for session storage, and an external payments API. Recent changes include a database migration that added two new indexes and an upgrade to the Redis client library.
What a thinking-optimized prompt looks like:
<bug_description>
Symptom: Intermittent 502 errors in production Next.js app, 3-5 times per hour
Duration: Each episode lasts 10-30 seconds, then self-resolves
Traffic correlation: Occurs during peak load only
Recent changes: DB migration (added 2 indexes), Redis client library upgrade
</bug_description>
<system_context>
Stack: Next.js 14, PostgreSQL (connection pool: max 20), Redis (sessions),
external payments API (Stripe)
Infrastructure: Vercel (frontend), Railway (PostgreSQL + Redis)
Error logs show: "upstream connect error or disconnect/reset before headers"
</system_context>
Reason through all plausible causes of intermittent 502 errors in this environment before settling on a diagnosis. Consider connection pool exhaustion, Redis issues, external API timeouts, and infrastructure limits — but don't limit yourself to these.
Provide:
1. Ranked list of candidate causes (most to least likely) with reasoning for each ranking
2. Diagnostic steps to confirm or rule out the top two candidates
3. Recommended fix once the root cause is confirmed
4. Any monitoring or alerting to add to catch this earlier in the future
Notice the prompt doesn't say "first check X, then check Y." It sets up the problem with full context, names the suspected areas without constraining the reasoning, and specifies what a complete answer looks like.
Scenario 2: Architecture Design
System design tasks are ideal for extended thinking. Designing a meaningful system involves holding functional requirements, non-functional requirements, constraints, and tradeoffs in mind simultaneously — exactly the problem space where the internal reasoning phase adds value.
The setup:
A B2B SaaS company needs to add a real-time notification system to their existing product. Users should receive notifications in-app (browser), via email, and optionally via Slack or webhooks. The system needs to handle 10,000 active users with up to 500 concurrent users at peak. Notifications can be triggered by many system events. The team has strong PostgreSQL expertise but no message queue experience.
What a thinking-optimized prompt looks like:
<requirements>
Functional:
- Real-time in-app notifications (browser-based)
- Email delivery with configurable digest schedules
- Slack and webhook integrations (optional, user-configured)
- Notification preference management (user-level on/off per notification type)
- Read/unread tracking and notification history (90-day retention)
Non-functional:
- Scale: 10,000 registered users, 500 concurrent at peak
- Latency: In-app notifications visible within 2 seconds of triggering event
- Reliability: Email delivery failure should not block the triggering transaction
</requirements>
<constraints>
- Team expertise: Strong PostgreSQL, no message queue experience
- Existing stack: PostgreSQL (primary DB), Redis (caching), Next.js frontend
- Timeline: MVP in 6 weeks, full feature set in 14 weeks
- Infrastructure: Currently on AWS, comfortable with managed services
</constraints>
Think carefully about the architecture before committing to a design. Consider the team's PostgreSQL expertise as a genuine advantage — an approach built on familiar tools may outperform a theoretically superior but unfamiliar one given the timeline.
Produce:
1. Recommended architecture with component diagram (text/ASCII)
2. Justification for each major component choice
3. The alternative you most seriously considered, and why you rejected it
4. Data model for the notifications table(s)
5. The single highest-risk implementation decision and how to mitigate it
The key phrase is "think carefully before committing to a design." This explicitly invites exploration before conclusion. The constraints note that PostgreSQL expertise is an advantage — not to constrain the design, but to signal what tradeoffs matter in this context.
Scenario 3: Multi-Constraint Optimization
Some problems don't have a single obvious answer — they have a solution space with many competing requirements that need to be balanced. Extended thinking is well-suited for these because the internal reasoning phase can explore and evaluate multiple options before committing.
The setup:
An engineering team of 8 needs to migrate a legacy monolithic PHP application to a modern stack over 18 months while keeping the current application running, continuing to ship new features, and not exceeding their current infrastructure cost. Team skills are mixed: 3 senior engineers experienced with the current PHP app, 2 mid-level full-stack engineers, 2 junior developers, and 1 DevOps engineer.
What a thinking-optimized prompt looks like:
<migration_context>
Current state: PHP monolith, 8 years old, 150K lines of code
Target state: Modern stack (team is open to recommendations)
Timeline: 18 months
Constraint: Application must remain live with no extended downtime
Constraint: New features must continue shipping throughout migration
Constraint: Infrastructure costs cannot exceed current $4,200/month
</migration_context>
<team>
- 3 senior engineers: Deep PHP/MySQL expertise, limited modern stack experience
- 2 mid-level full-stack: React frontend, some Node.js backend
- 2 junior developers: Mostly frontend, learning backend
- 1 DevOps: Currently manages LAMP stack on AWS EC2
</team>
Think through the realistic options for this migration given both the technical requirements and the team composition. The team constraint is as important as the technical constraint — a theoretically optimal migration strategy that requires skills the team doesn't have will fail.
Produce:
1. Recommended migration strategy (strangler fig, big bang rewrite, module-by-module, etc.) with justification
2. Month-by-month high-level roadmap for the 18-month window
3. Which parts of the monolith to migrate first and why
4. Risk assessment: top 3 ways this migration could fail, with mitigation for each
5. Success metrics: how to know at the 6-month mark if the migration is on track
This prompt is effective because the constraints are complete and realistic. The "think through" instruction invites the model to weigh the team reality against the technical options before recommending an approach.
Free Experimentation Playground
Use this playground for open-ended practice. Try any of the following:
- Option A: Take the debugging scenario from earlier and rewrite the prompt as an overly constrained step-by-step version, then compare the outputs
- Option B: Design a prompt for a complex analysis task you're working on — apply the goal-oriented pattern
- Option C: Experiment with the migration scenario above, modifying the constraints to see how the recommendation changes
Patterns Across All Three Scenarios
Looking back at all three scenarios, the same structural elements appear in every thinking-optimized prompt:
| Element | What to include |
|---|---|
| Problem context | Symptoms, system description, relevant recent changes |
| Constraints | Technical, team, timeline, budget — all of them |
| The "think" invitation | A sentence that explicitly invites reasoning before concluding |
| Output specification | What a complete answer looks like — not the reasoning steps |
| Quality signal | One sentence about what "good" means in this context |
The output specification is the most important element to get right. It tells Claude what to produce without prescribing how to produce it. A well-written output spec for an extended thinking task looks like: "Produce X with Y quality criteria" — not "First do A, then do B, then produce C."
Key Takeaways
- Debugging, architecture design, and multi-constraint optimization are the three highest-value use cases for extended thinking
- In all cases, provide complete context and let Claude determine the reasoning path
- The team and constraint context matters as much as the technical requirements — include both
- Explicitly invite reasoning ("think carefully," "reason through the options") before asking for conclusions
- Your output specification should describe what a complete answer looks like, not the steps to reach it
- Use the free playground to practice applying these patterns to your own real problems
Discussion
Sign in to join the discussion.