By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

Boris Cherny: We Cut 80% of Claude Code’s Prompt

Fresh off the launch of Opus 5, Claude Code creator Boris Cherny joins Diana Hu at Startup School 2026 to talk about what the newest models can do, how Claude Code came to be, and what it means to build products when the underlying…

Diana HuhostBoris Chernyguest

Jul 27, 202635mWatch on YouTube

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

CHAPTERS

Jump to publisher timestamps

Chapter summaries

Opus 5’s standout capability: sustained long-running work without extra scaffolding
Diana Hu opens by asking what Opus 5 can do that earlier versions couldn’t. Boris Cherny describes how new model training yields a mix of intended and surprising emergent skills, then highlights Opus 5’s ability to persist on tasks for extremely long durations, especially with Auto Mode.
- •Model training attempts many skills; only some reliably stick, and some capabilities emerge unexpectedly
- •Opus 5 can continue working for very long periods without stopping
- •Auto Mode combined with Opus 5 enables unusually persistent execution
- •Reduced need for extra task scaffolding or special prompting tricks to keep it going
Why prompt injection is harder now: alignment + classifier layers
Boris explains what prompt injection is and why it used to be dangerous when models encountered malicious instructions online. He then outlines a layered approach that makes prompt injection difficult to demonstrate with Opus 5.
- •Prompt injection: the model following hostile instructions found in external content
- •Boris says older models might have complied with harmful instructions; newer ones resist
- •Defense stack includes a well-aligned model plus a prompt-injection classifier run on all traffic
- •Classifier approach draws on mechanistic interpretability work by identifying activation patterns
- •Additional classification layer via Auto Mode contributes to preventing prompt injection
Claude Code deleted 80% of its system prompt: adapting the harness per model generation
Diana brings up that Claude Code removed over 80% of its system prompt. Boris explains that Claude Code’s harness, tools, and prompts are continuously revised because each model behaves differently, and Opus 5 no longer needs many corrective instructions.
- •Claude Code’s system prompt and tool prompts are frequently changed as models change
- •Many older instructions existed to correct behaviors earlier models didn’t naturally do
- •Opus 5 performs well enough that much of that prompt became unnecessary
- •Boris notes you can experiment by setting a custom system prompt when running Claude Code
Simple Mode and prompt ablations: finding what prompts truly help vs. hurt
Boris describes an undocumented “Simple Mode” that removes system prompts, including tool prompts, to test what’s actually providing value. He says they use this ablation approach to measure prompt impact and have found the model can be more intelligent without extra prompting, even if product usability sometimes benefits from it.
- •Simple Mode removes system prompts (including tool prompts) for experimentation
- •Ablations are used to evaluate whether each prompt line is actually useful
- •Boris reports the model can appear more intelligent with fewer prompts
- •Some prompts remain helpful for product experience and predictable user-facing behavior
“Press delete” as a development philosophy: rebuild prompts and tools from empirical evidence
Diana asks whether everyone building agentic products should be brave enough to repeatedly delete and rebuild. Boris strongly agrees, suggesting even individual users periodically delete their accumulated instructions and see what the newest model can do.
- •Boris endorses regularly deleting and rebuilding prompts as models evolve
- •He recommends users periodically delete Claude.md, skills, and hooks to reassess necessity
- •Team practice: remove the full system prompt, then restore line-by-line based on measurable impact
- •Claude Code also frequently ships/unships tools and removes harness code that no longer helps
How to rebuild a system prompt: start minimal, observe failures, add only what repeats
Boris lays out a step-by-step approach: delete first, then run the product and watch where the model reliably stumbles. Only after repeated failures should instructions be reintroduced, because every added instruction becomes recurring overhead and may not be needed.
- •Delete first, then use the model/product before adding new instructions
- •Don’t guess what the model needs; observe real failures in actual usage
- •Add prompt lines back only after repeated, consistent stumbling points
- •Every prompt instruction is reread each time, so unnecessary lines impose ongoing cost
- •Boris frames model work as empirical and iterative rather than upfront system design
What stays stable (and what doesn’t): evals help, but they also saturate quickly
Diana asks what remains stable across model releases and whether evals carry over. Boris says evals can persist longer than the harness, but rapid improvement often saturates them, forcing teams to discard old evals and create new ones based on fresh observed failure modes.
- •Evals can persist across model generations, but not indefinitely
- •Rapid model gains often saturate existing evals, making them obsolete
- •Teams must build new evals from where the current model struggles in real use
- •Emphasis remains on empiricism: use the product, find failures, then codify them into evals
Product overhang and “unhobbling”: when the product limits what the model can already do
Boris introduces “hobbling” as the product getting in the model’s way, and “product overhang” as unrealized capability that exists in current models but isn’t expressed due to inadequate product design. He recounts early Claude Code motivation: remove restrictive scaffolding so the model could write larger chunks of code than existing tools allowed.
- •Product overhang: models can do more than products currently let them express
- •Hobbling: design choices that block or constrain model capability
- •Early coding tools focused on autocomplete or read-only chat instead of full write workflows
- •Claude Code aimed to remove friction so the model could write larger units like files/features
- •Boris sees many commercially valuable opportunities still uncaptured by current products
Give models harder tasks and higher-level goals: stop overspecifying step-by-step instructions
Boris suggests a key tactic for elicitation: assign tasks that are slightly harder than what you think the model can do, and avoid overly detailed procedural micromanagement. He argues modern models respond better to high-level goals with guardrails and clear completion criteria, then room to execute.
- •A common mistake is giving overly specific, step-by-step instructions
- •Boris recommends describing the task, guardrails, and exit criteria instead
- •He says this approach works better with modern models than it would have months earlier
- •Encouragement to let the model run and check back after it progresses
Example of new capability: rewriting a large codebase across languages via long-running orchestration
Boris gives a concrete example: rewriting a codebase from one language to another, framed as something that now seems feasible with recent models. He describes a workflow where tests help validate correctness and a long-running, orchestrated effort rewrote a large codebase over many days with steering.
- •Models can now rewrite substantial codebases from one language to another
- •A strong test suite provides a way to validate correctness while rewriting
- •Boris describes a long-running job using a single prompt plus steering
- •Dynamic workflows are described as enabling orchestration of many agents over extended time
- •He contrasts feasibility now versus previous models that couldn’t complete the task even with guidance
Play and experiment to discover hidden capabilities: creative elicitation beyond obvious use cases
Boris argues that experimentation can reveal surprising abilities that weren’t explicitly trained as primary features. He cites an internal viral example of getting the model to draw using OpenCV, framing it as evidence of a large “solicitation gap” and many undiscovered opportunities.
- •Experimentation uncovers capabilities not obvious from standard usage
- •Boris describes giving the model OpenCV and asking it to draw images
- •He says this worked well despite not training the model specifically to draw
- •Hypothesis that many similar opportunities exist but haven’t been discovered yet
Prompt engineering is shifting toward verification: enabling the model to check its work
Asked about prompt engineering’s future, Boris says the critical skill is increasingly about giving hard tasks and building in verification so the model can confirm progress and avoid getting stuck. He shares an ongoing experiment: directing Claude to rewrite an app while continuously comparing outputs via screenshots and pixel-level checks.
- •Skill shift: less about clever prompts, more about hard tasks plus verification
- •Verification is described as the most common missing ingredient in real usage
- •Boris describes an ongoing multi-week task to rewrite an app and compare outputs visually
- •He emphasizes that elaborate prompting tricks aren’t required if verification is built in
- •The model can continue autonomously when it has clear goals and ways to validate progress
Scaling up to thousands of agents: dynamic workflows, loops, and routines for orchestration and maintenance
Diana asks how tasks end up spawning thousands of agents. Boris explains dynamic workflows as a way to orchestrate many agents in stages, and contrasts them with loops and routines for recurring work; he then describes using routines to maintain multiple codebases with daily automated pull requests.
- •Dynamic workflows: orchestrate agents in stages (fan out, verify/summarize, fan out again)
- •Boris frames this as a new way to scale test-time compute via orchestration
- •Loops and routines: repetitive jobs that can run locally or in the cloud without keeping a laptop open
- •He describes Claude running many daily routines to maintain several apps and codebases
- •Examples include dead code cleanup, removing completed experiments, adding/removing tests, and unifying duplicated abstractions
Is coding solved—and what should CS students still learn? Empiricism plus practical product skills
Boris qualifies that “coding is solved” mainly for the kinds of coding he does, noting areas where the model still struggles. He then explains what differentiates top users—an empirical mindset and willingness to drop stale assumptions—and closes with what CS students should still learn: applying CS to practical problem-solving and building real products with broader skills.
- •Boris says coding is “solved” for his work type but not for all domains and edge cases
- •He emphasizes empiricism: try tasks, observe failures, and adapt rather than rely on priors
- •He notes a common failure mode is overspecifying to force the model to work like a human would
- •For students: learn CS in a practical way by solving real problems
- •He stresses complementary skills like building products, design sense, business sense, data work, and talking to users

Publisher timestamps

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.