Opus 5 is not as bad as the internet says

Opus 5 is not as bad as the internet says. After more than five weeks of daily coding, I still see the unreadable prose, scope creep, wrong assumptions, and regressions that users describe. But when I give it a researched plan, a bounded task, and checks outside its own final message, it is a strong software developer.

Why my view changed: I stopped making Opus plan and build at once

My view improved because I stopped asking Opus to discover the architecture and implement a large feature in the same context. My launch-week assessment called it a strong implementer that was difficult to supervise. Five weeks of repeated use have made that division clearer and increased my trust in the implementation role.

Reading hundreds of negative reports affected my judgment more than I expected. The reports taught me what to watch for, but they also made each awkward sentence or unnecessary edit feel like confirmation of a settled verdict. Once I separated poorly scoped tasks from planned ones, the difference became clearer. Opus struggled most when I asked one conversation to understand a large feature, decide the architecture, preserve every constraint, implement the whole change, and explain it clearly. That is several jobs hidden inside one prompt.

When I gave Opus the implementation part after the architecture and boundaries were settled, it produced strong work. It traced relevant code across the repository, handled difficult changes, and noticed effects that a less attentive model might miss. In a bounded task, that attention helped rather than hurt because Opus found the files, tests, and edge cases connected to the requested behavior.

The change in my view does not erase Opus 5’s failures. It tells me which role makes those failures easier to contain.

Which Opus 5 problems are real, and what helps?

All five groups of complaints are credible, but I do not find them equally serious. The prose problem remains obvious in ordinary use. The other four become much less damaging when Opus receives a researched plan, a narrow implementation boundary, and a real verification step.

Complaint	What reduces it	What remains
Hard-to-read prose	Response limits and plain-language rules	Opus is still less clear than Fable in my use
Scope expansion	Explicit non-goals and narrow file scope	Instructions can still be ignored
False premises	Research before editing and explicit questions	A reviewer must verify the premise
Regressions or false completion	Acceptance criteria, tests and diff review	The selected checks may still be incomplete
Losing the plan	Saved plan, smaller tasks and cleaner context	Every slice still needs review

Each change can reduce its matching problem, but none of them lets me skip independent review.

1. Difficult prose: limits help, but Fable stays clearer

This is the complaint I recognize most quickly. Opus can assemble correct words into a sentence that takes more than one reading to understand, especially in explanations, recaps, and longer Markdown files. Reddit users described the same combination of long sentences, weak structure, and text that technically makes sense but is exhausting to decode. [5] [6]

What helps: Anthropic’s Opus 5 prompting guide says user-facing answers and written reports run longer by default, and it recommends explicit limits for both. [1] Shorter output and a direct plain-language instruction help, but neither consistently gives Opus the conversational clarity I get from Fable 5. That difference matters in a planning conversation. It matters much less when the output I care about is a tested code change.

2. Scope expansion: explicit non-goals keep the task bounded

Opus is unusually alert to nearby problems, possible abstractions, missing validation, and ways a small change might be made more complete. That can be useful during an audit. During a bounded fix, it can turn one request into a refactor or create a workflow around a check that should have taken one command. Anthropic explicitly warns that Opus 5 may expand a task’s scope, over-verify its work, and delegate too readily. [1]

What helps: I state the non-goals as clearly as the goal. Unrelated findings are reported, not fixed, and existing architecture stays in place unless the acceptance criteria require a change. One Reddit author reported a similar improvement after replacing old instructions that demanded immediate fixes with a rule to surface unrelated problems and let the user decide the scope. [7] The report shows that configuration can change the behavior. It does not make every failure the user’s fault.

3. False premises: research exposes assumptions earlier

The clearest Reddit report in the collection described Opus inventing a Linear issue, then referring to it throughout code comments, tests, and commit messages. [8] I have not seen that exact failure, but I recognize the underlying risk: once Opus commits to an interpretation, it can do a lot of technically competent work before stopping to question the premise.

What helps: A separate research phase makes assumptions visible before code depends on them. The model still needs a clear instruction to ask when a missing fact changes the design, and a reviewer still needs to check that the implementation answers the original request rather than a nearby one.

4. Regressions: verify the work outside Opus

Several reports describe a fix that creates a regression, followed by another fix that reopens the original bug. One Reddit thread reduced the pattern to fixing bug A, breaking it while fixing bug B, and then solving A again. [9] Those accounts are anecdotes without repositories I can inspect, but they describe a familiar agent failure: each local fix looks useful while the full set of acceptance criteria is moving further out of reach.

What helps: I do not accept the model’s statement that the task is complete. Completion comes from the agreed checks: the relevant tests, the build, a focused diff review, and any manual behavior the feature requires. Planning helps Opus choose the work. Verification determines whether the work is done.

5. Losing the plan: separate research from implementation

A large feature mixes research, architecture, implementation, debugging, and review in one growing context. Opus may spend the useful part of that context while exploring, then implement from a compressed or partial memory of the decision. One mixed Reddit report is revealing: the author found Opus frustrating in a large established repository, but said it built a new Chrome extension in one session, made 17 commits, and passed a Codex review. [10] The report does not isolate the cause, but it shows the same user getting much better results on a new project with less inherited context.

What helps: Anthropic’s Claude Code guidance says performance can fall as the context window fills, which can lead to missed instructions and more mistakes. It recommends separating research and planning from implementation for uncertain or multi-file changes. [2] That advice applies to every coding model I use. Opus simply makes the cost of ignoring it easier to see.

What do 1,008 negative Opus 5 excerpts actually prove?

