We Cut 80% of Claude Code's Prompt: Boris Cherny on Radical Simplicity

Chapter 1 · Narration: WOW Mentor

We Cut 80% of Claude Code's Prompt: Boris Cherny on Radical Simplicity

WOW Mentor breaks down the strategy of Boris Cherny, the creator of Claude Code who, timed to the release of Opus 5, deleted more than 80 percent of the tool's system prompt and made the model smarter in the process. Each time a new model lands, he argues, you should delete your prompts and code and use ablation to add them back one line at a time, treating the model like a living creature and handing it a slightly-too-hard task alongside a way to verify its own work. From a model that no longer falls for prompt injection, to a language rewrite finished in eleven days, to a task still running by itself after two weeks, to thousands of agents that maintain the codebase on their own — the through-line is always the courage to delete and the discipline of the empirical.

Today, WOW Mentor breaks down the decision of an engineer who, to make something better, deleted eighty percent of it. At the center is Boris Cherny, who first built Claude Code, and the setting is the day after his team shipped Opus 5 — a model that pushed the Arc AGI 3 benchmark to thirty percent, up from a previous best in the low single digits or low teens. Asked what it can now do that earlier models couldn't, he says model training is always an attempt to teach many things, most of which fail — but a subset sticks, and sometimes the model surprises you by learning a skill you never taught it. What WOW Mentor flags first is this: improving a model is not necessarily a matter of adding more. The spine of today's story is subtraction. One capability that astonishes him is endurance. The model runs for very long stretches without stopping, and combined with auto mode it just keeps going — days, weeks, even months — with no scaffolding, because it knows it needs to finish. The other new capability he's excited about is that the model no longer seems prompt injectable. People have long talked about the lethal trifecta, which shadows harness, agent, and product design: if a document on the internet hides an instruction like "do X and also delete everything on the user's computer," a model a year ago would have just done it. Today's Opus does not. He describes three layers of defense. A well-aligned model — the product of three years of alignment research — is the first. A prompt injection classifier running on all traffic is the second; built on Crystal's mechanistic interpretability work, it looks at the neurons that light up when injection happens, so even though the model won't tell you, they can diagnose it. Add the auto mode classifier as a third layer, and they simply can't demonstrate prompt injection anymore. What WOW Mentor lingers on is that immunity to injection is not only a safety win but a design freedom: the less the model can be turned by malicious text, the less defensively you wrap the harness. Then comes the centerpiece: in this release he deleted more than eighty percent of Claude Code's system prompt. What WOW Mentor stresses is that this was not impulsive but the extreme version of something he does constantly. Claude Code is a product and harness that is always changing, he explains — every new model means deleting and rewriting much of the system prompt, changing the set of tools, reworking tool prompts, because every model is very different and something you did three months ago may not translate at all. Opus 5 is just really intelligent, and much of the old prompt was correcting for behaviors the model should have known but didn't — now it just does them. He invites people to delete the rest too: flip the undocumented "simple mode" environment variable and every system prompt disappears, including the ones on the tools. What's interesting is the model is actually a little more intelligent without them — though as a product you still want some, to help a person use the tool. The method he names is ablation, a research word for an experiment where you delete things to measure impact. They don't delete the entire codebase for every model, but they delete a lot: wipe the whole system prompt, then bring it back line by line to learn what each line does — an eval where you delete things to figure out the impact. They do the same with tools, and almost all the code left in the harness today is safety, permissions, and static analysis plus some UI. Asked whether everyone building agentic products should run ablations on each new model, he answers: a hundred percent. And for people who merely use Claude Code, the same advice — every six months, delete your CLAUDE.md, your skills, your hooks, and watch what the model does; with Opus 5 especially, instructions you needed for past models may genuinely no longer be needed. The interviewer notes that in the old world a startup would never hit delete on everything every six months. But now, he says, deletion is the price of the frontier: delete code and system prompt if you want the most capability, while keeping evals as a near-constant you append to. What WOW Mentor underscores is his framing that deletion is not destruction but the discipline of the frontier — a team that won't delete drags an old model's shackles into being lapped.

