On July 25, 2026, Boris Cherny - head of Claude Code team at Anthropic - was intervirewd in front of packed audience at YC Startup School. Please look at 30 ideas from his speech.

1. Opus 5 can no longer be prompt injected, and three layers make that true

A year ago a web page could hide an instruction in its text, tell the model to delete everything on the user's computer, and the model would do it. That risk, which people named the lethal trifecta, shaped how every harness and agent product got designed. Opus 5 refuses. Boris says three layers make the refusal hold. First, the model itself, after three years of alignment research. Second, a prompt injection classifier that runs on all traffic, built on Chris Olah's interpretability work, watching the neurons that light up when an injection lands. The model will not tell you it happened, but those neurons will. Third, the auto mode classifier. With all three running, Boris says Anthropic can no longer demonstrate a working prompt injection at all.

2. Anthropic deleted 80 percent of the Claude Code system prompt

Claude Code changes constantly, and every model release starts another round of cutting. Prompts go, tools go, tool descriptions get rewritten. With Opus 5, 80 percent of the system prompt went. The reason is plain. Most of those lines patched behaviour the model should have known but did not. Opus 5 knows it, so the patch became dead weight that the model reads on every single turn. Boris adds that you can go further yourself. Claude Code takes a flag that lets you replace the system prompt with whatever text you want, which is an odd amount of rope for a vendor to hand out.

3. An undocumented simple mode strips every prompt, and the model gets slightly smarter

One environment variable starts Claude Code with no system prompts at all, including the ones attached to the tools. Anthropic built the switch as an ablation tool, a way to ask whether the prompts still earn their keep. The answer is uncomfortable: "the model is actually a little bit more intelligent without these prompts." Boris still defends keeping some of them, because a product has to behave in a way that makes sense to the person using it, and prompts are how you get that behaviour. Raw intelligence and good product manners are not the same target, and he is choosing the second one on purpose.

4. Delete your CLAUDE.md, your skills and your hooks every six months

His advice to the room was blunt. Twice a year, delete all three, then use the thing and watch what happens. He expects it to surprise people. Most of what sits in those files was written for a model that no longer exists, to fix problems that no longer occur, and it now costs attention on every run. For Opus 5 he says Anthropic really does recommend trying this. Worth pausing on that: the vendor is telling you to throw away the configuration files its own users spent months tuning, because the model probably does not need them.

5. Ablation is the method: erase the whole prompt, then restore it line by line

Merriam-Webster defines ablation as "the process of ablating: such as a: surgical removal b: loss of a part (such as ice from a glacier or the outside of a nose cone) by melting or vaporization". The word comes from Middle English ablacioun, meaning removal, and English has used it since the 15th century. Research borrowed it for the same gesture: take a piece away, then see what stops working.

Applied to prompts, ablation means deleting the entire system prompt and bringing it back one line at a time, measuring what each line actually does. Boris describes it as a kind of eval run backwards, where you learn by subtraction instead of by addition. Anthropic does the same with tools, unshipping them to find out which ones the model needed in the first place.

6. Never guess what instruction the model needs, wait until it fails twice

The temptation after deleting is to sit down and rewrite from imagination. Boris says do not, because you will predict the wrong things. The order is delete, then use. Run your product, or run Claude Code against your own code base, and pay attention. Note where it works well and where it trips over your architecture. Only when the same stumble repeats do you write a line to fix it. His reasoning is economic rather than aesthetic. The model reads that instruction every single time you use it, so it has to be worth what it costs.

7. Almost all code left in the harness is safety, permissions and static analysis

Strip the scaffolding out over two years and something telling remains. Boris says nearly all the code in Claude Code today handles safety, permissions and static analysis, plus a body of interface code. The clever machinery that once coaxed capability out of weaker models has been unshipped. Tools get removed as routinely as they get added. Anyone expecting the best harness in the world to be an elaborate construction will be disappointed: it is mostly guardrails and a good screen, wrapped around a model that no longer needs to be led by the hand.

