Boris Cherny at YC Startup School: Unhobbling Claude, Deleting Prompts, and Verification

TL;DR

Fresh off the Opus 5 launch, Boris Cherny sat down with Diana Hu at YC Startup School to explain how his team builds Claude Code on top of models that improve every few months. The core thesis: most builders are behind the models, not ahead of them. Claude Code's team deletes most of its system prompt with every model generation and re-earns each line through ablation. The scarce skill is no longer prompt engineering — it's giving the model a slightly-too-hard task and a way to verify its own work. And the frontier is orchestration: dynamic workflows that fan thousands of agents out over multi-week tasks, and routines that quietly maintain entire codebases.

Key takeaways

• Opus 5 runs for days, weeks, even months without scaffolding. No special looping tricks needed — given a task and a verification signal, it keeps going until done.
• Prompt injection is close to a solved problem in their stack. Three layers: an aligned model (years of alignment research), a classifier built on mechanistic interpretability that watches for injection-related activations the model itself won't report, and the auto-mode classifier. Combined, they can no longer demonstrate a working injection.
• Claude Code deleted over 80% of its system prompt for Opus 5. Much of the old prompt was correcting behaviors the model now gets right on its own — smarter models need fewer instructions.
• Prompts are rebuilt by ablation, not intuition. Delete everything, use the product, and only add a line back when the model repeatedly stumbles on the same thing. Every line is a tax paid on every request, so every line must be earned.
• Evals outlive harnesses — but not by much. On the current improvement curve, evals saturate within a couple of model generations and have to be replaced. The constant is the empirical process, not any artifact.
• "Product overhang" is the opportunity. Today's models can already do things no product elicits. Claude Code itself was born by unhobbling Sonnet 3.5 — removing IDE scaffolding and giving the model a terminal when everyone else was doing autocomplete.
• Give the model harder tasks than you think it can handle. Describe the task, guardrails, and exit criteria — then let it run. Overspecifying steps is the most common failure mode, especially among experienced engineers.
• Verification is the single most-missed skill. The pattern behind every impressive result in the talk is the same: a hard goal plus an automatic way for the model to check its own output (test suites, pixel-by-pixel screenshot comparisons).
• Dynamic workflows are a new axis of test-time compute. Claude orchestrates agents in sequence and parallel — an "algebra for agents" — fanning out, verifying, summarizing, and fanning out again across thousands of agents.
• Codebase maintenance is being automated with routines. Anthropic runs 20–30 daily routines per codebase: dead-code cleanup, shipping fully-rolled-out experiments, adding and pruning tests, unifying duplicated abstractions.

Lessons learned

Every prompt line must be earned

The Claude Code team treats the system prompt as a liability, not an asset. With each model release they run ablations — delete the whole prompt, then restore it line by line, measuring the impact of each line like an eval. They found the model is actually slightly more intelligent without most instructions; what remains exists to shape the product experience, not to make the model smarter. There's even an undocumented escape hatch for experimenting: --system-prompt to replace the prompt entirely, and a CLAUDE_CODE_SIMPLE=1-style simple mode that strips prompts from the tools as well.

The same advice applies to users: every six months, delete your CLAUDE.md, your skills, your hooks — and see what the model does before adding anything back.

Treat the model as an empirical science, not a system design

Boris contrasts this with everything he learned in traditional engineering. You don't architect up front and refactor over months; the model is "almost like a living creature" whose personality shifts with every generation. The winning mindset is scientific: try something, observe where it struggles, adjust the harness, repeat. The people who excel are the ones best at discarding their priors — including re-trying things that failed on the previous model.

Verification is the bottleneck

The most concrete, repeatable pattern in the whole conversation: hard task + self-verification = long-running autonomy. The Bun team rewrote their entire JavaScript runtime — over 100,000 lines of Zig — into Rust in an 11-day run (with steering), because Bun's and Node's large test suites gave the model an unambiguous signal for "did I do the right thing." Boris's own experiment rewriting Claude's Electron desktop app in Swift has been running for over two weeks from a short conversational prompt, because the agent screenshots the Electron app in a macOS VM and compares it pixel-by-pixel against the Swift build. Neither prompt was clever. Both had verification built in.

