Inside Claude Code: Why Anthropic Cut Its System Prompt 80% on Purpose
Agentic AIMost teams assume a more capable model needs more instructions. Anthropic’s Claude Code team found the opposite: as models got better, the system prompt got dramatically shorter — on purpose.
What Happened
At a fireside chat at the AI Engineer World’s Fair, Cat Wu and Thariq Shihipar from Anthropic’s Claude Code team detailed several internal practices behind the tool’s evolution. The most counterintuitive: the Claude Code system prompt shrank by 80% for Fable and Opus 4.8, because, as the team put it, “removing examples was extremely helpful.” Rather than prescriptive rules like “don’t do X,” the team shifted toward contextual guidance — and now maintains different, tailored system prompts for different model tiers rather than one prompt meant to fit all of them.
On security, the team leans heavily on Claude Code’s auto mode, backed by what Cat Wu described as “thousands of evals” and dedicated red-teaming. A Sonnet-based classifier evaluates every tool call against the user’s actual instructions, managing permissions dynamically rather than through static allowlists. Credential injection lets Claude call APIs without ever holding the credentials directly — a specific architectural choice to keep secrets out of the agent’s own context.
Why It Matters
The prompt-shrinking finding matters beyond Claude Code specifically: it suggests that as models improve, the highest-leverage prompt engineering move may be subtraction, not addition. Teams building on top of frontier models by stacking more examples and more edge-case instructions into their prompts may be fighting the model’s own competence rather than using it — Thariq’s framing was that prescriptive constraints crowd out a capable model’s own judgment.
The eval strategy described is also instructive: Cat’s team optimizes for task completion first, then layers in behavioral evals for things like Claude Code inappropriately suggesting breaks mid-task — evidence that “did it work” and “did it feel right to use” are being tracked as genuinely separate metrics, not one proxy for the other.
What This Means for Builders
The team’s internal decision rule — “ant fooding,” their term for requiring a feature to prove user retention internally before public release — is a concrete governance pattern any team shipping agentic tools could borrow. The stated proof point: Claude Tag currently lands 65% of the team’s own product engineering PRs, a retention number strong enough to justify continued investment without needing an external launch to validate it first.
On tool design, the team’s philosophy of favoring fewer, more general-purpose capabilities over many specialized tools is a direct answer to a common agent-building mistake: tool sprawl creates cognitive overhead for the model itself, not just for the developer maintaining the integration.
The So What
The through-line across security, prompting, and tool design is the same: constrain less, verify more. Dynamic permission classifiers instead of static rules, contextual guidance instead of prescriptive examples, internal usage data instead of launch-day guesswork. Teams building their own agentic tools should treat “does our team actually keep using this” as the release gate — not whether the demo looked good.
Source: Simon Willison
Content created with AI assistance and reviewed for accuracy.
Join the conversation
Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.
Join Stack Insiders →