Boris Cherny: We Cut 80% of Claude Code's Prompt (Category AI4SDLC)
I watched a talk by Boris Cherny, the creator of Claude Code, at Y Combinator Startup School 2026, recorded the day after the release of Opus 5. I have already covered his interview on the Lightcone podcast, as well as the inner workings of Claude Code. The main point here is the product philosophy: for the new model generation, the team removed more than 80% of the system prompt, with no measurable loss of quality on their coding evals, according to Boris.
The logic is that a system prompt consists largely of patches accumulated around the mistakes of a particular model generation. A new model no longer makes those mistakes, while old instructions and examples begin to constrain it: “you are supposed to answer like this,” so the model obediently imitates an outdated example. The team's methodology is therefore strict: with every model release, the prompt is stripped almost to zero, and lines are restored only when the model repeatedly stumbles over the same issue. Boris says there is even a CLAUDE_CODE_SIMPLE=1 flag that removes every prompt, including those embedded in tools; in that “bare” mode, the model measures as slightly more capable. The same applies to evals: they become saturated after one to three model generations and then have to be rebuilt.
From a product perspective, I liked the term product overhang: a model has capabilities that the product fails to expose because the product itself stands in the way. Claude Code emerged from exactly this observation. Sonnet 3.5 could already write complete files and features, while the surrounding products offered autocomplete and read-only chat. The value of a harness, then, lies not in what it adds on top of the model but in what it does not obstruct — a good echo of the harness factory model from The New SDLC, which I previously covered.
On skills, Boris describes a shift from prompt engineering through context engineering to elicitation: the ability to give a model a task that is “slightly harder than seems possible,” plus a verification mechanism, without overspecifying the solution. The formula is the same as with a strong colleague: the task, constraints, and definition of done. This looks amusing next to the book Prompt Engineering for LLMs: in a year and a half, the discipline has moved from “how to write instructions correctly” to “how to delete them correctly.” It also aligns with Anthropic's research on expertise: success with an agent depends on the ability to define the task and verify the result, not on magic wording.
Two stories, both recounted by Boris, illustrate the scale. The Bun team used Claude to rewrite more than 100,000 lines of runtime code from Zig to Rust in 11 days of continuous work, a job that would have taken people more than a year. Meanwhile, his own experiment rewriting an Electron application in native Swift had entered its third week by the time of the talk, with thousands of spawned agents — and Claude had created its own Slack channel where it posted progress screenshots.
My main conclusion is that the system prompt and CLAUDE.md are technical debt with a shelf life of one model generation. Instructions accumulated for the previous model turn from supports into constraints for the next one, so “press delete” is not a gesture of bravery but a routine engineering procedure, like cleaning up dependencies.
P.S. In general, if you have ~~unlimited~~ access to SOTA models, you need less and less imperative control over the execution flow or to force the model into a rigid framework. Instead, you move toward classic inversion of control (IoC), where the model follows the “Hollywood principle” (“don't call us, we'll call you”): low-level modules do not directly invoke the high-level module, which here is the model. The model itself controls the calls and invokes the available modules whenever it needs them.
#AI4SDLC #AI #Agents #Evals #DevTools #Engineering