The overhang: today's models exceed today's products

"Product overhang" is the gap between what current models can do and what any product lets them express; "hobbling" is when your product actively gets in the way. Claude Code's origin story is an overhang capture: in the Sonnet 3.5 era, coding products offered autocomplete and read-only chat while the model could already write whole files. The team's bet was simply to remove the scaffolding. Boris's hypothesis is that dozens or hundreds of similar overhangs exist right now — his examples range from whole-codebase language migrations to the accidental discovery that Opus 5 can draw genuinely good portraits with OpenCV, a capability nobody trained for.

Tips & tricks

• Prompt at the level of outcomes. State the task, the guardrails, and the exit criteria. Don't enumerate steps one-two-three-four — that style worked on older models and now actively hurts.
• Always pair a hard task with a verification loop the model can run itself: a test suite, a reference implementation, screenshots to diff, a build that must pass. This is what separates two-week autonomous runs from stalled sessions.
• Ablate your own setup. Periodically delete CLAUDE.md, skills, and hooks; re-add only what the model demonstrably still needs. Use --system-prompt and simple mode to experiment with Claude Code itself.
• Fix failures at the right layer. When the model struggles: better prompting for behavior, a skill for repeatable procedure, an MCP server for missing context.
• Re-throw old problems at new models. The Bun rewrite was a standing test problem that failed on every generation until it suddenly didn't. Keep a list of "too hard" tasks and retry them on each release.
• Use dynamic workflows for one big decomposable task — saying "use a workflow" is enough to trigger orchestration of sequenced and parallel agent stages inside a sandboxed Bun VM. Use loops (local cron) and routines (cloud cron) for repetitive tasks that share memory but not context.
• Automate maintenance with one-sentence routines. Real examples from Anthropic's own repos: daily dead-code deletion via static and dynamic analysis, shipping experiments already at 100% rollout, writing missing tests, deleting useless ones, and an "abstraction police" routine that finds and unifies near-duplicate abstractions across codebases.

Notable moments

• The Bun rewrite. Zig to Rust, 100,000+ lines, one prompt kicking off a dynamic workflow, 11 days of execution with human steering. It shipped: it's the runtime Claude Code runs on today. Boris estimates the same work would have taken engineers well over a year.
• The two-week Slack prompt. Via Claude Tag (Claude in Slack), Boris connected a macOS GitHub runner and an empty repo, then asked for the Electron desktop app rewritten in Swift with pixel-by-pixel screenshot verification — "don't stop until you're done." Still running at interview time, and it spontaneously created a Slack channel to live-blog its own progress with screenshots.
• OpenCV art. An internal viral discovery: ask Opus 5 to draw with OpenCV and it produces good portraits, animals, and landscapes — an untrained capability found by play, not planning.
• On the one weird trick: there isn't one. Boris's advice for becoming a top-1% user was blunt — skip the influencer threads, work empirically, and, as he put it, "don't listen to the LinkedIn influencers."

Chapters

Time	Topic
00:07	What makes Opus 5 different
02:06	Solving prompt injection
03:21	Why Claude Code deleted 80% of its system prompt
06:37	Press delete on your AI product
07:20	How to rebuild your system prompt
10:30	Product overhang and "unhobbling" AI
14:26	Give Claude harder problems
19:32	Prompt engineering is changing
21:57	The two-week Claude Code prompt
24:42	Running thousands of AI agents
30:15	Coding is (almost) solved
32:20	What every CS student should still learn

Caveats & advice for builders

Boris was careful to scope the "coding is solved" claim: it's solved for the kind of coding he does. Deep systems codebases, distributed systems, and fine-grained UI verification (the off-by-one-pixel class of problem) still trip the model up, even with Opus 5's big leap in vision and computer use.

His advice for CS students is shaped by his own path — he learned to program on a TI-83 in middle school, writing a BASIC algebra solver (and later assembly, when calculus demanded a better one). The through-line: programming was always in service of a practical problem. Computer science theory is worth knowing, but the durable, do-it-by-hand skills are the ones around it — design sense, business sense, data literacy, and talking to users. Combine those with engineering and you're building something people want; Diana's summary landed it: make something you want first, then level up to making something people want.