When Claude Gets Stuck
Stall patterns occur when Claude Code enters a cycle of repeated errors or produces implementations that diverge from requirements despite multiple correction attempts. The instinctive response — adding more explanation — is generally counterproductive. This lesson documents diagnostic indicators and effective recovery strategies.
Heuristic: if three successive explanations fail to resolve an issue, the problem lies in the approach, not the explanation. A change in strategy is required.
Diagnostic Indicators
The following patterns signal a stall condition:
- Identical errors recurring after ostensible corrections
- Disproportionate time spent explaining rather than implementing
- Confidently generated but architecturally incorrect output
- Repetitive acknowledgment of errors without behavioral change
Recovery Strategies
Context Reset
Execute /clear to discard accumulated context. Stall patterns
frequently originate from context degradation rather than task complexity.
Re-introduce only the essential specification in the fresh session.
Task Decomposition
Reduce scope to an isolable subproblem. If "build the auth system" fails, "validate the email format" establishes a working foundation from which complexity can be incrementally added.
Example-Driven Specification
Provide a minimal working implementation as a reference. Concrete code communicates intent with higher fidelity than verbal description and anchors the model to a known-correct pattern.
Lexical Reframing
Alternative terminology activates different regions of the model's learned patterns. "State machine" versus "handle transitions" may produce fundamentally different implementation approaches.
Model Escalation
If a task stalls on Sonnet, switching to Opus provides access to deeper reasoning capabilities. Conversely, overly complex reasoning on a simple task may benefit from Haiku's more direct generation patterns.
Early Detection
The critical meta-skill is recognizing stall patterns before significant time is invested. The three-explanation threshold serves as a practical decision boundary: if three attempts at clarification fail to produce correct output, the current approach should be abandoned in favor of one of the recovery strategies above.
Additional explanation within a degraded context is unlikely to resolve the issue. Effective recovery requires a structural change: different framing, reduced scope, fresh context, or a reference implementation that bypasses the communication failure.
Key Takeaways
- Three failed explanations indicate a strategy problem, not a communication problem
/clearresolves context-degradation-induced stalls- Task decomposition isolates the failure to a tractable subproblem
- Concrete examples outperform verbal descriptions for specification
- Model escalation (Sonnet to Opus) provides access to deeper reasoning