8. Evals die too, most survive only one to three model generations

Boris pushes back when asked whether evals are the stable asset you carry forward. They outlive the harness, he says, but not by much. One model generation, sometimes two or three, then the model saturates the test and the test tells you nothing. So you throw it away and write another. The method for writing the new one is the method for everything else here: use the product, watch the model struggle, build the eval from what you saw. On an exponential, even your measuring instruments are disposable.

9. The model is a living creature, not a system you design up front

Boris spent years on the other kind of engineering, where you think through the system design first, write a large suite of unit tests, and treat a re-architecture as a project of many months. At big companies he watched some run for years. Models break that habit completely. Every generation behaves differently and arrives with a slightly different personality, so the work is to spend time getting to know it and then shape the harness around what you find. He calls the model closer to a living creature than a system, something organic, and the discipline around it scientific rather than architectural.

10. Hobbling and product overhang are two sides of the same mistake

Merriam-Webster gives hobble as a verb meaning "to move along unsteadily or with difficulty", and transitively "to fasten together the legs of (an animal, such as a horse) to prevent straying: fetter" or "to place under handicap: hamper, impede". The noun includes "something used to hobble an animal". English has had the word since the 14th century.

That picture carries the whole idea. Hobbling is what a product does to a model when it ties the animal's legs together and then reports that the animal cannot run. Product overhang is the other half: abilities the model already has, in the version shipped today, that no product yet asks for. Boris calls them two sides of the same thing. Both come from not looking closely at what the model can already do.

11. Claude Code exists because someone unhobbled Sonnet 3.5

Sonnet 3.5 was, at the time, the best coding model that existed. Now look at what coding products did with it. Single line autocomplete, sometimes multi-line, which counted as a new idea. Chat with read access only, so you could ask about your code base but it could not touch anything. Boris read that as a gap. Nothing on the market was eliciting the model's real ability, which was writing whole functions and whole files. Claude Code began from one question: what if you removed the scaffolding and gave the model the simplest harness possible, a terminal, and let it write? That was the overhang, and closing it produced the product.

12. Give the model a task slightly harder than you think it can do

The mistake Boris sees most often is people being too careful. They hand the model small work with detailed instructions, one then two then three then four, and they get what they asked for. His fix is deliberate overreach: aim just past what you believe is possible. He is explicit that this is new advice, because six months ago it would have failed. Today it works, and the outcome tends to surprise whoever set the task. The uncomfortable corollary is that your sense of the model's ceiling is probably a memory of a model that has been retired.

13. Describe the task, the guardrails and the exit criteria, then let it cook

Rather than sequencing the implementation, Boris names three things worth writing down. What the task is. What the guardrails are. What counts as finished. Then you leave, let the model work, and come back later. The numbered march through steps is a habit formed with weaker models, and it now costs you quality. Notice that the exit criteria carry as much weight as the task itself. A model that cannot tell when it is done will either stop too early or run past the point of usefulness, and with the current generation the second failure has become the more likely one.

14. Over-specifying is the failure mode of engineers with decades of practice

Boris singles out a particular group, and it is not beginners. Engineers who have been coding for years or decades over-specify. They want the task done exactly the way they would have done it, because that is what building systems demanded for their whole careers. Now the habit works against them. He is generous about the fix, calling it a journey and an act of unlearning, since nobody drops twenty years of practice in an afternoon. The direction of travel is towards treating the model as a colleague rather than as a compiler that needs precise input.

15. Bun was rewritten from Zig to Rust in 11 days, from one prompt

Bun is the JavaScript runtime that Claude Code runs on, a faster alternative to Node, and it was written in Zig. Zig makes you manage memory by hand, so leaks come easily. The Bun team had been using Claude to fuzz the code base and hunt those leaks one at a time, which was the ceiling of what models could do then. At some point Jared on the team decided to try the bigger version, a test problem he threw at each new model generation. Starting with Fable, the model could handle it. He defined a test suite, wrote one prompt, ran it as a dynamic workflow, and 11 days later the code base existed in Rust. That version ships in production today.

