The Instructions Were Never Helping
- Rich Washburn
- 19 hours ago
- 7 min read
The engineer who created Claude Code sat down at Y Combinator one day after Opus 5 shipped and told a room full of founders to delete their CLAUDE.md files.
Not tweak them. Delete them.
His name is Boris Cherny. He built Claude Code inside Anthropic and still runs it. He was on stage at YC's Startup School, and the first thing he confirmed was something almost nobody caught in the Opus 5 release notes. Anthropic had deleted 80% of Claude Code's own system prompt.
The reason is worth slowing down for. Every instruction in a system prompt is read on every single turn. Every line costs attention. And most of those lines were written to correct behaviors that older models lacked — models that no longer exist. Opus 5 just does the right thing without being told. So the instructions were not helping. They were dead weight. And when Anthropic ran the ablation — stripped everything, including the tool prompts — the model came out slightly smarter. Lines have rent to pay. Most of them were behind on rent.
The delete schedule
Boris did not stop at what Anthropic does internally. When the interviewer asked whether everyone building with AI should do the same thing, he said 100%. Then he attached a schedule.
Every six months: delete your CLAUDE.md, delete your skills, delete your hooks. Watch what the model does without instructions. Only when it stumbles on the same thing repeatedly do you add one line back.
Think about what that implies. The harness — the entire scaffolding of instructions, rules, and configuration files that developers have been meticulously curating for years — is not accumulated knowledge. It is scar tissue. Each line was a workaround for a model that has since been replaced. Keeping it is like keeping a cast on a leg that healed three versions ago. Boris called the harness something you rederive per model. Like getting to know a new creature, not maintaining an old machine. If your CLAUDE.md has been accumulating since Sonnet 3.5, you are not providing the model with memory. You are providing it with constraints written for a model that no longer exists, and you are paying for those constraints on every single turn.
Product overhang
Before the system prompt discussion, Boris told the origin story of Claude Code itself, and the story contains a formula worth pulling out. He calls it product overhang — the gap between what a model can already do and what any product lets it do. Two years ago, that gap looked like this: the models could already write entire files. Every coding product on the market was still doing autocomplete. Claude Code was the thinnest possible harness dropped into that gap. No scaffolding. Just give the model terminal access and let it work.
That gap built a product. Now run the same logic forward. Boris, who is arguably the person best positioned on earth to know, says the overhang with today's models is bigger than it was then. Unclaimed. Commercially valuable. The next Claude Code is not going to come from adding more instructions to a model. It is going to come from someone who finds the thing the model can already do that no product is letting it do, and builds the thinnest possible harness to close that gap.
The instruction-heavy approach to AI product development is the opposite of this. It assumes the model needs to be told everything. The product overhang thesis says the model is already doing more than your product allows, and the fastest path to value is removing constraints, not adding them.
535,000 lines in 11 days
Then Boris told a story that sounds impossible until you check it.
Claude Code runs on Bun, the JavaScript runtime Anthropic acquired last December. Bun was over 500,000 lines of Zig — a low-level language where you manage memory by hand. The team had been hunting memory leaks one case at a time. Then an engineer named Jared decided to stop hunting and let the model try a full rewrite.
He defined a test suite. Bun is extremely well-tested, and Node.js has its own comprehensive suite. That meant the model had a referee — an objective, automated way to know whether it was right at every step. One prompt. A dynamic workflow orchestrating dozens of Claude instances in parallel. Eleven days. 535,000 lines of Zig converted to Rust. It is in production right now. Claude Code, the tool millions of developers use daily, is running on the result.
This was not possible with previous models, even with steering. The test suite was the critical piece. Not the prompt. Not human guidance. The automated verification loop that told the model at every step whether it had done the right thing.
The three-sentence prompt
After the Bun story, Boris described the skill that separates elite users from everyone else. It is not prompt engineering. It is two things: give the model a task slightly too hard, and give it a way to verify its own work. Then he showed the receipt. A prompt he typed into Slack — Claude running in a Slack channel via Claude Tag — that has been running for over two weeks.
Three sentences. Rewrite the Electron desktop app in Swift. Run the Electron app in a Mac virtual machine, screenshot it. Compare it to the Swift version pixel by pixel. Do not stop until you are done.
No framework. No scaffolding. No multi-step plan document. A task beyond what he knew the model could complete. A verification loop. An exit condition. That was it. Claude even decided on its own to open a Slack channel and live-blog its progress with screenshots.
When people ask what separates the top 1% of Claude users, this is the answer. They build the checker before they hand over the task. The model does the work. The verifier is your job.
Claude maintaining Claude
Take that pattern, make it recurring, and you get the part of the talk that should change how every engineering team operates. Anthropic has Claude maintaining Claude's own codebase on a schedule. Not the models. The products — the CLI, the iOS app, the Android app, the desktop app. One-sentence prompts on timers.
Clean up dead code. Every day, Claude runs static and dynamic analysis across all codebases and files pull requests to delete what is unused. Nobody prompted the static and dynamic analysis part. It figured that out. They call one routine the abstraction police. Claude scans all codebases daily, finds near-duplicated abstractions — things that are probably the same concept rebuilt in different ways across different teams — and unifies them. Twenty to thirty routines running every day. Hundreds of agents. Sometimes thousands. Doing the work that used to take teams of engineers. The humans ship products. Claude does the chores. Every routine is a one-sentence prompt on a timer. A cron job. The moat is not the routine. It is deciding what is worth repeating.
Forget your priors
Boris's closing advice was the most important thing he said, and it was also the simplest.
Do not listen to LinkedIn influencers. Do not read Twitter. Forget what you learned about past models. Forget what you learned about computer science theory. Look at the model, try a task, see where it struggles, adjust. It is not a theoretical science. It has become an empirical science.
This is the part that is hardest for experienced engineers, because overspecifying used to be the job. Twenty years of engineering discipline says: define the requirements, write the spec, enumerate the edge cases, instruct precisely. That discipline built good software when humans were writing it. Applied to a model that has outgrown instructions, it produces worse results than giving it almost nothing and letting it work.
Boris learned to code on a TI-83 calculator. His guide is still on the internet — a beginner's tutorial from 2004 at ticalc.org. Practical problem first, theory second. That loop built Claude Code.
The inversion
Here is where this connects to something larger. I have been writing about the end of prompting for a while. The thesis was that prompt engineering was a temporary skill — a friction layer that existed because models were not smart enough to infer intent. As models got smarter, the friction would disappear.
What Boris described at YC is the next phase of that argument, and it is sharper than I expected. The instructions were not just unnecessary. They were actively degrading performance. The model was smarter without them. The harness you built for the previous model is a constraint on the current one. This inverts the relationship between the human and the system. For the entire history of software, the human's job was to specify behavior precisely. The more precise the specification, the better the output. With frontier models, that has flipped. The more you specify, the more you constrain the model to a previous version's limitations. The skill is no longer telling the model what to do. It is building the environment where the model can discover what to do and verify its own work. The model does the work. The human designs the verifier. That is the new division of labor. And it is not a future state — it is happening right now, in production, at the company that built the model.
The question is no longer whether these systems can do the work without detailed instruction. They already can. The question is whether the people building with them can let go of the instinct to instruct, and learn the new skill instead: giving the model a task slightly too hard, building the checker, and getting out of the way. Most of us are still over-specifying. The models have moved on. The instructions were never helping. They were just in the way.
Rich Washburn is a technologist and strategist working at the intersection of AI, infrastructure, and capital. He is Managing Partner and Chief AI Officer at Eliakim Capital.