The collection shows that five kinds of complaint appeared repeatedly, so it is useful for deciding what to guard against. It is a map of failure modes, not a satisfaction survey or a model ranking.

I collected 1,008 excerpts dated from 23 July to 29 August 2026. They came from 229 posts and 779 comments across 294 distinct Reddit threads. A comment and its parent post are not independent tests, and several busy threads contributed many entries. One timestamp falls a day before Anthropic’s public announcement on 24 July, so I treat the dates as Reddit metadata rather than evidence of early access. [14]

negative excerpts

1,008

distinct threads

294

posts

229

comments

779

A fair popularity comparison would need matching samples for Fable, Sol, earlier Opus releases, and other models, adjusted for user count and subreddit activity. I do not have those samples. What I do have is a detailed record of the problems people repeatedly described after a bad Opus 5 session.

I grouped the excerpts by the failure being described rather than counting every free-form tag as a separate problem. That produced the five groups above. Instruction failures and token use usually appeared as part of those problems, not as separate outcomes. The grouping gave me the practical checklist of safeguards I wanted from the collection.

What can better Opus 5 instructions actually fix?

Better instructions can reduce verbosity, unnecessary verification, delegation, and scope expansion. They cannot guarantee plan adherence, truthful completion, good prose, or correct reasoning. The useful change is not a clever prompt. It is a clearer task contract backed by process and verification.

Four details make the largest difference in my work. I name the requested outcome, state what must not change, point to the existing architecture that should be followed, and define the evidence required for completion. For a broad feature, those details come from research and an architecture plan, not from a longer version of my first idea.

Persistent instructions help with rules that apply to every task. Claude Code loads CLAUDE.md as project context, so it is a reasonable place to say that unrelated problems must only be reported, that established patterns should be reused, and that completion requires actual test or build output. Anthropic warns that this file is context rather than enforced configuration, and that short, specific instructions work better than a long collection of overlapping rules. [3]

That limitation matters because careful users still report failures. One verified Reddit thread describes a concise CLAUDE.md being ignored. [12] Better instructions change the odds; they do not transfer responsibility for a model error to the user.

This is also why I would not tell a frustrated user to learn prompting and leave it there. The strongest positive reports changed the workflow around Opus. One Reddit user moved requirements and review to Fable, then handed Opus a full specification; the unwanted behavior mostly stopped. [11] That separation of roles is also how I now handle large changes.

How I use Opus 5 for large features

I keep one main conversation responsible for the outcome and the architecture. That conversation researches the repository, asks targeted agents for missing information, decides the design, and writes a plan with affected systems, non-goals, risks, and acceptance criteria. Only then does implementation move to Opus agents in bounded pieces.

The agents do not receive a vague instruction such as “build the feature.” Each one gets the relevant plan section, the files or systems in scope, the behavior to preserve, the checks to run, and a stopping point. Anthropic’s subagent documentation says a subagent works in its own context and returns a summary to the main conversation. That protects the main context, but it also means the delegation message must carry the facts the worker cannot infer. [4]

I prefer Fable 5 for the main conversation because it communicates more clearly and keeps a better architectural overview in my projects. Opus then handles much of the implementation. That is my preference, not a general ranking, and it is possible partly because I pay for Max 20x. Anthropic lists that plan at $200 per month with 20 times the Pro capacity per session. [13] A workflow that consumes one premium model for planning and several Opus agents for execution is not equally available to every subscriber.

The same separation still helps if Opus is the only model available. In that case, I separate the stages by conversation instead of by model.

How should you use Opus 5 by itself?

Use Opus for the whole process, but do not ask it to perform the whole process in one uninterrupted run. Separate planning from editing, persist the agreed plan, implement one reviewable slice at a time, and start with cleaner context when the job changes.

For an uncertain feature, begin in plan mode and ask Opus to inspect the repository without changing it. The plan should name affected files and systems, explain the chosen approach, record unresolved questions, and define how each slice will be checked. Review that artifact before implementation. Anthropic recommends separating research and planning from implementation when the approach is unclear or the change spans several files, while noting that a small and obvious fix may not need the extra planning step. [2]

Next, give the implementation conversation only the first coherent slice. A useful slice can be reviewed and tested without waiting for the entire feature. If a feature would take a developer weeks, split it into independently testable parts. Divide it by dependency and verification boundary, not by an arbitrary number of prompts.

Keep the plan outside the conversation so it survives a context reset. Use /clear between unrelated tasks, and send repository research to subagents only when it is large enough to justify an isolated context. Opus 5 already tends to delegate, so more agents are not automatically better. [1] The goal is to keep the main context focused, not to spawn as many agents as possible.

Finally, review the evidence rather than the confidence of the final message. Read the diff, run the checks that matter, and compare the result with the saved acceptance criteria. If one slice is wrong, fix and verify that slice before adding the next. This keeps a local mistake from turning into a feature-wide rewrite.

What Opus 5 still gets wrong

Some Opus 5 problems remain even with a good workflow. Its prose is still harder to read than Fable’s in my use, it still needs more supervision than I want, and explicit boundaries do not guarantee that it will stay inside them.

Opus 5 is now part of my regular implementation workflow. It is not my preferred model for the main architecture conversation, and I still would not choose it to write an article without a heavy editing pass. A confident implementation can still rest on a bad premise, so I keep the plan and final review outside the worker context.

The Reddit complaints helped me identify the failure modes, but they did not settle whether Opus could work for me. My launch-week mistake was treating supervision quality and implementation quality as the same thing. I still do not trust Opus to supervise a large change, but when Fable holds the plan and review, I often trust Opus to write the code.