This has me very rattled. Just back from a very busy week in London, so my time with Claude has been light. Now I’m back, and very concerned that we aren’t necessarily always getting better and better LLM capabilities.
The assumption has been so steady that nobody bothers to state it. Each model is better than the last, so whatever you build on today’s model will run at least as well on tomorrow’s. Most roadmaps quietly depend on it. Samuel Johnson had the human version in 1750: “The natural flights of the human mind are not from pleasure to pleasure, but from hope to hope.” We’ve been flying from model to model on the same principle.
What if we go through cycles where all of a sudden capability we’d come to count on deserts us for an unknown period of time? Two weeks before an important launch, and your entire dev team is going backwards.
That’s the fear, and this month it has stopped being hypothetical for some people. Someone shared with me significant new bugs surfacing in code that was already well tested — but inexplicably rewritten by the new Claude. Not only unable to continue doing what it had been doing, but detrimentally impacting systems that had been working. One bad Claude session.
The complaints are public, and they predate the new model. On April 6 The Register reported that the director of AMD’s AI group had filed a public issue saying Claude Code had become “dumber, lazier,” backed by an analysis of “6,852 Claude Code sessions incorporating 234,760 tool calls and 17,871 thinking blocks” and concluding that “Claude cannot be trusted to perform complex engineering tasks.” A week later VentureBeat described “a growing number of developers and AI power users” accusing Anthropic of degrading Opus 4.6 and Claude Code, “intentionally or as an outcome of compute limits.” Anthropic’s Boris Cherny pushed back, saying the change users pointed at “does not impact thinking itself.”
Then on April 16 Anthropic shipped Opus 4.7, calling it “a notable improvement on Opus 4.6 in advanced software engineering, with particular gains on the most difficult tasks,” a model that “handles complex, long-running tasks with rigor and consistency.” That may all be true on the benchmarks. It isn’t what the person with the rewritten code experienced.
Keen to test K2.6. Moonshot released Kimi K2.6 this week as the latest in its open-source series, and says it can “handle continuous coding for up to 13 hours.” Very much missing my reliable Opus 4.6, though. It’s hard to go backwards.
