The 80% rule: context engineering for Claude 5

On July 24th, the same day Claude Opus 5 shipped, Thariq from Anthropic published a post that hit 300 points on Hacker News and is still being shared. The claim: Anthropic removed over 80% of Claude Code's own system prompt for the Opus 5 and Fable 5 generation of models. Their coding evaluations didn't register the change. Four fifths of the guidance came out and quality held steady.

The reaction in the comments was a mix of "obvious in retrospect" and "this breaks everything I've been doing." Both responses are correct. Here's why the 80% number matters, what Anthropic actually changed, and the specific things you should now delete from your own context.

What "unhobbling" means

Anthropic's word for what they did is unhobbling. The argument goes like this: most of the constraints they'd written into Claude Code's system prompt were guardrails built for older, weaker models. Those models genuinely needed the guardrail — without it, they'd do the wrong thing. Claude Opus 5 and Fable 5 mostly don't. They've internalized enough about coding conventions, documentation norms, and contextual judgment that you don't need to tell them explicitly.

When you leave those constraints in the prompt anyway, something worse than waste happens. The constraints start conflicting with each other, and with the model's own reasoning. One line said to leave documentation "as appropriate." Another said "DO NOT add comments." The model had to spend tokens resolving which instruction won before it could touch a file. You were paying — in latency, in money, in quality — for the model to untangle the scaffolding you'd built to help it.

The fix was not better few-shots or a cleverer reformulation. It was deletion.

The comment rule: a concrete illustration

The most cited example from the post is the commenting instruction. Here's what Claude Code's system prompt used to contain:

This rule existed because older models would write excessive, often wrong comments. It solved a real problem in 2024. But it also fired in cases where multi-line documentation was exactly right — complex algorithms, public APIs, code that would confuse any reader who hadn't written it themselves.

The replacement, in full: "Write code that reads like the surrounding code: match its comment density, naming, and idiom."

One sentence. It produces better results across more codebases than the rule set did, because it trusts the model to read the room rather than follow a rigid directive. The old version fails the moment you point it at a repository whose house style includes docstrings. The new version doesn't.

The six shifts

Thariq's post describes six places where the right approach changed for Claude 5 generation models. Each one is a migration, not just advice.

Rules → Judgment. Stop writing "never do X" unless you have a specific, demonstrable failure mode that Claude can't reason its way out of from context. The model can read a codebase, infer conventions, and match them. Explicit rules that repeat what it can figure out don't reinforce the behavior — they compete with it.

Examples → Interface design. This is the most counterintuitive shift. The old pattern was to give Claude examples of how to call your tools. The new finding: examples constrain the model to a narrow exploration space. A better tool interface teaches Claude how to use it without consuming context on demonstrations. If your parameter accepts three states, make it an enum. The type signature says more than an example does, and it doesn't box the model in.

Everything upfront → Progressive disclosure. Not everything belongs in the system prompt or CLAUDE.md. Claude Code now supports skills that load at the right time, and deferred tools that only expand their schema when searched for. A verification workflow, a deployment checklist, a code review procedure — these don't need to sit in CLAUDE.md taking up context on every request. Put them in a skill. Load them when the task calls for them.

Repeated instructions → Simple tool descriptions. Older models sometimes needed the same guidance in the system prompt and the tool description. That's no longer necessary. Put instructions once, where they belong — in the tool description — and delete the mirror copies elsewhere.

Manual memory → Auto-memory. Claude Code now writes what it learns about a project to a local memory file, loaded at session start. You don't need to design CLAUDE.md as a memory store. Keep it lightweight; let the auto-memory do the bookkeeping.

Simple specs → Rich references. Instead of a markdown description of what you want, try an HTML mockup. Instead of describing expected output in prose, write a test suite. A rubric — a structured description of what "good" looks like — is a more useful reference than a prose explanation. Claude can handle increasingly complex references, and the richer the target, the better the result.

Two API changes that will break your integration

Beyond the prompting shifts, Opus 5 introduced two changes to how the API behaves that aren't defaults you can ignore.

Thinking is on by default. On Opus 4.8, requests ran without thinking unless you opted in. On Opus 5, thinking happens unless you've explicitly turned it off. max_tokens now caps thinking plus response text together — any workload that ran thinking-free on 4.8 needs that cap revisited before it starts silently truncating output.

Disabling thinking is blocked at certain effort levels. thinking: {"type": "disabled"} only works at effort high or below. Pair it with xhigh or max and every request returns a 400. This is a hard breaking change from 4.8, where the two settings were independent. Check your harness configurations before assuming Opus 4.8 defaults carry over.

What to actually do right now

The migration is mostly subtraction, applied in a specific order.

First, run /doctor in Claude Code (v2.1.206 or later). It deduplicates your local and checked-in CLAUDE.md, proposes cuts to anything Claude could derive from reading the codebase, and reports before changing anything. Low-risk, high-signal.

Second, apply the test to every line in your CLAUDE.md: could Claude work this out by reading the repository? Directory layouts, dependency lists, architecture overviews — all candidates for deletion. What stays is genuine gotchas: non-obvious decisions, dependency quirks, conventions that look wrong until you understand the reason. "We keep all types in types.go" is a gotcha. "Write clean code" is not.

Third, pull every verification instruction. Any line in your system prompt that says "verify your work," "double-check before responding," or "use a subagent to confirm" is stacking on top of behavior the model already does. Opus 5 verifies its own output without being asked. Those lines aren't free — they trigger extra loops on agentic runs that you paid for and didn't need.

Fourth, cap subagent delegation explicitly. Opus 5 reaches for delegation more readily than earlier models. On genuinely parallelizable work, that's a win. On small tasks, it multiplies cost for nothing. Add a line that tells the harness when delegation earns its cost — and when it doesn't.

Fifth, add explicit length instructions. Opus 5 writes longer responses and narrates its own work more than earlier models. Effort controls how much the model thinks, not how much it writes. You need to ask for conciseness directly; lowering effort won't do it.

The pattern that will keep repeating

Every six months or so, the right amount of hand-holding decreases. The model gets better at reading context and exercising judgment in ambiguous cases. The harness that was necessary last year is friction this year.

The 80% number is startling, but the frame underneath it is what matters: context engineering doesn't get less important as models improve. The skill shifts. The high-value work moves from writing guardrails to designing interfaces — tools with expressive parameter schemas, skills structured for progressive disclosure, references that give the model a clear target rather than a set of constraints.

What you built over the last year isn't wasted. The knowledge — what your team's workflow looks like, what "good" means for your specific use cases, what context Claude actually needs — that carries forward. What you're refactoring is the encoding, not the knowledge itself. The agents and systems you've built are still valuable. They just need their scaffolding trimmed to match the model they're running on.

Open your CLAUDE.md and read it as if you were the model. How much of it would you have worked out on your own?