Claude Code's Creator Deleted 80% of Its System Prompts for Opus 5 — Performance Went Up
Boris Cherny, the creator of Claude Code, was asked at Y Combinator’s Startup School 2026 how people learn to build effectively with Claude. His answer was one of the more practically useful pieces of AI engineering advice this year.
There is no one weird trick. Approach the model empirically. Give it a task that is too hard, provide the tools to verify its own work, watch where it fails, and fix that specific failure — better prompting, a new skill, or an MCP connection that provides missing context. Then repeat.
The longer version involves deleting system prompts.
What Happened With Opus 5
When Anthropic shipped Claude Opus 5 — which posted 96.0% on SWE-bench Verified and took the #1 spot on Frontier-Bench — the Claude Code team ran the scaffolding they had carefully tuned for Opus 4 through the new model. It worked. Then they started removing prompts.
They removed 80% of the system prompts that had been built and refined for the previous generation. Performance improved.
The reason is structural. Each model generation has different default behaviours, different failure modes, and a different internal weighting of instructions. Scaffolding optimised to correct Opus 4’s weaknesses became noise that interfered with Opus 5’s strengths. An instruction that prevented Opus 4 from hallucinating package names was an unnecessary constraint on a model that handles it better. A prompt teaching Opus 4 to be careful about context boundaries was deadweight for a model with a longer native context and better boundary awareness.
Cherny’s framing was direct: “Every model generation it behaves differently, it has a slightly different personality, and you have to take the time to get to know it and then adjust the harness based on that.”
The Liability Frame
The standard engineering intuition is that system prompts are an asset — hard-won configurations that accumulate value over time. The Opus 5 result suggests the opposite mental model: system prompts are a liability that expire with the model they were built for, and carrying them forward incurs debt.
The implication for teams that have deployed Claude Code or similar agentic tools for more than one model generation: the careful prompt library from the previous cycle is probably hurting you. Testing by removing sections, rather than adding to them, is likely underweighted in most deployment workflows.
On Prompting Advice
Cherny was blunt about prompting best practices in general: “Maybe don’t listen to the LinkedIn influencers. There is nothing like [one weird trick]. That simply doesn’t exist.”
Most prompting advice is reverse-engineered from a model generation that has already changed. By the time it is widely distributed, the behaviour it describes may not be current. The model at launch and the model six months later — through fine-tuning, RLHF adjustments, and in-context instruction changes — are not the same thing.
The empirical approach Cherny described is the same one a developer uses to debug an unfamiliar codebase: observe the actual behaviour, form a hypothesis about the failure, fix the specific thing, and verify the fix. Not “apply best practices from a similar project.”
Micromanagement vs Outcomes
A secondary point from the Startup School session: users who give overly specific instructions consistently get worse results than users who define outcomes and let the model route to them. The instinct to control every step — the prompting equivalent of micromanagement — conflicts with how current-generation models work best.
Cherny said this is one of the more common and correctable failure modes he sees. Operators constrain model behaviour based on assumptions from older models or from AI systems with different architectures. The fix is not a better constraint but the removal of the constraint and a direct test of what the model does without it.
Claude Opus 5 shipped on July 24, 2026. The YC Startup School session was public and recorded on the Y Combinator YouTube channel.