Anthropic's latest Claude Code note looks like a prompt-writing tip until you read the number. For Claude Opus 5 and Claude Fable 5, the Claude Code team says it removed more than 80% of the system prompt with no measurable loss on its coding evaluations.

A team simplifying context architecture for an AI coding agent

That is a small bomb for teams that have spent the last year doing the opposite: adding more rules, more examples, more repo notes, more memories, more skills and more tool warnings every time an agent did something wrong.

The lesson is not "delete your instructions." That would be the lazy version. The useful lesson is sharper: context is now an architecture problem. You have to decide what an agent sees, when it sees it, what it can retrieve, what it can do, and which controls belong outside natural language entirely.

For AI practice in 2026, that matters more than another clever prompt template.

Prompt engineering was too small a frame

Prompt engineering was a reasonable starting point when most LLM work meant one question, one answer. You tuned the wording, gave examples, added a role, demanded a format and tried again.

Agents changed the shape of the problem. A coding agent does not see only the user prompt. It sees a system prompt, repo instructions, nested CLAUDE.md or AGENTS.md files, tool definitions, memory, retrieved files, chat history, task plans, previous errors, test output and sometimes external documents from MCP servers or search tools.

Anthropic's engineering post on effective context engineering defines context broadly: the set of tokens that land in the model during inference, including system instructions, tools, MCP, external data and message history. Sourcegraph's practical guide says the same thing in more operational language: context engineering is the discipline of designing what the model sees on every call.

That wording matters. If prompt engineering is writing the sentence, context engineering is maintaining the pipeline that produces the sentence, the files around it, the tools it can call and the history it carries forward.

Once an agent runs for many turns, context becomes a scarce resource. More tokens do not automatically mean more understanding. Anthropic's earlier context-engineering post warns that recall degrades as context grows and that every extra token spends part of the model's attention budget. Anyone who has watched an agent forget a simple workflow halfway through a huge session has seen this in practice.

What Anthropic actually changed

The July 24 Claude post argues that new models need less rigid scaffolding than older ones. Anthropic says Claude Code had become overconstrained by overlapping system prompts, CLAUDE.md files and Skills. One example was exactly the kind of contradiction teams accidentally create: one instruction says to leave documentation where appropriate, another says not to add comments.

Older agent setups often respond to such failures by adding one more rule. The post's new advice is different. Instead of telling the model "do not write comments," tell it to match the surrounding code's comment density, naming and idiom. Let the model infer the local convention rather than hard-code a global ban.

Anthropic also criticizes excessive examples. Examples can be useful, but they can narrow the model's exploration space. If you show ten rigid examples for tool use, the agent may imitate those shapes even when a better path exists. The suggested replacement is clearer tool interfaces: better names, schemas, parameter descriptions and affordances that make the right action easier.

The post also pushes progressive disclosure. Do not front-load every verification rubric, tool manual and rare edge case into the initial context. Load details when the agent needs them. Keep CLAUDE.md lightweight. Spend the fixed context budget on project-specific pitfalls, not on directory maps, dependency lists or general coding advice the agent can infer from the filesystem.

Claude Code's public memory docs now point in the same direction. They tell users to keep CLAUDE.md for durable context that would be useful to a new teammate, move multi-step procedures into Skills or path-scoped rules, remove outdated or conflicting instructions, and use the /doctor checkup to trim content Claude can derive from the codebase. The docs say that trim check requires Claude Code v2.1.206 or later.

That is not vague prompt mysticism. It is maintenance work.

Why "use judgement" makes people nervous

The Hacker News thread around the Claude post had 332 points and 219 comments when checked through the HN API. The reactions were not just applause.

Some users liked the direction. They argued that huge instruction preambles are baroque, that agents can now infer many conventions, and that people are fighting model behavior with brittle one-off rules.

Others were less comfortable. One commenter asked for a specific list of removed system-prompt changes because "give Claude judgment" is too vague for people building agents. Another pointed out that once a project has 50 grown-over-time instructions from commits, docs, chat history and memory, contradictions become likely. Several comments split the world into two work styles: hands-on human-in-the-loop pairing versus walk-away automation. Those two styles do not need the same context architecture.

The strongest objection was safety. If a model is asked to use judgement, what happens when the action has consequences? HN brought up sandbox escapes, production actions, prompt injection and the difference between a model deciding comment style and a model deciding whether it may touch a network, secret or deployment target.

That objection is correct. Style guidance can move from rigid rules to judgement. Hard safety controls should not.

What teams should remove

Start with the easy cuts.

Remove rules that state facts the agent can inspect. "This is a Python repo" is usually wasted. So is a complete directory tree that goes stale the next time someone moves files. Let the agent list files when it needs them.

Remove duplicate rules. If the same testing instruction appears in the system prompt, CLAUDE.md, a skill and a task template, you have not made it four times more important. You have made it four places to edit.

Remove rules that were written for old failures if the current model no longer fails that way. A prompt scar from a 2024 model may be a tax on a 2026 model.

Remove global style bans unless they are truly universal. "Never add comments" is worse than "follow the surrounding file's comment style." "Always use dependency injection" is worse than "match the pattern used in this module unless you have a reason not to."

Remove generic checklists from the initial context. "Run tests, lint, check security, update docs" may sound safe, but as a giant always-loaded block it becomes background noise. Put verification steps into a callable skill, a CI script or a task-specific checklist that appears when the agent is actually ready to verify.

Remove examples that only demonstrate the obvious. Keep examples when they encode a local trap, a nonstandard API or a policy decision. Delete examples that merely show the agent how to call a normal function.

