What jumped out at me is how aggressively this post tries to retrain people’s habits. Not the model’s habits — ours. Anthropic is basically saying: stop babying Opus 5.5, stop narrating your thoughts, stop restarting long jobs every time you remember one more requirement. If that sounds a little like “use the product the way the product wants to be used,” that’s because it is. And honestly, that’s the interesting part.
A lot of these recommendations feel like they’re less about prompting genius and more about respecting the shape of the model. “Give the whole task in one message,” “name the finish line,” “delete ‘think carefully’,” “read what it needs from you first.” None of that is mystical. It reads like Anthropic has found that Opus 5.5 is happier being treated like a worker with enough autonomy to keep moving, not like a chatty assistant you micromanage every three turns.
That’s probably the right instinct for a model meant to do long repository work. The examples around Claude Code especially point in one direction: the real product is not just answering questions, it’s sustaining intent across a long run, a lot of edits, and a messy context window. That’s a much more demanding claim than “it writes nicer code.” If the model can actually keep a migration moving for hours and surface only the decisions that matter, that’s genuinely useful. If not, then this guide is just a very polished way of asking users to do more of the work themselves.
I’m also mildly skeptical of the confidence around the safety and fallback behavior. “Most flagged messages move to an older model, and your work goes on there” sounds convenient, but in practice it also sounds like a place where behavior can get weird fast. The article says legitimate work can get flagged and they’re tuning it, which is reassuring in the abstract and not very reassuring in the concrete. If I were using this seriously, I’d want to know how often normal coding or research tasks get bumped, and whether those switches happen at the worst possible moment.
The other thing I noticed is how much of the advice depends on users being disciplined about prompts and project instructions. That’s fine for experienced developers, maybe even desirable. But it also means the model is being positioned less as “easy” and more as “capable if you know how to steer it.” There’s nothing wrong with that. In fact, I think it’s more honest than pretending a frontier model needs no coordination. Still, it does make the sales pitch narrower: this is for people who are willing to think in finish lines, stop conditions, and verification steps.
The most convincing bits are the boring ones. “Ask it to mark what it couldn’t confirm.” “Review the diff before a person does.” “Attach the screenshot instead of retyping the numbers.” Those are the habits that usually separate useful agentic workflows from expensive nonsense. If Opus 5.5 is actually better at calling out what it didn’t verify, that’s a meaningful improvement. Hallucinated certainty is still one of the ugliest failure modes in these systems.
What I’d try first is the long-run workflow with a real repo task and very explicit stop rules. Not a toy prompt. Something annoying, like a migration or audit that would normally take a human an afternoon. If Opus 5.5 can keep a checklist in a file, flag only the decisions it truly needs, and summarize cleanly at the end, then the guide is pointing at something real. If it can’t, the prose here will still look thoughtful, but the model won’t have lived up to it.
Reference: Getting the most out of Opus 5.5 in Claude and Claude Code / claude.dev Blog
