Model-level reasoning degradation: thinking loops waste compute and degrade output quality

Problem

Claude Code's reasoning quality degrades significantly during extended sessions, particularly when working on complex multi-file codebases. The thinking/reasoning loop runs inside the model before hooks can intervene, resulting in:

1. Wasted compute on circular reasoning — The model spends extensive thinking cycles second-guessing itself, re-reading the same data, and going in circles instead of acting decisively
2. Reactive patching instead of systematic analysis — Despite explicit user instructions to "read ALL code before fixing," the model jumps to fixing the first issue it finds, then discovers more issues later from user screenshots
3. Degraded output quality — Code produced has formatting inconsistencies, missed edge cases, and bugs that should have been caught by reading the surrounding code

Evidence

In a real development session (complex statistical software project, GLM ANOVA display fixes):

1. User explicitly ordered: "read and understand all input setup in every case, summarize the pattern, then read all report format, then read the whole code, understand and plan to fix, then show me before start fixing"
2. Model fixed ANOVA display layout (Fix 1-2) without reading the computation code that feeds it
3. User ran the app and immediately found TWO more bugs (Lack-of-Fit rows showing with DF=0, Regression Equation showing wrong format) — both were in code the model should have read
4. Model then reactively patched both bugs — the exact patching behavior the user warned against
5. The thinking transcript showed extensive circular reasoning: analyzing the same screenshots multiple times, re-deriving the same conclusions, and failing to commit to decisions

Why hooks don't fix this

We tried implementing enforcement hooks:

• Phase gate (blocks code edits until READ -> PLAN -> APPROVE workflow complete)
• Stop reminder (blocks session end until state files updated)
• Test suite guard (blocks wrong test suites)

These hooks work for enforcing external workflows, but they cannot fix the core problem: the reasoning degradation happens inside the model's thinking before any tool call is made. The model decides to patch before the hook can block it. By the time the edit tool is called, the model has already committed to a reactive approach.

Expected behavior

• Read ALL related code systematically before proposing any fix
• Identify ALL issues in one pass, not discover them one-by-one from user screenshots
• Produce code with consistent formatting and correct edge case handling on first attempt
• Decisive reasoning without circular loops

Actual behavior

• Reads only the rendering code, misses the computation code that feeds it
• Fixes one issue, breaks or misses others
• Produces code with wrong decimal precision
• Thinking transcript shows extensive re-analysis of the same data without progress

Impact

• User has to verify every change manually — defeating the purpose of AI assistance
• Trust destroyed after multiple rounds of "fixed!" followed by user finding more bugs
• Development velocity drops because each fix creates a new verification cycle

Related

• Previous issue: #44627 (running irrelevant test suites and reporting them as validation)

Suggestion

This appears to be a model-level issue with how Claude maintains focus and follows multi-step instructions during extended sessions. Hooks and prompts can enforce external gates, but the internal reasoning quality needs to be addressed at the model/training level.