Short version
Most people who use AI seriously build up a set of standing instructions — do it this way, never do that, always include these sections. Those instructions were written to compensate for what older models got wrong. The newest models do not have those weaknesses, and they follow instructions far more literally, so the old corrections now distort the result instead of improving it. Anthropic states this outright in its own documentation. We cut our planning instructions roughly in half and the output got better. The rules for what to cut are simple, and they apply to briefing colleagues too.
Key facts
- The official line Old instructions are "often too prescriptive" and "can degrade output quality" Source: Anthropic documentation
- The cause Newer models interpret prompts "literally and explicitly" and do not infer requests you did not make Source: Anthropic model prompting guide
- The rule Explain the reason behind a rule instead of shouting the rule — "Claude is smart enough to generalize from the explanation" Source: Anthropic prompting best practices
One piece of vocabulary, and then we are done with jargon
Where this article says standing instructions, it means any set of directions you have saved and reuse — a house style you paste in every time, a saved prompt, a document your team keeps for "how we ask the AI for a plan". In developer tooling these are packaged as files called skills, but the idea is not technical: it is the note you leave for the assistant so you do not have to repeat yourself. Everything below applies whether yours is a proper configuration file or a paragraph in a shared document.
What happened to us
We had a set of standing instructions for one job: when someone asks for a plan, produce it in a particular format, with a particular list of sections, always as a designed page rather than a plain document. It worked. Plans got read instead of filed, which was the whole point.
Then a new model arrived, and the same instructions started producing worse plans. Not dramatically worse. Worse in the specific way that is hardest to spot: it followed our format rigidly even when the request did not suit it, produced a heavy designed page for a two-paragraph question, and stopped exercising the judgement we had originally wanted from it.
The instinct in that situation is to add more instructions. Add an exception. Add a "but only when". That instinct is exactly wrong, and the vendor's documentation says so.
It is not just us
Anthropic's own guidance for its newest models says this, in plain words: "Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. Review and consider removing older instructions if default performance is better."
Read the last sentence again, because it is unusual. The company is telling customers that the work they did to improve results may now be making them worse, and that deleting it is a legitimate fix. The same page notes the model also updates its approach as it learns from the task in front of it — which is another way of saying the scaffolding you built is doing a job the model now does for itself.
Anthropic's engineering team puts the underlying principle more directly still, in its guide to context engineering for agents: "Smarter models require less prescriptive engineering, allowing agents to operate with more autonomy."
Two honest caveats, because this is the kind of claim people over-extend. That "too prescriptive" line appears on the page for the previous version of the model, and the documentation says instructions written for it carry over: "your existing Claude Fable 5 prompts should perform well on Claude Fable 5.1 without changes" (Anthropic). So it is the same guidance, one page removed. And there is no official page specifically about designing standing instructions for the very newest model. The direction is well documented. The fine detail is inference.
Why over-explaining backfires
Here is the mechanism, and it is not mysterious.
Anthropic's guidance describes recent models as taking you at your word: the model "interprets prompts literally and explicitly", "does not silently generalize an instruction from one item to another" and "does not infer requests you didn't make" (Anthropic, model prompting guide). Older models were vaguer, so people compensated: they added emphasis, repeated themselves, wrote rules in capital letters, spelled out every step. Those additions were corrections for a specific weakness.
Remove the weakness and the correction becomes a distortion. Anthropic's own worked example is a code-review setup: a prompt saying "only report high-severity issues" or "don't nitpick" was written to stop an older model drowning you in trivia, and the newer model "may follow that instruction more faithfully than earlier models did" — investigating just as thoroughly, then declining to report what it judges below your stated bar (same page). Measured bug-finding falls while the model's actual ability has risen. It looks like the new model got worse. It got more obedient, to an instruction that no longer fits.
The analogy is one every manager knows. You hand a new starter a forty-step checklist because they do not yet know what good looks like. You do not hand the same checklist to an experienced colleague — and if you do, you get worse work, because they stop thinking and start ticking boxes. What has happened is that the tool moved from the first category to the second, and most people's standing instructions were written for the first.
What to delete
Anthropic's own guidance is unusually specific about what now hurts.
| What you probably wrote | Why you wrote it | What it does now |
|---|---|---|
| "CRITICAL: you MUST use this when…" | It was not being used enough | Used far too often. Anthropic: prompts written "to reduce undertriggering on tools or skills… may now overtrigger. The fix is to dial back any aggressive language" — write "Use this tool when…" instead (prompting best practices) |
| A rigid list of steps for every task | The old model wandered off | Mechanical work. Anthropic's guidance: "prefer general instructions over prescriptive steps", because the model's reasoning "frequently exceeds what a human would prescribe" (prompting best practices) |
| "Do not use bullet points or headings" | Older models over-formatted everything | The current model "leans the other way": Anthropic says if your prompt carries anti-formatting language, "remove it or replace it with a rule that says when specific formatting is appropriate" (current model guidance) |
| "Hold everything until the final answer" | Older models chattered while working | Anthropic names this line — "hold all findings for the final response" — and says "remove lines like that before adding anything" (current model guidance) |
| A long list of edge cases | Covering every eventuality felt safe | Anthropic's advice is to "only add context Claude doesn't already have" and to include three to five well-chosen examples, not an exhaustive catalogue (skill authoring, prompting best practices) |
A practical self-check follows from that first row: if you find yourself reaching for capitals, treat it as a signal that the rule needs a reason rather than a louder voice. Anthropic's prompting best practices demonstrate the swap directly — "NEVER use ellipses" is listed as the less effective version, and "your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them" as the better one, because "Claude is smart enough to generalize from the explanation." The rule alone breaks on the first case the author never imagined; the reason does not.
Worth flagging one place the documentation is not of one mind. The skill authoring guide still suggests that when an instruction is being missed, one option is "using stronger language such as 'MUST filter' instead of 'always filter'" — the opposite lever from the one the prompting page recommends. Both pages are current. Our reading is that emphasis is a reasonable last resort for a rule the model keeps missing, and a bad default for a rulebook, but you should know the guidance pulls two ways before you delete every capital letter you own.
What still helps
Cutting is not the same as emptying. These earn their place.
- A one-line role. "You produce planning documents that a reader can review, decide on, and hand off." Anthropic's guidance on setting a role is blunt about the return: "even a single sentence makes a difference" (prompting best practices).
- The reason behind a constraint, not the constraint alone. Instead of "never use ellipses", write "this will be read aloud by a speech system, which does not know how to pronounce them". The model generalises from the reason and handles the cases you never listed. The rule alone cannot.
- Three to five good examples. That is the documented number — "include 3–5 examples for best results" (prompting best practices) — and they should be chosen to show a judgement call, how to weigh one option against another, not to enumerate every situation.
- A clear definition of finished. What has to be in it, what counts as good enough. This is the part people leave out and then argue about.
- Things it cannot possibly know. Your client names, your internal constraints, the rule that test accounts are always excluded. The official principle is to "only add context Claude doesn't already have", and to challenge every piece — "does Claude really need this explanation?" (skill authoring best practices).
Notice the pattern. What survives is context and standards. What goes is procedure.
The trap on the other side
"Less is more" is easy to over-apply, and Anthropic flags the opposite failure just as clearly: instructions that are too general, or that wrongly assume the model shares context it has no way of having. The line worth memorising, from their engineering team: "minimal does not necessarily mean short; you still need to give the agent sufficient information."
The goal they name on the same page is to "find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome" — in plain terms, the smallest set of genuinely useful information that gets you the outcome you want. Not the shortest instructions. The least noise. A brief that omits your actual constraints is not lean, it is incomplete, and you will pay for it in rework.
Our rewrite, concretely
Here is the before and after, because abstract advice about instructions is exactly the sort of thing that sounds agreeable and changes nothing.
| Before | After | Why |
|---|---|---|
| Every plan must be a designed page | Plain document by default; designed page only for a finished piece someone outside the team will read | Forcing the heavy format onto internal drafts wasted effort and made short answers absurd |
| A fixed list of required sections | The same list, described as a sensible default, with "adjust it to the request" | A rigid template is precisely the over-specification the new model does not need |
| Detailed step-by-step procedure | The objective, the standard for "done", and the distinction between a client document and a technical one | Procedure produced box-ticking; standards produced judgement |
| Rules in capitals | The same rules as sentences with their reasons | Explained rules generalise; shouted rules do not |
| Everything in one long document | A short core, with the detail for each document type kept separately and consulted when relevant | Only what is needed gets read |
The single change with the largest effect was the first one. Our old instructions forced one output format on every request because that format had solved a real problem — plans in plain text were not being read. But "always" was doing damage the moment the model was good enough to judge for itself when the heavy version was warranted.
Before: ALWAYS output the plan as a self-contained designed page. NEVER produce a plain document. The plan MUST include all six sections listed below, in this exact order. After: Produce a plan a reader can review, decide on and hand off. Plain document by default; a designed page when the plan is a finished piece for someone outside the team, because those get read and plain ones get filed. The six sections below are a sensible default — adjust them to the request.
The second version is not much shorter. It is less bossy, it says why, and it hands back the judgement calls. That is the whole move.
Where the experts disagree — and why that is useful
It would be neater to end there. But the people building these tools do not actually agree on how much structure is needed, and you should know that before you rebuild anything.
Boris Cherny, who created Claude Code at Anthropic, described his workflow in January 2026 as planning first. InfoQ's write-up of his posts, published on 10 January 2026, quotes him: "If my goal is to write a Pull Request, I will use Plan mode, and go back and forth with Claude until I like its plan. From there, I switch into auto-accept edits mode and Claude can usually 1-shot it. A good plan is really important!"
By June he had reversed it. The tip archive howborisusesclaudecode.com, which collects his public posts and dates them, records him saying "I don't use that anymore. I use auto mode — instead of plan mode", with the reason attached: "It was really important for Opus 4 through 4.5, but starting with 4.6, and definitely with 4.7, it just doesn't need it." That is an aggregator rather than an Anthropic page, and we could not find the June statement on a primary source we could fetch, so treat the exact wording as the archive's rather than as a quote we verified at source. The direction of travel matches everything above.
Both statements can be true, and the resolution is the useful part. If the plan was scaffolding — something the model needed in order to think straight — then yes, it is becoming unnecessary. If the plan is a checkpoint for a human, a moment to confirm this is the right job before hours of unattended work begin, it has nothing to do with the model's abilities and it is not going away. As models take on longer unsupervised runs, the second purpose gets more valuable, not less.
So keep the plan. Stop treating it as instructions for the model, and start treating it as the thing you approve.
Auditing your own instructions in an afternoon
- Find them. The saved prompt, the shared document, the paragraph everyone pastes. Most teams have more of these than they think, and nobody owns them.
- Establish a baseline without them. Take three real requests and run them with no standing instructions at all. This feels reckless and it is the most informative thing you will do all afternoon — sometimes the plain result is already better. It is also the official method: Anthropic's authoring guide says to "run Claude on representative tasks without a Skill", document the failures, and "measure Claude's performance without the Skill" before writing anything (skill authoring best practices).
- Delete on sight: capitals, "always" and "never" without a reason, step-by-step procedures, formatting bans, and lists of edge cases.
- Rewrite each surviving rule as a rule plus its reason. If you cannot articulate the reason, that is your answer about whether the rule should exist.
- Re-run the same three requests and compare against the baseline. Keep only what demonstrably closed a gap.
- Put a date and an owner on it. These instructions have a shelf life now — roughly the interval between model releases, which is months. Something that expires and belongs to nobody will quietly rot.
And one rule for when it goes wrong: if the result is too generic, add one good example rather than five rules. If the instructions are being ignored altogether, make the description of when they apply clearer — do not make the language more forceful. Louder is the fix that stopped working.
The part that is not about AI at all
Read the list of things to delete again with a colleague in mind rather than a machine.
Rules in capitals with no reason. A rigid procedure for work that needs judgement. An exhaustive list of edge cases instead of a few good examples. Formatting bans. No clear definition of what finished means. Every one of those is a bad brief for a person, and every one of them produces the same failure: technically compliant work that misses the point.
The reason this looks like a new problem is that with people, the mismatch is invisible. An experienced colleague handed a beginner's checklist quietly ignores the silly parts and gets on with it. A model does not. It follows what you wrote, exactly, and hands the result back — which makes it an unusually honest mirror for the quality of your instructions.
If your standing instructions turn out to be full of shouted rules with no reasons attached, that is worth a moment's thought about the briefs your team gives each other.
Bottom line
The work you did last year to get better results from AI is now depreciating, and the vendor says so in its own documentation. That is not a failure — it is what happens when the thing you were compensating for gets fixed.
The move is not to add more instructions when quality drops. It is to delete the corrections, keep the context and the standards, explain your reasons instead of shouting your rules, and hand the judgement calls back. Budget an afternoon, keep a note of what you removed, and put a review date on it, because you will be doing this again the next time a model ships.
And if you take one thing: explain why, do not just forbid. It is the difference between a rule that generalises and a rule that breaks on the first case you did not anticipate — which was always true of people, and is now true of the software too.
FAQ
Do I really need to rewrite instructions that are working?
Test rather than assume. Run three real requests with your instructions and without them. If the plain result is as good or better, your instructions have stopped earning their place.
Why would older instructions make a newer model worse?
They were written to correct weaknesses the newer model does not have, and newer models follow instructions more literally. A correction that is no longer needed becomes a distortion — the model obeys it faithfully and produces something you did not want.
Is this Anthropic's official position or an opinion?
Official. Anthropic's documentation says instructions written for prior models are often too prescriptive, can degrade output quality, and should be reviewed and possibly removed. The specifics of applying that to the very latest model are inference, not documentation.
Does the same apply to ChatGPT and other tools?
The documented guidance quoted here is Anthropic's. But the underlying cause — more capable models following instructions more literally — is not specific to one vendor, and the audit costs an afternoon whatever you use.
Should we stop asking for a plan before the work starts?
No. The reason has changed. The plan is no longer scaffolding the model needs to think clearly; it is the checkpoint where a human confirms this is the right job before hours of unsupervised work. That matters more as models run longer, not less.
How short should instructions be?
There is no target length. The principle is the smallest set of genuinely useful information that gets the outcome you want — and Anthropic is explicit that minimal does not mean short. Leaving out your real constraints is not lean, it is incomplete.
How often will we have to redo this?
Roughly whenever a significantly better model arrives, which currently means months rather than years. Put a date and an owner on the document so the review happens on purpose.
ISA After Hours · Augsburg
Want to compare the instructions that survived contact with real work?
ISA After Hours is a community of Israeli and international tech professionals in Augsburg. We meet after work, swap what actually improved our results, and delete the rest.
Join ISA After Hours →Sources
- platform.claude.comAnthropic: Prompting guidance — "skills developed for prior models are often too prescriptive"
- platform.claude.comAnthropic: Prompting best practices — roles, reasons behind constraints, general instructions over steps
- platform.claude.comAnthropic: literal instruction following, and the code-review harness example
- platform.claude.comAnthropic: Skill authoring best practices — degrees of freedom, only-add-what-it-lacks, baseline first
- infoq.comInfoQ, 10 January 2026: Boris Cherny's plan-first workflow, quoted
- howborisusesclaudecode.comTip archive: the June 2026 reversal — "I don't use that anymore. I use auto mode" (secondary, unverified at primary source)
- anthropic.comAnthropic engineering: Effective context engineering for AI agents
- platform.claude.comAnthropic: What changed in the current model, including formatting guidance
- claude.comThariq Shihipar: the case for HTML documents that started our original instructions