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.

Opus 5: What Changed & What You Must Do

Anthropic deleted over 80% of Claude Code's system prompt and their coding evaluations didn't move. Then they published the list of what changed. Here's what that actually means for anything you've built.

There is a particular kind of engineering work that only makes sense in hindsight.

For about two years, everyone building on top of language models learned the same lesson the same way. The model would do something careless, and you would write a rule. It would forget to run the tests, so you added always run the tests. It would wander off and refactor half the file, so you added do not modify code outside the requested scope. It would give you a confident wrong answer, so you added double-check your work before responding.

Each rule was a scar. Collectively they became a system. We gave the system a name - context engineering - and we got good at it.

Then Anthropic removed over 80% of Claude Code's system prompt for the Claude 5 generation and reported no measurable loss on their coding evaluations.

Not an improvement. No loss. Which is worse, in a way, because it means most of what was there had stopped doing anything at all.

What they actually said

The claim is easy to sensationalise, so here it is precisely. In their post on context engineering for Claude 5-generation models, Anthropic writes that they removed over 80% of Claude Code's system prompt with no measurable loss on their coding evaluations. They describe the underlying problem as overconstraining — and they name three sources of it: the system prompt, CLAUDE.md files, and skills.

They also give an example of what overconstraining looks like in practice, and it's mundane enough to be uncomfortable: one instruction saying to leave documentation as appropriate, another saying not to add comments. Both written by reasonable people. Both arriving in the same request. The model has to resolve a contradiction that nobody knew they'd created.

They then shipped a tool — /doctor in Claude Code — whose job is to help you right-size your own skills and CLAUDE.md.

That's the part I keep returning to. It's one thing to publish guidance. It's another to build tooling whose purpose is to help users delete what they wrote.

The six reversals

The same post lays out six practices that inverted. I'll give them as they're framed, then say what I think each one actually costs you.

Rules → judgement. The instinct was to encode every decision you didn't want the model making badly. The new position is that most of those rules are now describing behaviour it already has, and the encoding is what gets in the way.

Examples → interfaces. Three good outputs and three bad ones at the top of your prompt used to be the cheapest available lever. The guidance now is that examples constrain the model to the exploration space you happened to show it. The replacement isn't a better example — it's a better tool description.

Everything upfront → progressive disclosure. A million-token context window read as permission to load the world. It isn't. And you no longer need to: tools can now change mid-conversation without invalidating the prompt cache, which is the mechanism that made front-loading rational in the first place.

Repeat yourself → simple tool descriptions. Saying it three times — system prompt, tool description, then again in capitals — was a reliability tactic. It's now noise competing with itself.

CLAUDE.md as memory → automatic memory. The hand-maintained memory file is being superseded by memory the model manages itself.

Simple specs → rich references. A short brief protected a weaker model from its own tendency to over-reach. A stronger one doesn't need protecting; it needs material. The actual schema. The actual file. The actual decision you already made and wrote down somewhere.

Read as a list, these look like six unrelated tips. They aren't. Every one of them is the same move: stop compensating for a weakness that no longer exists.

The complaint and the cause are the same thing

Here's where it gets interesting, and where I think most of the coverage has stopped short.

Since Opus 5 launched, two complaints keep recurring in developer threads. The model argues with instructions. And it stops before the work is finished.

Both have documented causes, and neither is the model being difficult.

The stopping is arithmetic. On Opus 4.8, a request with no thinking field ran without thinking. On Opus 5, the identical request runs with adaptive thinking on. And max_tokens is a hard cap on total output — thinking plus the answer. So a budget you sized last month now gets consumed before the response finishes. Anthropic's migration guide flags it and says to raise max_tokens, starting around 64k at higher effort levels.

The number one complaint about the model is a configuration value nobody updated.

The arguing is subtler. Anthropic documents that the model is trained to resist instructions that appear to work against the user — and that this protection applies to the system role too. Override-style phrasing is described as less effective than plainly stating what changed. Which means every harness built on forceful CRITICAL: and MUST and IGNORE THE ABOVE language is getting exactly what it asked for, from a model that has been taught to be suspicious of precisely that shape of instruction.