16. The same rewrite would have taken a human team over a year

Put numbers on it. The job covered over 100,000 lines of a JavaScript runtime, which is a seriously complicated piece of software, moved between two systems languages. Boris estimates the human cost at definitely over a year. Two details keep the story honest. It was not one shot, because there was steering along the way. And earlier models failed at it even with that steering, so the difference between then and now is capability rather than patience. The reason it was checkable at all is that Bun and Node both carry large test suites.

17. Verification is the one thing almost nobody gets right

Of everything in the conversation, this is the point Boris presses hardest. Verification is the single most important thing people do not get right, and he says virtually nobody does. The logic is simple. A model that can check its own work keeps going, because it always knows whether it is closer to done. A model that cannot check its work gets stuck, and no amount of prompt polish will rescue it. Every example he gives contains a checking loop. The Rust rewrite had a test suite. The Swift rewrite compares screenshots pixel by pixel. Ask yourself what your model would use, and if the answer is nothing, that is the bug.

18. A Swift rewrite of the desktop app has been running for more than two weeks

The prompt was roughly this. Rewrite the Electron app in Swift. Run the Electron version in the Mac virtual machine, screenshot it, compare it pixel by pixel with the Swift version. Do not stop until you are done. Getting there took two small favours first: Boris asked whether the session had a macOS runner on GitHub, and access to an empty repository, and gave it both when the answer was no. He ran the whole thing in Claude in Slack. At the time of the interview it had been going for over two weeks and had not finished. Asked whether anyone in the audience had run a task that long, a few hands went up.

19. Claude opened its own Slack channel and live blogged its progress

Nobody asked for this part. Somewhere inside the Swift rewrite, Claude created an internal Slack channel and started posting screenshots of its own progress every few minutes. Boris mentions it almost in passing, which is the interesting thing about it. The behaviour was not prompted, not designed, and not the sort of feature anyone would have written a specification for. It supports his larger claim: what matters is rarely what you specify, it is what the model does once you give it room, a long horizon, and a way to check itself.

20. Do not listen to LinkedIn influencers, there is no one weird trick

Asked what separates the top one percent of Claude Code users, Boris answered: maybe don't listen to the LinkedIn influencers. Everyone hunts the secret setting, the magic phrase, the configuration that unlocks everything. It does not exist. What exists is a loop. Give the model a task that is slightly too hard. Give it the means to verify its work, the same means you would want if you were doing the job yourself. Watch where it struggles. Then fix that struggle, with better prompting, or a skill, or an MCP if the real problem is missing context. He says people overthink it, and over-engineer out of habit.

21. Opus 5 draws portraits with OpenCV, and nobody taught it to draw

For a couple of weeks this went viral inside Anthropic. Someone worked out that if you hand Opus 5 OpenCV and ask it to draw an image, it draws. Portraits come out well. So do animals, and so do landscapes. The model was never trained to draw anything. The ability sits there and appears only if you ask the right way, which is what elicitation means in practice. Boris is careful about how it was found. Somebody was playing, trying creative things with no direct commercial application, which is exactly the activity that gets cut first when a team is busy.

22. Hundreds of capabilities exist today that no product has yet asked for

From the drawing trick Boris draws a general claim, and it is the most useful sentence in the interview for anyone building. His hypothesis is that dozens or hundreds of openings like it sit inside the models we already have, unclaimed. He is precise about the timeframe: today's models, not a future release, not the thing arriving next quarter. He also says he is not seeing startups capture this, and calls the openings amazing, interesting and "commercially valuable". If he is right, the binding constraint on a lot of products right now is imagination rather than capability, which is a harder problem to buy your way out of.

23. Dynamic workflows are a new form of test time compute

