An AMD Director Documented Claude Code's Quality Collapse. Here's What the Data Shows.

On April 2, 2026, Stella Laurenzo filed a GitHub issue on Anthropic’s Claude Code repository. The title: “Claude Code is unusable for complex engineering tasks with the Feb updates.”

Within days it had 2,200+ reactions, 293 comments, coverage in The Register and PC Gamer, and a thread on Hacker News that pulled in Anthropic’s head of Claude Code. The issue is now closed, but the conversation it started is far from resolved.

Laurenzo is a senior director at AMD, leading LLVM engineers working on open-source AI compilers including IREE. She and collaborator Ben Vanik (also an IREE maintainer) had been running 50+ concurrent Claude Code agent sessions doing systems programming in C, MLIR, and GPU driver code. In January and early February, this workflow was producing results: 191,000 lines merged across two pull requests in a single weekend.

Then it stopped working.

What the data actually shows

The report wasn’t an opinion post. Laurenzo had Claude Opus 4.6 analyze its own session logs from January through early April: 17,871 thinking blocks, 234,760 tool calls, 6,852 session files, and 18,000+ user prompts.

The core finding was a measurable shift in how the model approached code changes.

Read-to-edit ratio collapsed

In the “good period” (January 30 through February 12), the model read 6.6 files for every file it edited. It would read the target file, check related files, grep for usages across the codebase, look at tests, then make a precise change.

By mid-March, that ratio was 2.0. The model was editing files it had barely looked at.

Period	Reads per edit	Research actions per mutation
Jan 30 to Feb 12	6.6	8.7
Feb 13 to Mar 7	2.8	4.1
Mar 8 to Mar 23	2.0	2.8

One in three edits during the degraded period was to a file the model hadn’t read in its recent tool history.

A bash script caught 173 behavioral violations

Vanik built a stop-phrase-guard.sh hook that catches specific phrases indicating the model is dodging work, stopping prematurely, or asking unnecessary permission. It blocks the model from quitting and forces continuation.

The hook matches phrases across five categories: ownership dodging (“not caused by my changes,” “pre-existing issue”), premature stopping (“good stopping point”), permission-seeking (“should I continue?”), known-limitation labeling (“future work”), and session-length excuses (“continue in a new session”).

Before March 8, the hook fired zero times. After March 8, it fired 173 times in 17 days. Peak day was March 18 with 43 violations, roughly one every 20 minutes across active sessions.

Full-file rewrites doubled

The model increasingly chose to rewrite entire files rather than make surgical edits. Full-file writes went from 4.9% of all mutations during the good period to 11.1% in late March. Faster to generate, but it throws away precision and context.

The vocabulary of frustration

Word frequency analysis across 11,000+ user prompts showed the shift from the human side:

“great” dropped 47%
“stop” increased 87%
“simplest” increased 642% (the user naming what the model was doing)
“please” dropped 49%
“thanks” dropped 55%
“commit” dropped 58% (less code worth committing)
Positive-to-negative word ratio collapsed from 4.4:1 to 3.0:1

The model itself admitted the quality problems when corrected. In the report, Laurenzo quotes it saying things like “You’re right. That was lazy and wrong” and “I was being sloppy.”

What caused it

Laurenzo’s analysis pointed to two correlations.

First, estimated thinking depth dropped roughly 67% by late February, before thinking content was redacted from session logs. She used the signature field on thinking blocks as a proxy for thinking length (0.971 Pearson correlation across 7,146 paired samples where both were available).

Second, thinking content redaction (redact-thinking-2026-02-12) rolled out from March 5 through March 12, going from 1.5% to 100% of thinking blocks being hidden. The quality regression was independently reported on March 8, the day redacted blocks crossed 50%.

There was also a time-of-day pattern. After redaction, thinking depth became more variable by hour. 5pm and 7pm Pacific were the worst hours, coinciding with peak US internet usage. Before redaction, thinking depth was relatively flat across the day. Laurenzo interpreted this as evidence of load-sensitive allocation rather than a fixed budget.

What Boris Cherny said

Boris Cherny, Anthropic’s head of Claude Code, replied on April 6. He started by acknowledging the depth of the work.

Then he addressed the two variables.

