Anthropic Deleted 80% of Claude Code's Prompt. It Got Smarter
Boris Cherny strips instructions out as models get smarter. It is why Claude Code keeps improving while doing less. The 10 takeaways
The model got better.
Most AI teams add instructions every time a model gets smarter. Cherny’s team strips them out.
His thesis: frontier models are hobbled by products built for last year’s weaker ones. The fix is fewer instructions, harder tasks.
The proof is live. His team handed Opus 5 one instruction, rewrite the Bun runtime, 100,000 lines of Zig, into Rust. 11 days and thousands of parallel agents later, it shipped, tested and passing, from that single line.
“All you have to say is ‘use a workflow.’ That’s it.”
Cherny created Claude Code. He shipped Opus 5 the day before this interview. I watched it twice, so you can skip it.
Here are the 10 learnings that matter.
sponsored by Granola:
Less manual work, better results, that's Cherny's playbook, and it's Granola's too.
Platform agnostic, Granola takes notes in the background wherever your meetings happen: Zoom, Slack, Google Meet, Teams, even in person:
▫️ Get a refresher before each call, with instant context on who you’re meeting and what came up last time
▫️ Clean summaries and action items the moment you hang up
▫️ Always follow up: Granola drafts a follow-up email seconds after the call, or pulls it from your CRM via MCP
(code THEAICORNER for 1 month off)
1. Prompt injection just became a mostly solved problem
For 3 years, prompt injection has been the scariest phrase in agent security.
“If the model reads some instruction on the internet that’s like, do X and Y and Z and also delete everything on the user’s computer, a year ago the model would have just done it. But nowadays Opus does not.”
The fix is a stack, over a single patch. Layer one is the model itself, 3 years of alignment research into resisting instructions found in the wild, beyond just instructions from the user. Layer two is a classifier built on mechanistic interpretability: specific neurons light up when the model hits an injection attempt, even when the model stays silent about it. Layer three is a classifier running across all traffic on top of both.
The consequence is direct: agents that read the open web, files, or email got materially safer by default, and the whole security checklist you build around them just moved a layer up.
2. The 80% deletion was the method, not a cleanup
Here is the line that reframes your own system prompt.
“A lot of the stuff in the system prompt was correcting for these behaviors that the model should have known, but it didn’t. Now Opus 5 just does it.”
Every prompt you have ever written is a patch. It exists because the model failed at something on its own, so you told it how. The mistake is treating the patch as permanent. Cherny’s team treats it as temporary by default, and runs the deletion as a process:
Delete the full prompt
Run the product with nothing added back
Watch where the model actually stumbles
Add back only the line that fixes that specific failure
Repeat at every model release
Most teams accumulate instructions and never remove them, and that accumulation caps every new model’s ceiling. Deletion is the unlock.
Every prompt is a patch. Patches expire.
3. Claude can now run unattended for weeks. Boris proved it on himself.
“It’s still running. It’s been a little over 2 weeks.”
Boris opened a Slack session and asked Claude whether it had access to a Mac runner on GitHub. It said no, so he gave it one. He asked whether it could reach an empty repo for a Swift rewrite of Claude’s Electron desktop app. It said no, so he gave it access.
Then one instruction: rewrite the app in Swift, run both versions in a Mac VM, compare them pixel by pixel, keep going until done. Zero custom scaffolding, zero slash commands. 15 days later it was still running, and Claude had opened its own Slack channel to post progress screenshots, unprompted.
The bottleneck on long-running agents was never the model. It is the verification loop around it.
Build the check, not the babysitting.
4. The 11-day rewrite already in production
Claude Code runs on Bun, a JavaScript runtime built on Zig, a language with manual memory management.
“He had the model rewrite it from Zig to Rust. It was one prompt. It was a dynamic workflow. And it ran for 11 days, and it rewrote the entire codebase.”
A Bun engineer had thrown this exact task at every new model generation as an informal benchmark, and prior models failed outright. What made Opus 5 different was ground truth: Bun and Node.js both carry large, mature test suites, which gave the model something to check its own work against for 11 straight days. There was steering along the way, and the model did the work. Boris estimates the same rewrite would have taken a strong human team over a year.
The cost of rewriting a codebase in a new language just collapsed. Audit what you have been postponing for exactly that reason, then run it through the Claude Code system.
5. Verification is the new prompt engineering
“The skill nowadays is less about prompt engineering and more about figuring out how do you give Claude a hard task that seems a little bit too hard. And then how do you make it possible for Claude to verify its work along the way.”
A year ago the hottest job title was prompt engineer, then context engineer. Both tell the model what to do. Verification tells the model whether it succeeded, so it corrects itself with you out of the loop. That is the exact mechanism behind both the Bun rewrite and the 2-week Swift rewrite: each had a built-in way to check the output, a test suite in one case, a pixel-diff script in the other.
A hard task without verification stalls or drifts. A hard task with verification becomes a long-running agent. If a task feels stuck, a better prompt rarely fixes it, and a way for the model to check its own output usually does.
Want to build that muscle? Start here:
▫️ The autoresearch playbook: agent optimization loops
▫️ The Loop Library: 12 Claude Code recipes
▫️ The AI code review checklist
6. Product overhang: the idea behind Claude Code’s origin story, and yours
“The model is able to do all sorts of things with today’s models that we have not yet realized. There is often not a product that lets the model do this. On the flip side, often what happens is the product gets in the way. We call that hobbling.”
2 years ago, Claude models could already write entire files and functions, while the products on top still shipped single-line autocomplete or read-only chat. The model had outrun its own interface, and Claude Code’s entire pitch was closing that gap: full terminal access, minimal scaffolding, let the model do what it could already do.
The vocabulary is worth stealing. Product overhang: the model can already do X, and no product lets it. Hobbling: the product actively restricts the model from doing X. The fix is subtraction, remove friction over adding features, the same self-evolving principle behind every serious agent stack.
The biggest product opportunity right now sits inside a capability the current model already has. Nobody has built the interface for it yet.
7. Stop overspecifying, even after 20 years of coding
Experienced engineers make this mistake more than anyone.
“You want to describe the task, you want to describe the guardrails, you want to describe the exit criteria, and then just go let the model cook.”
The instinct to specify every step in order comes from decades of programming systems that could never infer intent. That instinct now caps what the model will do for you. The new shape: describe the task at a high level, set the guardrails over the procedure, define what done looks like, then step away and check back later.
Detailed, numbered instructions were correct for last year’s models. They are a ceiling on this year’s, which is the whole argument of the Opus 5 playbook.
8. Nobody trained Claude to draw. It draws anyway.
Small, and the clearest window into what stays undiscovered.
“You can ask Opus, hey, use OpenCV to draw this image. And it’s actually quite good. It can do portraits. It can draw animals. It can do landscapes. We didn’t train the model to draw.”
This spread inside Anthropic as a curiosity, over a roadmap item. Someone handed the model a computer vision library, asked it to render an image, and it worked, with zero training toward that outcome. The capability existed the entire time. Nobody had asked the right way.
The highest-leverage discoveries in this interview came from play over planning. Set aside time with no deliverable, hand the model a tool it was never built for, and see what surfaces, the same instinct behind the power-user setup that finds features months before the docs do.
9. How one prompt becomes thousands of agents
“It doesn’t just do one agent. It doesn’t just do ten parallel agents. It’s going to start a bunch of agents to do the first pass. Based on that, it might do a second step where it has another set of agents that verify the work.”
A dynamic workflow spins up a sandboxed virtual machine and lets Claude orchestrate waves of agents against one hard task: a first pass, a verification pass, a summary pass, then another fan-out. Boris, whose background is functional programming, calls it an algebra for agents, sequence and parallel composed inside a token budget.
Routines run the same idea on a schedule, and Anthropic now maintains its own codebases with them, across the CLI, iOS, Android, and desktop apps:
▫️ Dead-code cleanup: one sentence of instruction, runs daily, opens its own deletion PRs
▫️ Experiment hygiene: fully-rolled-out experiments get shipped and their flags removed automatically
▫️ Test coverage: missing tests get written, useless tests get deleted
▫️ “Abstraction police”: finds near-duplicate patterns across codebases and unifies them, unprompted
20 to 30 of these routines now run daily across Anthropic’s own codebases. That is the number to benchmark your own automation against, and the one-person OS is the scaled-down version of the same idea.
10. Coding is solved, with one honest caveat
Boris has said publicly that coding is solved, and here is the exact line he draws around it.
“There’s still codebases that are super deep systems codebases where Claude still struggles. There’s distributed systems where Claude still struggles. There’s really in-the-weeds UI verification, like something is off by a pixel.”
Opus 5 made a sharp leap in vision and computer use, and it remains imperfect at the pixel-level UI verification that shipped the 2-week Swift rewrite 7 sections up. Deep systems codebases and distributed systems stay genuine gaps.
The operating principle behind every takeaway here is the one Boris states directly near the end: forget what you learned about past models, run the task, watch it fail, adjust from evidence. He calls it empirical over theoretical. The honest claim beats the viral one, so know which bucket your task sits in before you plan around either answer.
The Claude Code playbook
The core thesis in one line: the model is usually further ahead than your product, your prompt, or your assumptions about it. Your job is to find that gap and stop getting in the way.
▫️ Founders: the biggest opportunity right now is an unhobbled product built on a capability that already exists, over a new model capability. Audit what the current model can do against what your interface allows this week, then ship the agent that closes the gap.
▫️ Investors: the moat in agentic products is shifting from model access toward the best verification loop and the least scaffolding. Ask portfolio companies how much of their system prompt survived the last model upgrade unchanged. A high number is a warning sign, and one worth adding to your diligence list.
▫️ Operators: the ablation habit scales down to any team on Claude Code today. Delete your CLAUDE.md, your skills, and your hooks every 6 months. Rebuild only what the model proves it needs.
▫️ Everyone else: the lesson travels. The instructions you wrote to compensate for a tool’s weaknesses 6 months ago are often the thing capping it today.
The 5 principles to steal
Delete first, add back only what fails. Ablation beats accumulation.
Give harder tasks with looser instructions. Guardrails and exit criteria, over step-by-step procedure.
Build the verification, not the prompt. A test suite or a visual diff turns a stalled task into a 2-week autonomous run.
Look for product overhang before you look for a new feature. The model can already do more than your interface allows.
Be empirical. Test the current model directly, watch it fail, adjust from that, over last year’s notes.
Delete the prompt. Watch where it breaks. Rebuild only what earns its place.
If this breakdown saved you half an hour, send it to one founder or investor still hand-tuning a system prompt from 3 model generations ago.
Keep reading
Master Claude Code
▫️ The Loop Library: 12 Claude Code recipes
▫️ The Claude Code system that replaces your tool stack
▫️ Loop engineering for coding agents
Run the new models right
▫️ You are overpaying for intelligence: the model router
▫️ How to never hit Claude limits: the token system
Build the agent stack
▫️ The Self-Evolving Agent Stack
▫️ Give your agent its own computer
▫️ The one-person startup operating system
Cherny's approach is a refreshing reminder that complexity often hobbles progress. Stripping prompts reveals the model's potential, while the real challenge lies in creating effective verification. It's a stark contrast to the typical "add more" mindset. Simplify, observe, then iterate—this is how you unlock capability.