Model intelligence used to scale on three inputs: the size of the neural net, the volume of training data, and the flops spent on training. Then the field added test time compute, which Boris translates as a fancy researcher's way of asking how many tokens the model generates while working. Dynamic workflows, he argues, are a new way to organise that compute and to raise how much of it you can usefully spend on one hard problem. Triggering one takes three words: use a workflow. Claude then starts a virtual machine inside the Bun sandbox and orchestrates agents in it. He notes that almost nobody has written about this yet.

24. Agent orchestration is an algebra, with sequence and parallel as its operators

Boris came from functional programming, and the design shows it. There is a way to run agents in sequence, a way to run them in parallel, and Claude has tools for combining the two inside the sandbox. He calls it an algebra for agents. In practice a hard job unfolds in waves. A first set of agents makes a pass. A second set verifies or summarises what came back. A third fans out again from there. The structure exists to spend tokens efficiently on work that might otherwise stretch across multiple stages and dozens of pull requests.

25. Claude now maintains its own code bases through 20 to 30 daily routines

Anthropic has Claude maintaining its own products. Routines run in the cloud on a schedule, so nobody keeps a laptop open, and they cover the CLI, the iOS app, the Android app and the desktop app. Twenty or thirty run every day, and each one is a single sentence. One hunts dead code across every repository using static and dynamic analysis, then files a request to remove it. Another finds experiments already rolled out to everyone and ships them properly, deleting the flag. A third writes tests for thin areas of coverage. A fourth deletes tests that older models or old habits left behind, which nobody needs and everybody keeps running.

26. The abstraction police routine hunts duplicate abstractions every day

This is the routine Boris says he loves, and it is the one that shows what a scheduled agent can do that a person cannot. In a large code base the same abstraction quietly gets built more than once, in different corners, at different times, by people who never saw each other's version. Squint and they are the same thing. Nobody ever merges them, because noticing requires holding the whole repository in your head at once. The routine he calls the abstraction police does that every day, across all their code bases, finds the near duplicates and unifies them. He adds a detail worth catching: nobody told the dead code routine to use static and dynamic analysis. It worked that out on its own.

27. These routines do the work of dozens or hundreds of engineers

The scale is hundreds of agents a day, sometimes thousands. Boris measures the output in people rather than tokens: this is the work of dozens or hundreds of engineers, the maintenance load that used to consume entire teams. He is honest that they are not fully there yet, while saying the path leads to automating app maintenance completely. The second effect is the one he cares about. Engineers stop doing the janitorial work and go back to shipping product and talking to users, which is the part of the job they wanted in the first place.

28. Coding is solved, but only for the kind of coding Boris does

He has said publicly that coding is solved, and here he narrows the claim himself. Solved for the coding he does, not for everyone. Deep systems code still defeats Claude. Distributed systems do too. So does close visual work, where an element sits a pixel off and the model cannot see it, although Opus 5 made a large jump in vision and computer use. He then polled the room instead of arguing. Some hands went up for writing no code by hand at all, and slightly fewer for more than half. His reading of that show of hands: it is getting there, for more and more kinds of code.

29. Treat the model like a coworker, because that is the intelligence level now

What has changed is the register of the conversation rather than any technique. You brief the model, you do not program it. Boris ties the phrase directly to capability: treat it like a coworker, because that is the level of intelligence it is at now. The advice explains everything else he says. You would not hand a competent colleague a numbered list of implementation steps and insist they follow your exact path. You would describe the goal, agree how you will both know it worked, hand over what they need, and let them work.

30. Forget your computer science theory and become an empiricist

Forget what past models could not do. Forget the theory from the classroom, which Boris grants is intellectually fascinating and worth knowing separately. Look at what this model does on a real task, find where it struggles, adjust, repeat. He frames the shift plainly: this stopped being a theoretical science and became an empirical one. The people who do best are the ones quickest to drop a prior, including the belief that because an idea failed before, it will fail again. Two of his three best examples exist only because somebody retried something that had not worked.

Sources: Merriam-Webster, "ablation", Merriam-Webster, "hobble"