What teams should keep

Keep project-specific gotchas. If the migration runner looks harmless but can corrupt staging data, tell the agent. If a package manager command is forbidden because it rewrites lockfiles incorrectly, tell it. If generated files should not be edited by hand, tell it.

Keep business rules that are not obvious from code. Code rarely explains why a payment edge case exists or which regulator forced a validation step. Those rules belong in durable context or nearby documentation.

Keep constraints that protect data, money and production systems. But do not rely on prose alone. A sentence saying "never deploy without approval" is weaker than permissions that make deployment impossible without approval.

Keep local conventions that save review time. The rule should be specific enough to help and narrow enough not to become a religion. "In API handlers, return typed error objects from lib/errors" is useful. "Write clean code" is not.

Keep short maps to where deeper material lives. A good CLAUDE.md can say, "For database migrations, load docs/migrations.md. For public API changes, load docs/compatibility.md." That is different from pasting both documents into every session.

Better tools beat longer instructions

Many teams try to fix agent mistakes with text because text is easy. Tool design is harder, but it is often the better fix.

If two tools overlap, the model wastes turns choosing. If a tool accepts a vague free-form string where an enum would work, the model can invent a mode. If a tool returns 5,000 lines when the agent needs 20, it floods the context. If a destructive tool has no dry-run or confirmation boundary, a paragraph of warnings will not make it safe.

A useful agent tool has a clear name, narrow purpose, typed parameters, safe defaults and compact output. It should make the common correct path easier than the dangerous path. When the action is irreversible, the safety boundary should be in the tool or environment, not in the agent's memory of a rule.

This is where context engineering stops being prompt work and becomes platform work. DevEx teams need to own tool surfaces, logs, permission levels, test commands, sandbox policies and review gates. A clever CLAUDE.md cannot compensate for a reckless tool API.

Memory is not a junk drawer

Agent memory has the same failure mode as human note-taking: it starts useful, then becomes a pile.

Claude Code's docs separate CLAUDE.md files from auto memory. CLAUDE.md is for instructions you write. Auto memory is for notes Claude writes based on corrections and preferences. Both can help. Both can rot.

A durable memory should prevent repeated steering. It should not be a transcript, a task log, a guess or a rule that applies to only one file. If a memory says "the team prefers small PRs," useful. If it says "fix the thing from Tuesday," garbage.

For teams, the practical move is to audit memory the way you audit dependencies. Who can write it? Can the agent write without approval? Does it expire? Is it scoped to a repo, user, directory or task type? Can you see what was loaded into a run after a bad output?

One HN user said they got better results after disabling auto-memory and actively shaping CLAUDE.md, skills and docs. That is anecdote, not a universal rule. But it points to the right operational question: do not add memory because it feels futuristic. Add memory when you can inspect it and when it improves repeatable work.

Progressive disclosure is the new default

The cleanest pattern is to keep the starting context small and let the agent earn more context as it works.

At launch, give it the mission, hard constraints, relevant repo instructions and the tools it needs to discover more. For coding, let it inspect files, search symbols, run tests and read docs on demand. For business agents, let it retrieve the relevant policy or customer record when the task calls for it.

Then load specialized context only at the moment it matters: migration rules before database changes, release rules before publishing, security review before external network or auth work, style guides before user-facing copy, evaluation rubrics before scoring output.

This does two things. It reduces token waste. More importantly, it makes context provenance clearer. When the agent makes a decision, you can ask: which instruction, file, memory or tool result was actually in view?

That is much easier to debug than one giant prompt casserole.

Where judgement is not enough

There are places where Anthropic's advice should not be misread.

Do not replace secrets policy with model judgement. Do not replace network controls with a sentence. Do not let an agent decide on its own whether to modify production data, approve payments, send customer email, delete records, rotate keys, publish legal copy, perform active security testing or merge code into a protected branch.

For those actions, keep hard controls: sandboxing, allowlists, separate credentials, human approval, typed tools, dry runs, audit logs, CI, policy-as-code and rollback paths. Natural-language instructions can explain why the boundary exists, but they should not be the boundary.

The right split is simple. Let the model use judgement for local style, task planning, which files to inspect, when to ask a question, and how to adapt to surrounding code. Use systems for irreversible authority.

How to measure whether simplification worked

Do not simplify a prompt and declare victory because it feels cleaner. Measure it.

Take a representative set of tasks: a bug fix, a refactor, a documentation change, a failing test, a small feature, a repo-specific gotcha. Run them with the old context and the trimmed context. Track success rate, review comments, token use, latency, number of tool calls, number of human corrections, test pass rate and whether the agent violated any hard constraint.

For coding agents, include tasks that should fail safely. The agent should refuse or ask before touching production config, secrets, destructive migrations or external writes. If trimming context improves normal tasks but weakens those boundaries, you cut the wrong thing.

Keep the context change in version control. Treat CLAUDE.md, skills, tool descriptions and agent settings like code. Review diffs. Explain why a rule exists. Delete it when the reason expires.

The practical takeaway

The longest prompt is no longer the most mature setup. It may be a museum of old failures.

Anthropic's 80% cut is not proof that every team can delete four-fifths of its agent instructions tomorrow. The claim comes from Anthropic's own coding evaluations, not a public universal benchmark. It is still a strong signal: frontier agents are less helped by piles of brittle rules than many teams assume.

The better question is not "what should our master prompt say?" It is "what context architecture lets the agent do the work, see the right evidence, use safe tools and stop before it can cause damage?"

That is the shift from prompt engineering to context engineering. Less magic. More maintenance.