Y Combinator · Startup School 2026

Boris Cherny: Building Claude Code

How Claude Code's creator thinks about building on accelerating AI — delete your system prompt, give models harder problems, and let verification do the rest.

Y Combinator · 35 min · brief by The Daily Read · Jul 27 2026

Min Runtime

10.9K

Views

524

Likes

80%

Prompt Cut

Tap a timestamp pill below to jump the video to that moment.

The problem

The products we build are hobbling the models we already have

The morning before Startup School 2026, Anthropic shipped Opus 5. It hit 30% on ARC-AGI-3 — a benchmark previously topping out in the low teens. In Claude Code's auto mode, it can run for weeks without any scaffolding. And it is, Boris Cherny says, essentially no longer prompt-injectable: a mechanistic interpretability classifier watches the literal neurons that fire during a prompt-injection attempt, catches it before the model even has to refuse, and the attack stops working. The capability curve is steep, and it is not flattening.

Yet most products built on these models are stuck in patterns designed for much weaker ones. Cherny — fresh off shipping Opus 5 and speaking at Startup School as the creator of Claude Code — names the gap: product overhang. The idea is that today's models can already do things that current products don't let them do. The model is capable of rewriting codebases, running for weeks, and verifying its own output without constant human checkpoints. Most harnesses get in the way.

hobbling is this idea in research: the model is doing something and you're just getting in the way...

heard you describe how to build the best agentic products on top of a cloud is this concept of a unhobling cloud and tell us more more about what that means. >> Yeah, so hobbling is this idea in a research that the model is doing something and you're just getting in the way. There there's this kind of like way of thinking about it that I really like. It's very useful when you're building product and it it's called product overhang and the idea is the model is able to do all sorts of things with today's models not a future model but today's model that we have not yet realized and there are so many capabilities the model has like this that people are not aware of and this is like the ability to you know like maybe use use a particular tool, use a particular language, solve a particular kind of problem, do things a particular kind of way that we thought

The other side of product overhang is “hobbling” — when scaffolding, over-specified prompts, and rigid instructions actively prevent the model from expressing what it can already do. Cherny's thesis: the biggest unlock in AI product development right now isn't a new model capability. It's removing the constraints that stop existing models from doing what they already have.

How they solve it

Delete first. Add back only what the model demonstrably needs.

Every time a new Claude ships, the Claude Code team runs a full ablation of the system prompt: delete everything, restore it line by line, measure the effect of each line. For Opus 5, they ended up removing over 80% of what was there. “A lot of the stuff in the system prompt was correcting for behaviors the model should have known but didn't. Now Opus 5 just does it.” The same method applies to tools: unchip them, run without, restore selectively. The goal is to never instruct the model to do something it would have done on its own.

Over 80% of the Claude Code system prompt — deleted. Here's why.

>> Talking about a prompt injection, the other side of the coin is now the system prompt. Let's talk a bit about the new release. You actually deleted over 80% of the system prompt from clock code. >> Yes. >> Tell us more about that. >> I think something that a lot of people might not realize is Claude Code as a product and as a harness is just always changing. We're always adding stuff. We're always deleting stuff. Every time that a new model comes out, we delete a bunch of the system prompt. Change a bunch of the system prompt. We change the set of tools all the time. We change the prompts for the tools all the time. And the reason is every model is very different. So something that you did for one model maybe three months ago, it just might not translate at all to the next model. And so one thing about Opus 5 is it's just really intelligent. And a lot of the stuff in the system prompt

The same principle scales to how you give instructions. Don't enumerate steps — describe the task, define the exit criteria, set the guardrails, then step back. The single most important design decision for any long-running agentic task, Cherny argues, is giving the model a way to verify its own work. When verification is built in, the model doesn't get stuck: it checks, corrects, and continues. “That's kind of it. I think people tend to overthink it a little.”

The evidence is concrete. The team behind Bun — the JavaScript runtime Claude Code now uses, originally written in Zig — asked Claude to rewrite the entire runtime in Rust. One prompt. A dynamic workflow. Eleven days of running. Previous models couldn't do this even with steering. Now it's in production. Cherny himself has a separate Claude Tag session running for over two weeks: rewriting Claude's Electron desktop app in native Swift, comparing screenshots pixel by pixel, live-blogging progress to a Slack channel, never stopping.

Still running. Two weeks. One prompt. No fancy scaffolding.

>> And how long did this take to run? >> It's still running. When did you start it? >> It's been it's been a little over two weeks. So, it's like 14 days, 15 days. >> Yeah. So, I don't know if anyone in the audience has gotten clock to run a a task for more than two weeks. >> I don't know. Raise your hand. Anyone in the audience? >> Oh, >> all right. Some some >> this this is like one of these this is about elicitation. So, so this is really one of those examples where the model can do it today. You just have to let it do it. And you don't need the fancy stuff. You don't need slashgo. You don't need sloop. These help, but really all you need is give the model the task. Give it a way to verify the output of its work so it doesn't get stuck and it'll just go. And actually, in this case, Quad also decided to live blog it. So, what it did is it created a Slack channel internally, and it started just posting screenshots every few minutes of its progress.

At the team level, Anthropic now runs 20–30 daily “routines” across its apps — cron-like jobs where Claude maintains its own codebases. One finds and deletes dead code. Another ships experiments that hit 100% rollout and removes the flag. Another writes test coverage for undertested paths. One Cherny particularly loves: “abstraction police” — Claude scans all repos daily for near-duplicate abstractions and files a PR to unify them. Hundreds to thousands of agents run every day, doing work that previously required dozens of engineers, freeing the humans to ship new products and talk to users.

Takeaway

The quick version

Delete your system prompt when a new model ships — every line you keep costs an instruction the model reads every time it runs. Add back only what you observe the model needing, not what you think it needs.
Give harder tasks than you think the model can handle. Describe what done looks like; skip the step-by-step. Modern models resist over-specification.
Verification is the unlock for long-running tasks. A model that can check its own output doesn't get stuck — it keeps going. Build in a way for it to confirm the work is correct.
Treat AI products empirically, not theoretically. Try it. Watch where it stumbles. Adjust. Forget what worked on the last model.

“The way to think about it is almost like a living creature — something more organic. Every model generation it behaves differently, it has a slightly different personality, and you have to take the time to get to know it and then adjust the harness based on that.”— Boris Cherny, Y Combinator Startup School 2026

The Zig-to-Rust rewrite that ran for eleven days and the Swift port still ticking at two weeks are not demos. They are dispatches from a world where the biggest opportunity in software is the gap between what models can already do and what the products you build actually let them.