We Deleted 40% of Our AI's Instructions. Nothing Broke.

This week Anthropic published a new set of context-engineering rules for its Claude 5-generation models. Buried in it is a sentence worth reading twice: they removed over 80% of Claude Code's system prompt and measured no loss on their coding evaluations.

Eighty percent of the instructions, deleted. Same results.

If you think of instructions as control — more rules, more reliability — that sentence doesn't parse. It should. It's the clearest signal yet that the way most companies write instructions for AI is a habit inherited from weaker models, and that the habit is now costing them.

We run agents in production, not as a demo. So we ran the experiment on ourselves the same morning: snapshot the current instruction files, apply the new rules, measure. Seven files, 51,674 characters before, 30,848 after. A 40% cut, in a single pass, with no capability we could find missing.

The number isn't the interesting part. The test we used to decide what stays is.

What actually changed

The guidance amounts to a handful of reversals. Translated out of engineer-speak:

Stop writing rules where judgment will do. The old way was to fence the model in: never do X, always do Y. Anthropic's own example is instructive — they replaced a hard rule about comment style with a principle: write code that reads like the code around it. A capable model applies a principle across a thousand situations you didn't anticipate. A rule only covers the one you did.

Stop padding with examples. Examples feel like clarity, but they quietly narrow the model to the shapes you showed it. Better to design the choice well in the first place — name the options, make the interface obvious — than to demonstrate it three times.

Stop loading everything upfront. Instructions don't all need to arrive at once. Detail belongs in references the model pulls in when the work calls for it, not in a wall of text it reads before every task. Anthropic's framing is a tree of context loaded at the right time.

Stop repeating yourself. Most bloated instruction sets say the same thing in three places, because each was written by someone patching a different failure. The duplication doesn't reinforce the rule. It just burns attention.

What we cut

Almost everything we removed fell into three piles.

Motivational preamble. Our agent's identity brief opened with a page of exhortation — you are not a chatbot, you are an operational employee, you do not wait to be told to work. Stirring. Also inert. That file went from 318 lines to 53, and the agent's behavior didn't change, because the behavior was never coming from the pep talk.

Process narration. Step-by-step boot sequences describing what to read and in what order. A capable model works out the order from the task.

Restated rules. The same guardrail written into three files by three different fixes, over months.

None of that was doing work. It was doing reassurance — ours, not the model's.

What we kept, and why we stopped at 40%

Here's the part worth taking away.

Anthropic could cut 80% because what remains in a coding tool's prompt is mostly product context — how their software behaves. We could only responsibly cut 40%, because a much larger share of our instructions isn't guidance at all. It's fact about our business that no model can infer:

• which approvals a human has to give before money moves or a contract is signed
• which sectors we serve and what those buyers actually care about
• what we will never say in a client's voice
• the specific accuracy rules we wrote after real mistakes — verify a claim before asserting it, use the actual link rather than a placeholder, never invent a statistic

That last category matters more than it looks. It's tempting, reading "let the model use judgment," to delete every constraint as legacy hand-holding. Don't. A rule that exists because something went wrong once isn't bloat — it's institutional memory, and it's the one thing a model genuinely cannot regenerate from first principles. Judgment can tell it how to write. Only you can tell it that a claim on your website has to be defensible because your buyers are hospitals.

So the test we ended up with, and the one we'd hand to anyone doing this:

> Does this instruction encode judgment the model already has — or a fact about our business it could not possibly know?

The first kind is deletable. The second kind is the actual asset. Cut the first, and what's left is a surprisingly clean document: a short statement of who the business is, what it sells, where the hard boundaries sit, and what has burned us before.

If you're going to try this

Four things we'd tell a business copying the exercise:

1. Snapshot before you cut. We committed a baseline of every file before touching one, so the diff was measurable and reversible. "It feels better" is not a result.
2. Cut in one pass, then live with it. Trickling out changes makes it impossible to attribute a regression to anything.
3. Keep the incident-born rules. If you can name the day a rule was written and the mistake that caused it, it stays.
4. Measure something. Ours was crude — file size plus a week of real work. Crude and honest beats elaborate and skipped.

The part that isn't technical

Most organizations have quietly accumulated a pile of AI instructions the way they accumulate policy: additively, defensively, one incident at a time, with nobody ever deleting a line. The result is long, contradictory, and mostly ignored — by people and models alike.

The fix isn't a better prompt. It's editorial discipline about what your business actually requires versus what you were nervous about. Writing a good instruction file turns out to be the same skill as onboarding a good hire: state the mission, name the non-obvious constraints, flag the things that got someone in trouble last year, and then get out of the way of a competent professional.

The models got good enough to be trusted with the rest. The question is whether your instructions ever say anything only you could have said.