← SnapRecaps

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

► 190,653 views ⏲ 35:51 Watch on YouTube ↗

Summary

Treat frontier models as an empirical science: keep prompts minimal, set tasks slightly beyond capability, and let the model verify its own work to unlock hidden product overhang.

Executive Summary

The video’s core message is that builders should treat frontier models as an empirical science: keep prompts minimal, design tasks slightly harder than the model seems capable of, and let the model verify its own work. Highlights include Opus 5 running autonomously for weeks without scaffolding or a /goal command, achieving unprecedented prompt-injection resistance through layered classifiers, and Claude Code deleting 80% of its system prompt because the new model no longer needed old behavioral corrections. The speaker emphasizes “product overhang”—unlocking capabilities the model already has but current tools block—and shows how a simple harness plus full terminal access let Claude autonomously rewrite Claude Code’s Electron app in Swift over a two-week run, even creating its own Slack status channel. Practical advice: avoid over-specified step-by-step prompts, focus on guardrails and exit criteria, and keep iterating empirically by observing where the model struggles and fixing with better prompting, skills, or MCP context. Above all, verification is the single most important element, enabling self-correction and preventing hallucination during long autonomous tasks.

Key Points

  • ▶ 1:27 Opus 5 can run autonomously for very long periods (days, weeks, even months) without stopping, requiring no scaffolding or /goal command — it simply understands the task.
  • ▶ 2:33 Opus 5 reaches a new frontier in prompt injection resistance, no longer following malicious instructions read from the internet, a major improvement over earlier models.
  • ▶ 3:19 This protection comes from a combination of three layers: a well-aligned model, a prompt injection classifier based on mechanistic interpretability, and an auto mode classifier — together making prompt injection impossible to demonstrate.
  • ▶ 3:39 Claude Code is constantly changing because every model is different, so Claude Code deleted 80% of its system prompt for Opus 5—instructions that corrected for older model behaviors are unnecessary when the new model handles them natively.
  • ▶ 4:34 Users can experiment with minimal prompts via --system-prompt or the undocumented CLAUDE_CODE_SIMPLE=1, which deletes all system prompts; Claude Code uses this as an ablation technique, finding the model is slightly more intelligent without prompts but keeps some for product behavior.
  • ▶ 5:58 The development process is ablation-driven: delete the entire system prompt, then bring it back line by line to measure each line's impact—and the same logic applies to tools and harness code, which is why the team unships tools constantly.
  • ▶ 8:25 Treat building on models as an empirical science: keep prompts minimal (only include instructions the model actually needs) and iterate based on observed behavior instead of designing large, rigid systems up front.

  • ▶ 9:25 Evals are useful but saturate quickly as models improve—so keep appending to your eval set, but be willing to delete old code and system-prompt assumptions and build new evals around the model’s real product failure points.

  • ▶ 10:30 Focus on “unhobbling” today’s model: identify capabilities it already has that the product blocks or hasn’t unlocked (“product overhang”), and keep adapting the product harness as each model generation changes.

  • ▶ 12:54 Claude Code originated from recognizing “product overhang”: the model could already write whole files, but existing coding tools held it back with rigid scaffolding—so they gave it a simple harness and full terminal access.

  • ▶ 13:27 The same un-hobbling opportunity still exists today: modern models have even more untapped capability, and founders can create breakthrough products by eliciting behaviors that current tools fail to surface.

  • ▶ 14:50 Practical founder advice: give models tasks slightly harder than you think they can do, avoid over-specified step-by-step instructions, and instead describe the task, guardrails, and exit criteria—then let the model work.

  • ▶ 15:45 Frontier models can now rewrite essentially any codebase from one language to another; Claude Code's own Bun runtime was rewritten from Zig to Rust in an 11-day workflow with human steering — work that would have taken over a year and is now in production.
  • ▶ 18:17 "Product overhang": keep retrying new models on old business/engineering/product problems, because a newer model may suddenly succeed where previous ones failed.
  • ▶ 19:33 "Model elicitation" — discovering hidden capabilities through playful experimentation (e.g., Opus 5 drawing with OpenCV despite no specific training) — reveals there are likely dozens of undiscovered abilities in today's models.
  • ▶ 20:16 Shift focus from prompt engineering to designing hard tasks and building in verification.
  • ▶ 20:21 Give Claude a task that is intentionally "a little bit too hard" to push beyond routine work.
  • ▶ 20:25 Enable Claude to verify its own work step by step; verification is called "the single most important thing" people get wrong.
  • ▶ 20:36 The section begins with Boris noting the Claude desktop app is Electron-based, and though it was sluggish six months ago, it has become a fast and reliable “pretty awesome experience.”
  • ▶ 20:56 Boris sets up an experiment to see if a native Swift version would feel better, starting a Claude session in Slack and then granting the agent access to a GitHub Mac runner and an empty Swift codebase after initial denials.
  • ▶ 21:33 The core prompt was to rewrite the Electron app in Swift, run both versions in a Mac VM, take screenshots, compare them pixel by pixel, and not stop until the task was done—relying on the agent to handle the complex rewrite and visual verification autonomously.
  • ▶ 21:55 Boris confirms the task was launched with the exact prompt described earlier.
  • ▶ 22:00 The task is still running — Boris reveals at ▶ 22:05 it has been going for a little over 2 weeks.
  • ▶ 22:09 The interviewer polls the audience on 2+ week Claude runs, and at ▶ 22:23 several attendees raise hands.
  • ▶ 22:26 Hallucination is often a process problem: many tasks people think need special scaffolding are tasks the model can already do if allowed to work correctly.
  • ▶ 22:34 The simple approach works now: give the model the task directly without requiring elaborate features like /goal or /loop (these help but aren't essential).
  • ▶ 22:41 Provide a way for the model to verify its own output; this self-correction loop prevents it from getting stuck or drifting into hallucination.
  • ▶ 22:47 Claude autonomously handles a long-running task, continuing to work independently over an extended period.
  • ▶ 22:48 Claude unexpectedly decided to "live blog" its progress by creating a dedicated internal Slack channel.
  • ▶ 22:54 It posted screenshots of its progress every few minutes, proactively building its own transparency and status-update infrastructure.
  • ▶ 23:19 Ignore social media hype—don't listen to LinkedIn influencers or read Twitter.
  • ▶ 23:28 There's no magic trick; work empirically: give the model a task that's too hard, give it tools to verify its work, see where it struggles, then fix it with better prompting, a skill, or an MCP for missing context.
  • ▶ 24:02 People overthink and overengineer because of habits from building complex systems, but the actual approach is simple and iterative.
  • ▶ 24:14 Over-specifying tasks is a common failure mode: telling the model to do a task exactly as you would doesn't align with how models work.
  • ▶ 24:29 Many people are unlearning this habit—it's an ongoing journey.
  • ▶ 24:35 The key shift is treating the model like a coworker, since that's roughly the level of intelligence it operates at.
  • ▶ 24:51 Boris estimates the two-week-running task has spawned thousands to tens of thousands of agents.
  • ▶ 24:57 An audience poll reveals no one has personally spawned over 1,000 agents, showing how rare this scale is.
  • ▶ 25:07 Key insight: the best Claude users design tasks that spawn thousands of agents, creating massive leverage.
  • ▶ 25:23 Dynamic workflows in Claude Code enable massive multi-agent execution; simply telling Claude to "use a workflow" triggers the system.
  • ▶ 25:40 A dynamic workflow runs inside a Bun-based virtual machine, where Claude orchestrates many agents across staged passes—e.g., initial work, verification, then fan-out again.
  • ▶ 26:53 Boris frames this as a new form of test-time compute: instead of scaling training, it orchestrates massive compute during inference to tackle very complex tasks.
  • ▶ 27:41 Loops and routines are a second way to run agents: a loop is a local cron job, while a routine runs in the cloud so it continues even when you close your laptop.
  • ▶ 27:55 Unlike dynamic workflows (one task broken into chunks), a loop/routine is a single repetitive task that does not share context across runs but may share memory.
  • ▶ 28:07 The same repetitive task is performed over and over, potentially on a schedule.
  • ▶ 28:09 Quad has been extended to maintain its own codebase via a dedicated Slack channel, running routines across all codebases (CLI, iOS, Android, desktop).
  • ▶ 28:31 Daily routines include cleaning up dead code (via static and dynamic analysis, opening PRs), shipping completed experiments, writing missing tests, deleting useless tests, and "abstraction police" to unify duplicated abstractions.
  • ▶ 29:39 This runs 20–30 routines daily, involving hundreds to thousands of agents, freeing engineers to focus on shipping new product and user-facing work.
  • ▶ 30:41 Coding is solved only for certain types of work, not all—super deep systems, distributed systems, and pixel-level UI verification remain challenging.
  • ▶ 31:07 Audience poll shows a notable share already writes 50–100% of code via agents, signaling agent-solvable coding is expanding.
  • ▶ 31:42 Exceptional builders use an empirical mindset: forget priors and model expectations, try tasks, observe struggles, and adapt—making coding an empirical science.
  • ▶ 32:13 The speaker highlights that being willing to retry approaches that "didn't work before" and staying open to them is a highly valuable, adaptable skill in the current AI-agent era.
  • ▶ 32:20 The interviewer poses the final question: what should CS students, especially those who learned to program before AI agent coding, still learn the "hard way" through traditional, foundational methods?
  • ▶ 32:41 He learned computer science by self-teaching, always motivated by solving a specific, practical problem he personally faced.
  • ▶ 32:56 His first coding experience was on a TI-83 calculator in middle school, starting with BASIC and writing programs to help him cheat on math tests.
  • ▶ 33:39 When BASIC could no longer handle harder calculus problems, he advanced to learning assembly to build a more powerful solver.
  • ▶ 33:56 Programming has always been practical for Boris, illustrated by building a better solver to “cheat better” on a calculus test.
  • ▶ 34:04 His key advice for students is to learn not just computer science, but how to apply it—through startups, products, design sense, business sense, data science, and talking to users.
  • ▶ 34:28 Combining these practical, product, and business skills with computer science becomes “really, really valuable” and is what he would still focus on.
  • ▶ 34:38 Start by building something you genuinely want or need for yourself.
  • ▶ 34:41 Then level up to make something people want, expanding from personal value to broader appeal.
  • ▶ 34:53 Everyone present receives Max 20X, sparking loud cheering and laughter.
  • ▶ 35:15 Attendees are told to look for a code in their email, with the speaker adding, "I can't wait to see you what you build."
  • ▶ 35:22 A second speaker confirms the email will be sent, as the announcement ends with more applause.
  • ▶ 35:31 The speaker challenges the audience to use the new account access to build an ambitious system, specifically one running for "hopefully multiple months" with "thousands of agents."
  • ▶ 35:39 The speaker thanks guest Forrest ("thank you so much, Forrest"), with Forrest replying "Thank you" at ▶ 35:43.
  • ▶ 35:44 The segment closes with cheering and applause from the audience as the conversation concludes.

Video Sections

  • ▶ 0:04 Introduction and Opus 5 Capabilities (0:04 - 3:22) - - Host welcomes Boris; Opus 5 introduces long-running autonomy and prompt injection resistance.
  • ▶ 3:22 System Prompt Reduction and Ablation-Driven Development (3:22 - 8:27) - - Claude Code's system prompt is cut by 80%, with custom prompts and ablation guiding iterative rebuilding.
  • ▶ 8:27 Building on Models, Evals, and Unhobbling Claude (8:27 - 12:29) - - Comparing model-based development to engineering, using evals, and reducing product overhang by unhobbling Claude.
  • ▶ 12:29 Claude Code's Origin and Founder Opportunity (12:29 - 15:36) - - From auto-complete to full-file generation, product overhang, and advice to give models harder, higher-level tasks.
  • ▶ 15:36 Model Elicitation and Harder Real-World Tasks (15:36 - 20:21) - - Rewriting codebases and apps, fuzzing for bugs, and experimenting to discover hidden model capabilities.
  • ▶ 20:21 Verification, Long-Running Tasks, and Agent Workflows (20:21 - 35:50) - - Verification-first coding, the Electron-to-Swift rewrite, spawning agents, and dynamic workflows for codebase maintenance.

Exact Transcript

Load the full timestamped transcript on demand and click any time to jump in the video.