The scaffolding isn't failing despite being emphatic. It's failing because it is.

Three things that surprised me

Telling it not to think makes the output worse. A system-prompt rule instructing the model not to think increases internal XML tag leakage into visible output. Anthropic's fix is simply to remove the rule. And with thinking disabled, the model can occasionally write a tool call as ordinary text instead of emitting a real tool-use block — the turn completes, it looks like it worked, the call never ran, and in an agent loop that leaked text stays in the conversation history and affects every subsequent turn. A failure that reads exactly like success is the worst kind there is.

Being polite in a code review prompt now costs you findings. "Only report high-severity issues" and "be conservative" are followed more literally now. CodeRabbit's benchmark against roughly a hundred error patterns from real open-source pull requests found Opus 5 at x-high effort caught 55.2% of known issues against a 61.1% baseline, while producing about four times the nitpicks. Their conclusion is the quotable one: more reasoning did not consistently produce a better review. Anthropic's own fix is to ask for everything with confidence and severity attached, then filter in a separate pass.

Their own system card contains a chart that contradicts their public advice. On FrontierCode — 150 agentic coding tasks built from real open-source pull requests — Opus 5 peaks at medium effort (53.4%), then declines through high (48.0%) and bottoms out at x-high (43.6%), barely above its low-effort score of 41.9%. Opus 5 is the only model on that chart with a mid-effort peak; the comparison models all improve with more effort. Meanwhile the public prompting guidance says to start at x-high for coding and agentic work.

I want to be careful with that last one, because it's the easiest to overstate. It is one benchmark. In the same chapter, DeepSWE improves monotonically with effort, and FrontierBench peaks at x-high. Anthropic offers no explanation for the FrontierCode curve, and I'm not going to invent one. But if you carried your effort settings over from a previous model and never re-tested them, that chart is a reason to run a sweep on your own evaluations rather than trusting a default.

The contradiction nobody has resolved

Anthropic's own materials say Opus 5 performs well out of the box on existing Opus 4.8 prompts.

A week of independent testing by Every's team found close to the opposite: the model argued with instructions, stopped before work was finished, and clashed with their existing skills and plugins. Their fix was to delete their skills and start over — after which, by their account, it got dramatically better.

Both of these can be true, and I think the reconciliation is the actual story:

A simple prompt carried over from 4.8 is fine. An elaborate compensatory harness carried over from 4.8 is the problem.

Anthropic never draws that line. Their guidance says to remove verification instructions and legacy harness scaffolding, but it doesn't say the more sophisticated your setup, the more likely it is to be hurting you now — which is the practical implication, and the one that determines whether you should be relaxed or worried.

The people most exposed to this are the ones who did the most careful work.

What I'd actually change

I haven't run these tests myself — everything above is either Anthropic's documentation or a linked report, and I've tried to be explicit about which is which. But the changes with the clearest evidence behind them are small:

Delete the re-check instructions. It verifies its own work now, and the instruction compounds with the behaviour rather than adding to it.

Delete any rule telling it not to think. That one actively causes the artifacts you're trying to prevent.

Delete forced progress narration. It narrates more on its own now.

Raise max_tokens. If you take one thing from this, take this one — it's the cause of the most common complaint about the model.

Then run a fresh effort sweep on your own evaluations instead of inheriting settings from a model that no longer exists.

The uncomfortable part

The reason this is hard isn't technical. It's that the scaffolding represents real work, done carefully, in response to real failures. Every rule in your CLAUDE.md is there because something went wrong once and you fixed it.

Deleting it feels like giving up ground.

But those rules were never neutral. They were a tax you agreed to pay in exchange for reliability you couldn't otherwise get. When the reliability arrives for free, the tax doesn't stop being charged — it just stops buying anything. And in a few specific cases documented above, it starts working against you.

The rule was never the thing keeping it in line.

The rule was the thing holding it back.

I put the full delete list — every item, every source — in the community. It's free. 👉 The New Operators

Video version: Claude Opus 5: The New Rules Of Context Engineering