When a tool gets more powerful but somehow feels harder to use, two explanations are possible. Either the tool was built poorly, or it's now asking something different of the user than it used to. The distinction matters because the right response depends entirely on which one is true.
Shortly after Anthropic released Opus 5, a post appeared on Hacker News, the gathering place for developers and practitioners, asking why a model that scores higher on benchmarks feels less pleasant to use. The thread drew 685 points and 631 comments, and what's striking is how cleanly the responses split into two camps. One side argued that the older model was simply easier to work with. The other insisted that this was exactly how a more capable model should behave.
Tracing why two groups using the same tool ended up with opposite experiences leads to a different question.
Why the Old Model Felt Easier
Type "write me a marketing email" into an older model, and it would produce something immediately. You didn't need to specify what the product was, who the audience was, or what tone to use — the model simply filled in the blanks itself.
It's tempting to read this as a capability, but another way to see it is that the model was simply guessing at the user's intent and running with it. When the output happened to look plausible, the guess seemed correct; when it didn't, users chalked it up to "that's about as good as AI gets." Either way, users got used to giving vague instructions and still receiving something usable.
What a Stronger Model Reveals
A stronger model handles that blank-filling differently. When context is missing, it asks a question, lays out several possible interpretations side by side, or checks which direction you want before proceeding. This can feel like an interruption to a workflow that used to be "just give me an answer first."
Seen through the lens of product design, this friction carries a different meaning. The exact point where a user gets stuck using a tool is, in one sense, a flaw — but it's also the clearest signal of what that user actually expects from the tool. The habit of providing minimal information while still expecting the desired result is one that worked with older models but doesn't hold up with stronger ones.
The link between prompt quality and output quality has become more direct than before. Older models had a kind of buffer, quietly filling in whatever information the user hadn't provided; that buffer has now shrunk. Viewed this way, the frustration looks less like a problem with the tool and more like a problem with how it's being used.
When Expectations Rise, Failures Feel Bigger
There's another factor mixed in here. Expectations for a stronger model rise along with its capabilities. When an older model made a mistake, people shrugged it off as "well, that's about what AI can do." When a stronger model makes the same mistake, the reaction is "wait, why did this happen?"
This mirrors a pattern documented in service-quality research: once expectations rise, the same-sized mistake produces lower satisfaction, not higher. Actual error rates can drop while perceived satisfaction fails to follow. Some of the friction people report with Opus 5, in other words, may be a paradoxical side effect of recognizing just how capable it is.
What Benchmarks Don't Measure
Benchmarks measure problems that have a correct answer: coding tasks, math problems, fact-checking. In these domains, gains in performance translate directly into a better felt experience. Mistakes drop, long contexts get handled more consistently, and complex reasoning holds up.
But much of the real-world work people do with AI has no single correct answer: which direction a project should take, whether a sentence sounds natural, whether an argument is persuasive. On tasks like these, stronger models tend to avoid flat assertions, laying out possibilities instead and handing the judgment call back to the user. Where an older model might have quickly said, "I think this is right," a stronger one is more likely to ask, "here's one direction, and here's another — which do you want?"
That's actually the more honest response. But it collides with a habit built around expecting a fast answer.
Decide the Kind of Task Before You Pick the Model
This is probably why the Hacker News thread split the way it did. People were using the same tool for different kinds of tasks, and then generalizing their particular experience into a verdict on the model itself.
A lighter model is efficient when you need a quick draft or want to scatter ideas around. A stronger model is the right fit for work where accuracy determines the outcome — code review, checking the logic of a long document, numerical analysis. Switch to a stronger model without making that distinction, and you'll keep getting responses that don't match what you expected, task after task, until you drift back to the older model and conclude that "this is just about as good as AI gets."
It's reasonable to factor benchmark scores into how you choose a model. But there's a question worth settling first: how much ambiguity can this particular task tolerate? For work where getting a quick sense of direction matters most, a lighter model is the practical choice. For work where a single error changes the outcome, a stronger model's caution actually lowers the real cost. Settle that question first, and both the model choice and the way you prompt it start to narrow down together.