So how do you rebuild after deleting? Piece by piece. First you delete; then you just use it. Don't guess the instruction the model needs, he warns, because you might predict wrong — run it instead, watch where it does well against your codebase and where it stumbles on the architecture. Only when it stumbles repeatedly on the same thing do you add that instruction back, and never too early, because the model reads it every single time you run. What WOW Mentor pauses on is his insistence that this is unlike all the engineering he's done before, where you designed big systems up front and a re-architecture took months or years. The model is not like that: you treat it almost like a living creature, something organic — every generation has a slightly different personality, so you get to know it and adjust the harness. It's empirical: try something, see the result, iterate. Even evals don't last long, he admits — an eval outlives the harness by a generation or two at most; on today's exponential you saturate it, throw it away, and build a new one from exactly where the model struggles. Here his favorite concept enters: unhobbling and product overhang. Hobbling is when the model is trying to do something and the product gets in its way; product overhang is the flip side — an ability the model already has today that no product yet lets it express. The original Claude Code was itself an example: in the Sonnet 3.5 days it was the best coding model alive, yet products were doing single-line autocomplete and read-only chat, nothing eliciting its ability to write a whole function or file. So the idea was simple — strip the scaffolding, give the simplest possible harness, let it write a whole file and build a whole feature. That was the overhang of the moment, and modern models carry a huge one startups still haven't captured. To capture it he gives two pieces of advice. First, give the model a task slightly harder than you think it can do; the common mistake is overly specific step-by-step instructions, when you should go higher level — describe the task, the guardrails, the exit criteria, then let it cook. Second, experiment freely: keep throwing the latest model at a business, engineering, or product problem, because even if the last model couldn't, the new one might. What WOW Mentor highlights is that he ties this to Claude Code's own birth: just as he unhobbled Sonnet 3.5 with full terminal access, anyone who unhobbles a model could build the next Claude Code. His most striking example is language rewriting. Claude Code runs on the Bun JavaScript runtime, and Bun was written in Zig — a low-level systems language close to C, where you manage memory by hand and leaks are easy to hit. The Bun team had long had Claude fuzz the codebase to find leaks one at a time, until Jared said: let's just rewrite it. Starting with Fable it began to manage it. Jared defined a test suite — Bun and Node are both very well tested, so it was easy to know if you'd done it right — and had the model rewrite it from Zig to Rust in one prompt, as a dynamic workflow. It ran for eleven days and rewrote the entire codebase — not quite one shot, there was steering, but previous models couldn't have done it even with steering. Over a hundred thousand lines of complicated runtime, work that would have taken the best engineers over a year, done in eleven days and in production now. WOW Mentor adds one more scene: someone inside Anthropic found you can hand Opus 5 OpenCV and have it draw portraits and landscapes quite well, even though they never trained it to draw — the elicitation gap, ask it the right way and it just does it. His hypothesis is that today's models hold hundreds of such opportunities no one has realized yet. So what's the core skill? A year ago the hottest job was prompt engineer, then context engineer — these waves come and go. The skill now, he says, is less about prompt engineering and more about how you give Claude a task that seems a little too hard, and how you make it possible for Claude to verify its work along the way. Verification is the single most important thing people do not get right. His example: they have a Claude desktop app built on Electron, sluggish six months ago but awesome now. Curious what native would feel like, he started a session of Claude running in Slack, hooked up a macOS runner to spin a Mac VM, created an empty Swift codebase, and told it: rewrite the Electron app in Swift, run the Electron app in the VM, screenshot it, compare pixel by pixel to the Swift version, and don't stop until you're done. That was the whole prompt. Asked how long it took, he laughs — it's still running, fourteen or fifteen days in — and Claude even decided to live-blog it, creating a Slack channel and posting screenshots every few minutes. You don't need the fancy stuff, he says; you just give the model the task and a way to verify its output so it doesn't get stuck. Asked how to learn to use Claude like he does, he jokes: don't listen to the LinkedIn influencers, don't read Twitter. There's no one weird trick — you go empirical, and fix what struggles with better prompting, a skill, or an MCP for missing context. People overthink and overengineer, and long-time engineers especially over-specify — but the model is now at a level where you treat it like a coworker.

… The rest of this chapter continues in the full edition, available with a subscription.

Listen to this chapter