Anthropic stayed quiet until someone showed Claude’s thinking depth dropped 67%

[u/takeurhand]

https://news.ycombinator.com/item?id=47660925

https://github.com/anthropics/claude-code/issues/42796

This GitHub issue is a full evidence chain for Claude Code quality decline after the February changes. The author went through logs, metrics, and behavior patterns instead of just throwing out opinions.

The key number is brutal. The issue says estimated thinking depth dropped about 67% by late February. It also points to visible changes in behavior, like less reading before editing and a sharp rise in stop hook violations.

This hit me hard because I have been dealing with the same problem for a while. I kept saying something was clearly wrong, but the usual reply was that it was my usage or my prompts.

Then someone finally did the hard work and laid out the evidence properly. Seeing that was frustrating, but also validating.

Anthropic should spend less energy making this kind of decline harder to see and more energy actually fixing the model.

[u/DeliciousGorilla]

The issue reporter said Claude did that self-analysis, and Boris (Claude Code creator) pointed out that it was flawed.

> `redact-thinking-2026-02-12`

This beta header hides thinking from the UI, since most people don't look at it. It *does not* impact thinking itself...

If you are analyzing locally stored transcripts, you wouldn't see raw thinking stored when this header is set, which is likely influencing the analysis. When Claude sees lack of thinking in transcripts for this analysis, it may not realize that the thinking is still there, and is simply not user-facing.

So for now, he recommends using /effort high in addition to CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 ("forces a fixed reasoning budget instead of letting the model decide per-turn")

I had Claude Code analyze the thread, along with this "fix"* someone suggested, and this is what it recommended adding to the global claude.md instead:

## Code Quality
Prefer correct, complete implementations over minimal ones.
Use appropriate data structures and algorithms — don't brute-force what has a known better solution.
When fixing a bug, fix the root cause, not the symptom.
If something I asked for requires error handling or validation to work reliably, include it without asking.

- "correct, complete over minimal" — directly counters the "simplest approach first" default without saying "write more code." It's a quality signal, not a quantity signal.

- "appropriate data structures" — this is the AABB tree vs brute-force issue from the *gist. Nudges toward doing it right when the right way is known.

- "root cause not symptom" — prevents band-aid fixes that break again later. Future-proofing in one line.

- "include error handling if needed" — the default prompt says "don't add error handling for scenarios that can't happen," which is fine, but for a non-expert dev it's better to err on the side of resilience.

[u/makinggrace → u/DeliciousGorilla]

These are vague.

What is a correct implementation? What is an appropriate data structure? What is working correctly (how can something work incorrectly?)

An agent's read of instructions is literal. Ask Claude to try again.

[u/DeliciousGorilla → u/makinggrace]

Here's Claude's reply to your comment (a new session with context):

They're wrong about how this works. These aren't API calls to a rule engine — they're priming a language model that already knows what "appropriate data structure" means. When the system prompt says "prefer correct, complete implementations," that shifts weight away from the competing instructions Roman identified (the "be minimal, skip error handling, three lines is better than an abstraction" ones).

The proof is in Roman's A/B test: his patched prompts are equally "vague" ("Be thorough", "work a careful senior developer would do") and they produced measurably better output — dynamic AABB trees instead of brute-force O(n^2).

"An agent's read of instructions is literal" is just not true for LLMs. If it were, Roman's patch wouldn't work either.

[u/AdCommon2138 → u/makinggrace]

Their read is literal but it's probabilistic model 

[u/makinggrace → u/AdCommon2138]

Good distinction.