On thinking redaction: Cherny said this was a UI-only change. “It does not impact thinking itself, nor does it impact thinking budgets or the way extended reasoning works under the hood.” The header avoids needing thinking summaries, which reduces latency. He noted that analyzing locally stored transcripts would show absent thinking, which could mislead the analysis, since the thinking was still happening server-side.

On thinking depth declining: Cherny pointed to two specific product changes:

Opus 4.6 launch with adaptive thinking (February 9). The model now decides how long to think for, rather than using a fixed budget. Cherny said this “tends to work better than fixed thinking budgets across the board.” Users can opt out with CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1.
Medium effort default (March 3). Anthropic changed the default effort level from high to 85 (medium). Cherny said they found effort=85 was “a sweet spot on the intelligence-latency/cost curve for most users.” Users who want more thinking can set /effort high or /effort max, or use the ULTRATHINK keyword for a single turn.

Cherny also said Anthropic would test defaulting Teams and Enterprise users to high effort.

In a follow-up, he asked Laurenzo to try effort=max and share transcripts via /bug so the team could pinpoint specific failures.

On Hacker News, Cherny acknowledged a more specific problem: adaptive thinking was “under-allocating reasoning on certain turns,” with fabricated responses showing “zero reasoning emitted” while correct turns had deep reasoning. He described this as a bug being investigated.

When asked directly whether there were internal changes he was aware of that could have caused the regression, Cherny replied: “Confirmed” that there were not.

Where the two accounts don’t line up

Cherny’s response explains some of what happened but leaves gaps.

The community pushed back on several points. Users who had already been running on effort=high for weeks reported the same degradation. Laurenzo herself said that “in our prior testing, we have not found that any combination of effort flags changed the stop-hook/easiest-path bias.”

The adaptive thinking bug that Cherny acknowledged on Hacker News (zero reasoning on certain turns causing fabrication) is a different, more concrete problem than a default effort setting. Several commenters noted that this acknowledgment on HN came after the GitHub issue had already been closed, creating the appearance that the issue was dismissed before the investigation was complete.

Curtis Cook, one of the more detailed community responders, suggested that “adaptive thinking appears to have a bug where it decides that an issue is probably small and doesn’t want to spend any time thinking about it.”

The cost data in Laurenzo’s report is also striking. With roughly the same number of user prompts in February and March (5,608 vs 5,701), API requests jumped 80x and estimated compute cost went from $345 to over $42,000 on Bedrock pricing. Some of that was intentional scale-up to more concurrent sessions. But even accounting for that, Laurenzo estimated degradation-induced thrashing multiplied request volume by 8-16x beyond what scaling alone would explain.

What you can do right now

Based on Cherny’s response and community testing, these are the settings that may help:

In your ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1",
    "MAX_THINKING_TOKENS": "63999"
  }
}

Set effort to high or max:

/effort high or /effort max in a session (sticky across sessions)
Or "CLAUDE_CODE_EFFORT_LEVEL": "max" in your settings

Use ULTRATHINK for individual complex prompts where you want maximum reasoning.

Keep sessions short. Multiple users reported that quality degrades significantly past 200-400K tokens in the context window. Starting fresh sessions helps.

Consider hooks. Vanik’s stop-phrase-guard hook is publicly available. It catches ownership-dodging, premature stopping, and permission-seeking. You can adapt it for your own CLAUDE.md rules.

The bigger question

Laurenzo’s report surfaced a tension that goes beyond one bug or one default setting.

Power users running complex engineering workflows want maximum thinking depth, even if it costs more and takes longer. The product defaults are tuned for the median user who benefits from faster, cheaper responses. When Anthropic shifted defaults toward efficiency, it hurt the users who were getting the most value from deep reasoning.

Laurenzo put it simply in a follow-up comment: “The experience we had in December/January is the bar and the evidence points to that being a proper expectation to hold and that the raw model is still capable of it.”

The issue now has 1,394 upvotes and counting. Anthropic closed it. Laurenzo is waiting for a resolution before trying again. She’s not writing off Claude Code. “Claude was good to us,” she wrote, “and I’d like to see it reach that level again.”

Whether it does will depend on whether Anthropic treats power-user workflows as a priority rather than an edge case. The data in this report makes a strong argument that those workflows are where the real value, and the real risk, lives.

Sources:

GitHub Issue #42796 by stellaraccident (Stella Laurenzo)
Boris Cherny’s response
Ben Vanik’s stop-phrase-guard hook
The Register coverage
Hacker News discussion