Anthropic admits over-constraint: For the Claude 5 generation, the less it’s restricted, the better it works

Claude Code team member Thariq Shihipar admits in a post that the prompt-writing skills you’ve worked hard to learn are mostly the rigid rules that older-generation models needed. In the face of Claude Opus 5 and Claude Fable 5, Anthropic cut the system prompt by more than 80%. Internal coding benchmarks showed no measurable decline.
(Background: Anthropic released Claude Opus 5! Performance is close to the Fable 5 price but cut in half, making it the newest default model)
(Additional context: Claude Code’s new /goals command—separates execution and evaluation to prevent AI agents from “being lazy” and lying)

Table of contents

Toggle

• How over-constraint happens
• Those old tricks are now myths
• Four-layer division is the new solution

This week, Claude Code team member Thariq Shihipar wrote in the official blog that they significantly rewrote Claude Code’s system prompt, targeting two new-generation models: Claude Opus 5 and Claude Fable 5. He said that much of the prompt experience accumulated one rule at a time has become ineffective in front of these new models.

The scope of this change is not small: more than 80% of the content in the system prompt was directly deleted, and internal coding evaluations showed no measurable drop. This means: writing more and micromanaging more doesn’t mean Claude performs better; for the new generation of models, often the less you control, the smoother it runs.

How over-constraint happens

In the article, Shihipar breaks down a specific scenario: within the same request, instructions from three parties—system prompt, CLAUDE.md, and Skills—stack on top of each other, often clashing. For example, one side says “retain necessary explanations as appropriate,” while the other says “no writing code comments.” Claude first has to spend effort deciding which one counts, before it can truly start coding. The rules aren’t helping the model save effort; they first create a layer of contradiction that needs to be unraveled.

These rules didn’t appear out of thin air. When Claude Code first launched, the team feared the worst case—like the model mistakenly deleting files—so they stuffed the system prompt with hardline requirements, essentially installing safety rails for older models whose judgment wasn’t yet up to par. In older versions, it was clearly written that by default it should not write comments, should not produce explanation strings spanning multiple paragraphs unless the user explicitly requests it; otherwise, don’t spontaneously generate planning or analysis files.

For the models at that time, this trade-off was necessary.

But when the same guardrails were placed in front of the new models, things changed. The new system prompt has replaced that long list of rules with a single decision: “Write code that reads like the surrounding code.” In plain terms, the comment density, naming, and customary writing styles all follow the surrounding code.

Those old tricks are now myths

The first most counterintuitive one: in the past, the team believed the best way to teach Claude how to use tools was to provide examples—listing usage scenarios one by one. Now they’ve found that examples actually lock the model’s exploration space into the boxes drawn by the examples. A better approach is to make the tool design more self-explanatory. For instance, a Todo tool only needs to list states as the enumerated values pending, in_progress, completed. Then the model can tell how to use it just by looking at these states, without needing to be taught rigidly through examples.

The second is “everything upfront.” In the past, system prompts tended to write code review and verification-process details all at once—whether you use them or not—so the context window gets occupied by a big chunk before work even begins. Now, verification and code review have been split into skills that can be called on demand. Some tool documentation has also been changed to lazy loading: when the model truly needs to use it, it finds the complete definitions via ToolSearch.

This progressive disclosure logic also applies to your own CLAUDE.md: don’t think about stuffing all knowledge into one big file. Splitting it into a whole tree of files loaded at the right moments is the right solution.

The third is closest to day-to-day operation: CLAUDE.md manual memory is being replaced by automatic memory. Previously, users had to press hotkeys themselves to write lessons learned into CLAUDE.md; now Claude determines which content is worth keeping and saves it as memory on its own. The more tightly you manage it, the less it equates to remembering better.

Four-layer division is the new solution

Shihipar’s solution isn’t to delete all rules—it’s to redistribute what each layer of context should handle.

System Prompt is tied to product logic; most developers rarely touch it. Only people building agent frameworks should spend effort here.

Keep CLAUDE.md lightweight, leaving space for the real traps and nuances in the code libraries. Don’t write useless lines like “Claude understands as soon as it looks at the file structure.”

Treat Skills as lightweight guides. Unless it’s an extremely important domain, don’t write too many constraints. For longer skills, split them into multiple files.

References should be brought in primarily in code form. A single HTML design draft usually lets the model capture what you want more than a paragraph of text description or a screenshot. Specifications can also be more concrete: a detailed test suite, or existing functions waiting to be ported from another codebase, can directly serve as specs. Going further, you can even write them as rubrics, allowing Claude to dynamically pull out verification sub-agents and check whether the results match the specific taste you want, item by item.

The official side also rolled out the claude doctor command: in Claude Code, enter /doctor to check whether your skills and CLAUDE.md are too large and too restrictive. What the developer community has been discussing lately is the same kind of trouble: you’ve installed a bunch of Skills, Plugins, and MCP Servers, and you’ve also written a CLAUDE.md so long you can’t finish reading it—yet before any work starts, half of the context window is already eaten away.

Your old experience—“the more finely you write rules, the more obedient the AI will be”—isn’t a bonus in front of the new generation of models. It’s just dead weight taking up space. The real question isn’t what rule you can add next, but which rule can already be deleted.