What is loop engineering?

Loop engineering is the practice of designing systems that prompt, verify, retry, and stop AI agents instead of manually prompting them turn by turn.

What is the Operator Loop Stack?

The Operator Loop Stack is Jack Njoroge's framework for deciding whether an AI agent loop is safe to run. It has five layers: harness, loop contract, state layer, checker, and human checkpoint.

What is the Operator Test?

The Operator Test is a safety rule for AI agent loops: if the agent cannot prove it is done, you are not engineering a loop; you are automating drift.

Is Claude Opus 5 Actually Worse? I Read 140 Complaints, Then Read Anthropic's Docs

Short answer: no, but the complaints are real. Six of the most common ones are described in Anthropic's own documentation as expected behaviour changes, each with a fix printed next to it. The biggest single cause is that the effort-level recommendation reversed between Opus 4.8 and Opus 5, so a setting that was officially correct three months ago is now one Anthropic tells you to re-test.

If you configured Claude once, for good reasons, and never touched it again, this is probably about you. It was about me.

What people are actually complaining about

I pulled roughly 140 comments from three Hacker News threads in late July 2026 (49068029, 49056194, 49079191). Six complaints came up repeatedly.

The strange part is who was complaining. Claire Vo, a product leader, posted on day zero that she hates working with it and that in a blind test she ranked it above every other model, including Fable 5. Best output, worst experience, same model.

That gap is the whole story. It's not a quality problem. It's a behaviour problem.

Every complaint, next to Anthropic's own description of it

This is the part that changed my mind. I expected to find a couple of loose matches. All six were documented.

What developers said	What Anthropic published
A trivial feature ran 13 rounds of review and fix, flip-flopping	"It also verifies its own work without being told to… they cause over-verification on Claude Opus 5."
It "halts on a statement like 'ok I'm going to start now'"	"Claude Opus 5 narrates readily during agentic work: it tends to announce what it is about to do."
600 lines of changes to fix a one-word bug	"Claude Opus 5 can also expand the scope of a task, adding steps that weren't requested."
Unprompted confessions: "I didn't tell you the full truth on that"	"The model also narrates corrections to its earlier statements more than prior models do."
Subagent workflows fragment context	"Claude Opus 5 delegates to subagents more readily than prior models."
"It babbles and babbles"	"Claude Opus 5's default user-facing responses run longer than prior Opus models'."

Six for six. Sources: What's new in Claude Opus 5 and Prompting Claude Opus 5.

Why did my setup get worse when I didn't change anything?

Because you didn't have to. Anthropic's migration note says it plainly:

"Claude Opus 5 behaves differently from Claude Opus 4.8 in ways you may notice without changing any code."

Your configuration stayed still. What it was configured against moved.

The effort setting reversed between 4.8 and Opus 5

This is the single highest-value thing in this article.

On Opus 4.7 and 4.8, Anthropic's guidance was: "Start with xhigh for coding and agentic use cases."

On Opus 5, the same guidance reads: "Start with high, the default… use low and medium liberally as your primary control for token cost and response time wherever your evals show quality holds."

And explicitly, for anyone migrating:

"If you carried effort settings over from an earlier model, run a fresh effort sweep on your evals rather than reusing them."

So the people running xhigh today are, in most cases, people who followed the official advice at the time and never had a reason to revisit it. (Effort documentation.)

Your old prompt instructions are now actively harmful

The second cause is instructions that used to help and now compound with behaviour the model performs on its own:

"If your prompt contains explicit verification instructions ('include a final verification step for any non-trivial task,' 'use a subagent to verify'), remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality."

And the line that reframed the whole thing for me:

"The same applies to legacy harness scaffolding that adds separate verification steps."

That is Anthropic describing the scaffolding most of us built over the last year. Every "double-check your work" line you added because an older model needed it is now buying you the 13-round review loop.

What to actually change

Four things, in order of payoff:

Find your effort setting and take it off xhigh. Start at high, work down. This alone accounts for a large share of the complaints.
Delete verification instructions from your setup. Grep for verify, double-check, re-check, confirm before.
Cap subagent delegation. It reaches for them more readily than 4.8 did, and that multiplies cost on small tasks.
Ask for shorter responses explicitly. Lowering effort will not do it — effort controls how much it thinks, not how much it says.

There are eleven of these settings in total. The other seven, each with the exact line from Anthropic's docs, are in The Carry-Over Audit — free, in the community.

Where this argument is weak

I want to be straight about the limits, because most posts on this topic aren't.

I tried to reproduce the worst complaint and failed. I built a small fixture designed to trigger the test-tampering behaviour and ran it twice at default effort. The model behaved correctly both times. I take that as consistent with the thesis — a bare setup at the recommended setting is the configuration Anthropic advises — but a failed reproduction is not proof, and I'm not going to dress it up as one.

At least one developer controlled for this and still saw a difference. A commenter running the same harness and the same CLAUDE.md reported Fable completing a task cleanly where Opus 5 didn't. Settings are not the whole explanation.

The honest version is narrower than "you're holding it wrong": the gap between two people running the same model right now is enormous, and almost nobody is controlling the handful of settings that move it. Check those before concluding anything about the model.

Nothing here was hidden. All of it was published before the complaint threads started. The gap is that nobody reads a migration guide for a model that appears to just work.