Claude Opus 5 completed one of my coding tasks considerably faster than Opus 4.8.
There was just one problem: it confidently reported that the issue was fixed when it wasn’t.
That experience captures the trade-off with Anthropic’s latest Opus model. It is faster and more capable on difficult, multi-step work, but polished output can make its mistakes harder to notice.
After testing it on coding and agent tasks, I changed three parts of my workflow.
1. Start with medium reasoning effort
More reasoning is not automatically better. For routine coding tasks, begin with medium effort and increase it only when the problem genuinely requires deeper investigation.
Higher effort can consume more tokens, expand the scope of the task, and produce a solution far more elaborate than the one you requested.
2. Verify outcomes, not explanations
A convincing explanation is not evidence that the task was completed correctly.
Ask for or independently run the relevant tests. Review the files that changed. Confirm the original bug no longer exists.
The dangerous failure mode is not nonsense. It is an incorrect result presented like finished work.
3. Control the scope
Define what the model may change before it begins:
- Which files can be modified?
- What behaviour must remain unchanged?
- Which tests must pass?
- Can it create subagents or expand the task?
Opus 5 is strongest when the job requires investigation across multiple steps. For a small, clearly defined change, that same initiative can become unnecessary complexity.
The quick version
I condensed my findings, the confidently wrong problem, and the three changes I recommend into this 90-second video:
My broader verdict is simple: Opus 5 is a meaningful upgrade for difficult coding and agent work, but only when verification is part of the workflow.
I published the complete review, including pricing, benchmark comparisons, use cases, and switching advice, on Hashnode:
Have you tested Opus 5? Did it improve your workflow, or merely become more articulate while being wrong?
Top comments (5)
Something people need to keep in mind. 'reasoning' level, is how many iterative loops it does before answering. It's like rambling on explaining your work, if you go on too long, you miss the plot. If you overthink, you overexplain and overexplaining leads to overarching thoughts that lead to inaccurate answers. Best to keep reasoning low, unless you're dealing with something particularly difficult, eg. "review this memory controller and consider ways we can optimize it", is a thinking task, vs "The buttons are overlapping on the UI", isnt. discerning when to think, vs when not to, is common practice for humans, it applies to AI too.
Exactly reasoning should match the task. More thinking isn’t automatically better; good judgment is knowing when depth adds value and when it only adds noise.
Ideally, it should be an automated procedure determining the level of reasoning. Eg. while scoping a task, ask it to determine how complex implementation will be on a scale of 1-100, then adjust reasoning depth as necessary. If you want a 2nd method, ask it how integrated it is with other systems from 1-100, that'll also determine whether 'more thinking' is necessary to prevent breaking adjacent systems. A bit of a manual process for now, but hopefully auto-reasoning-depth becomes a standard soon.
It's the same for all AI. Modern software engineers are becoming too reliant to the point that they just accept all changes without verification and that's today's reality. Only the engineers that still has the discipline to use AI not as a "crutch" will be the good seniors, principal engineers, and engineering managers of tomorrow.
AI should amplify engineering judgment, not replace it. Maybe , engineers who verify, question, and understand AI-generated changes will be the ones ready to lead.