You’ve spent years mastering software architecture. You’ve built complex systems, written elegant prompts, and designed intricate workflows. And now, the thing you’re most proud of might be the very thing holding you back from the AI revolution.
That’s the uncomfortable truth at the heart of a conversation with Boris Cherny, the creator of Claude Code. He’s not just building the future of AI programming; he’s actively dismantling the past.
In a recent YC talk, Cherny dropped a bombshell that should fundamentally change how you think about building AI products: “The smarter the model gets, the less product scaffolding you need. The true opportunity isn’t in adding more features—it’s in removing the ones that are getting in the way.”
This isn’t just another tech trend. It’s a paradigm shift that threatens to render everything you know about product engineering obsolete.
The 80% Deletion That Changed Everything
When Claude Code was updated for the new Opus 5 model, the team did something radical. They deleted over 80% of the system prompt. Not because they had to. Because the model was smart enough to figure it out on its own.
Think about that for a second. For months, we’ve been told that prompt engineering is the new black. That the key to unlocking AI’s power is crafting the perfect instruction set. But Cherny is saying the opposite: the more complex your prompt, the more you’re hobbling the model.
“We’ve been doing ablation experiments,” Cherny explained. “We delete the entire system prompt and then add it back line by line to see if it actually helps. And you know what? When we removed all the prompts, the model actually performed slightly better.”
This is the equivalent of telling a world-class sprinter that they need to run in a straightjacket. The model already has the capability; you’re just preventing it from being used.
The “Product Overhang” Trap
Cherny introduced a concept that should terrify and excite every product builder: Product Overhang.
It’s the idea that our current models can already do amazing things that we haven’t even thought to ask for. The product—the interface, the prompts, the constraints—is actively blocking the model’s potential.
“The models have all these capabilities,” Cherny said. “And the product is essentially hobbling them. The real opportunity isn’t building new workflows. It’s removing the ones that are in the way.”
Consider the birth of Claude Code itself. When Cherny started, the best AI coding tools were doing single-line autocomplete or chat. They gave the model read-only access to the codebase. The idea that the model could write an entire file, let alone an entire function, was considered science fiction.
Cherny’s bet was simple: “What if we just removed all the scaffolding and gave the model full access to the terminal?” That one act of subtraction created a product that is now rewriting entire codebases in a single prompt.
The Death of the Prompt Engineer
Remember that hot job title from a year ago? Prompt Engineer? It’s already dead. And the new one is dying too.
“It’s gone from ‘prompt engineer’ to ‘context engineer’,” Cherny observed. “But both are fleeting. The real skill isn’t telling the model how to do the work. It’s giving it the task, the guardrails, and a way to validate its own results.”
This is the shift that most developers are failing to make. They’re still writing incredibly detailed instructions, trying to micromanage the AI’s thought process. But the modern model doesn’t need that. It needs you to trust it.
Cherny’s example is telling. He wanted to experiment with a native Swift version of the Claude desktop app. His prompt to the AI? “Take this Electron app, rewrite it in Swift. Run it in a Mac VM. Take screenshots. Compare pixel by pixel. Don’t stop until it’s done.”
That’s it. No step-by-step instructions. No complex workflow. Just a goal, a constraint, and a verification mechanism. The AI has been running for two weeks, spawning thousands of sub-agents, and is now live-blogging its own progress in a Slack channel.
From “How” to “What”
The old engineering mindset was all about the “how.” How do we build this? How do we architect for scale? How do we ensure reliability?
The new AI-native mindset is about the “what.” What do we want to achieve? What are the constraints? What does success look like?
“People are overthinking this,” Cherny said. “They’re trying to apply a decade of software engineering principles to a fundamentally different type of system. You can’t treat a model like a database. You have to treat it like a living thing.”
This is where the real competitive advantage will come from. Not from writing better code, but from asking better questions. From designing products that get out of the model’s way. From having the courage to delete everything you’ve built and start over with a blank slate.
The Test That Matters
Cherny has a simple test for any product builder: “If you can’t delete 80% of your system prompts and get the same result, you’re probably adding friction, not value.”
This applies to your product, your workflows, and your prompts. The models are getting smarter exponentially. Every six months, you should be doing a full ablation. Delete everything. See what happens. Then add back only what the model actually needs.
“The people who are winning at this,” Cherny concluded, “are the ones who can forget everything they learned from the old model. They have the courage to re-test things that were impossible six months ago.”
So, here’s the question you need to answer: Are you building a product that unlocks AI’s potential, or are you building a cage that keeps it contained?
FAQ
Q: Is this just about Claude Code, or does it apply to all AI products?
A: It applies to every AI product. The principle is universal: as models become more capable, the product's job shifts from instructing the AI to enabling it. Any product that adds complex workflows or constraints without re-evaluating them for each new model generation is likely hobbling the AI's potential.
Q: So should I just delete all my prompts and hope for the best?
A: No. The key is iterative ablation. Delete everything, run your product, and observe where the model fails. Only add prompts back for the specific failures it repeatedly encounters. The goal is to find the minimum viable instruction set, not to eliminate all guidance.
Q: What if my model is still 'dumb'? This strategy only works for smart models, right?
A: Partially true. This strategy works best with frontier models like Opus 5. However, the principle of 'less is more' still applies to any model. The question is always: 'Is this instruction helping the model perform better, or is it just making me feel more in control?' The answer often reveals more about your own anxiety than the model's needs.