Boris Cherny: Building Claude Code
In a Nutshell
Boris Cherny explains how Opus 5 enables long-running autonomous agents and massive test-time compute through dynamic workflows that orchestrate thousands of agents across sequential and parallel stages. The key insight is that current models possess far more capability than products expose—unhobbling requires giving models harder tasks with verification tools rather than over-specifying instructions, and deleting accumulated constraints every 6 months. Self-maintaining codebases are now possible through 20-30 daily routines that handle dead code cleanup, experiment removal, test generation, and abstraction unification across all codebases.
These notes were generated by AI and may contain inaccuracies.
Boris Cherny, creator of Claude Code, joined for a discussion fresh off the Opus 5 release. The model achieved 30% on Arc AGI 3, representing a significant jump from previous low single digits or low teens scores.
Opus 5 demonstrates several novel capabilities compared to previous versions. The model can run for extended periods - days, weeks, or months at a time - particularly when combined with auto mode, without requiring scaffolding like SLGO. It also shows resistance to prompt injection, a capability that has been developing since Opus 4.7-4.8, with Sonnet 5 also performing well in this area.
The prompt injection resistance comes from three layers of protection: a well-aligned model representing three years of alignment research, a prompt injection classifier based on Chrisola's mechanistic interpretability work that monitors neurons in the model's brain for injection patterns, and an auto mode classifier. These three layers combined make prompt injection demonstrations impossible.
Over 80% of the system prompt was deleted from Claude Code with the Opus 5 release. This reflects the ongoing evolution of Claude Code as a product, where new models require deletion and modification of system prompts, tools, and tool prompts since behaviors that needed correction in previous models are now innate in newer versions.
Users can experiment by running d-system-prompt to set custom system prompts, or use the undocumented simple mode by setting the environment variable claude code simple equals 1, which deletes all system prompts including those for tools. Interestingly, the model performs slightly more intelligently without these prompts, though some prompts are retained for product usability when using Claude Code as an end-user product.
The development philosophy involves significant deletion with each model release. While not the entire codebase is deleted, extensive ablation occurs where the entire system prompt is removed and then reintroduced line by line to assess the impact of each component. Tools are also frequently removed and code in the harness is deleted regularly. The current Claude Code harness primarily contains safety, permissions, static analysis, and UI code.
The recommendation is to delete Claude.md files, skills, and hooks every six months to see what the model can accomplish without previous constraints. For Opus 5 specifically, deleting these elements is recommended since the model may not require instructions that were necessary for earlier models.
When rebuilding system prompts for new models, the process involves deleting first, then using the model to identify where it fails or succeeds. Instructions should only be added back when the model repeatedly stumbles on the same issues. This empirical approach differs from traditional engineering, where systems are designed upfront with comprehensive unit tests. Models behave more like living creatures with different personalities per generation, requiring ongoing adjustment based on observed behavior.
Evals are the most stable component across model releases and should be continuously appended to. However, they typically outlive harnesses for only 1-3 model generations before saturating and requiring replacement with new evals based on observed model struggles.
Product overhang refers to capabilities that current models possess but that products have not yet enabled them to express. Hobbling occurs when products get in the way of eliciting correct model behavior. The original Claude Code was created to unhobble Sonnet 3.5 by providing full terminal access instead of the rigid constraints of previous IDEs that limited models to single-line or multi-line autocomplete and read-only chat functionality.
Two key approaches for unhobbling models include giving models slightly harder tasks than initially thought possible, and providing higher-level task descriptions with guardrails and exit criteria rather than overly specific step-by-step instructions. The model should be allowed to work independently and return with results.
Opus 5 can rewrite entire codebases from one language to another. The Bun JavaScript runtime, originally written in Zig, was rewritten to Rust by the model in a single prompt using dynamic workflows. The process ran for 11 days, leveraging Bun's comprehensive test suite for validation, and the resulting Rust version is now in production use by Claude Code.
Internal experimentation at Anthropic revealed that Opus 5 can use OpenCV to draw images including portraits, animals, and landscapes despite not being specifically trained for drawing tasks. This discovery emerged from creative play without direct commercial applications.
The role of prompt engineer has evolved, with the current skill being less about traditional prompt engineering and more about giving models challenging tasks and enabling work verification. The desktop app rewrite experiment from Electron to Swift has been running for over two weeks, with the model creating internal Slack channels to post progress screenshots every few minutes.
The distinguishing factor for advanced Claude usage is an empirical approach: giving models tasks that seem too difficult, providing verification tools similar to what a human would use, observing where the model struggles, and addressing gaps through better prompting, skills, or MCP context. This contrasts with over-specification tendencies common among experienced engineers accustomed to traditional system building.
Dynamic workflows represent a fairly new feature in Claude Code. To use dynamic workflows, all that is required is to say "use a workflow." Claude will then trigger the dynamic workflow. A dynamic workflow uses the Bun runtime as a sandbox, starting a virtual machine within Bun that allows Claude to spawn many agents and orchestrate them. Rather than running just one agent or ten parallel agents, dynamic workflows handle complex tasks such as rewriting an entire codebase, performing in-depth data analysis over complicated data, or building very complex features that require multiple stages and dozens of pull requests.
The system starts agents for an initial pass, then may run a second stage with agents that verify or summarize the work, followed by a third stage that fans out again. This approach productively orchestrates different agents in sequence and in parallel. Different tools exist to orchestrate agents inside the sandbox, using tokens efficiently for complex work.
This system functions as an algebra for agents. There are ways to run agents in sequence and ways to run agents in parallel. Dynamic workflows represent a new form of test time compute. Historically, scaling laws related model intelligence to neural net size, training data volume, and training flops. Test time compute refers to the number of tokens generated. Dynamic workflows provide a new way to orchestrate test time compute, ramping up the amount used for difficult tasks. This approach enables launching thousands of agents productively and efficiently.
A second approach to running many agents uses loops and routines. A loop functions as a cron job running locally for Claude Code. A routine performs the same function but runs in the cloud. This allows closing a laptop while the routine continues. Unlike dynamic workflows, which break one task into chunks, loops and routines handle repetitive tasks that do not share context but may share memory. These can run every hour, every five minutes, or every day.
Claude Code now maintains itself through routines triggered from a Slack channel. Routines run across the CLI, iOS app, Android app, and desktop app. One routine cleans up dead code by looking for it across all codebases using static and dynamic analysis, then creates a pull request daily to delete it. Another routine ships experiments that have reached 100% rollout by deleting the experiment code. Additional routines write tests for areas needing coverage and delete tests that are no longer needed.
One routine called the abstraction police finds nearly duplicated abstractions across codebases and unifies them. Approximately 20 to 30 such routines now run daily across all codebases, sometimes involving hundreds or thousands of agents. This work previously required dozens or hundreds of engineers. Engineers can now focus on shipping new products, talking to users, and performing other engaging work.
Coding is solved for the types of coding performed by the speaker, but not for everyone. Deep systems codebases, distributed systems, and precise UI verification remain challenging. Claude still struggles when something is off by a pixel. Opus 5 represented a significant advance in vision and computer use, but it is not yet perfect.
Audience polling indicated that a substantial portion of attendees have 100% of their code written by agents, with a slightly smaller but still significant group reporting more than 50% agent-written code.
The most effective users of Claude Code adopt an empirical mindset. This involves forgetting prior knowledge about past models and computer science theory, observing where the model struggles on a task, and adjusting based on those observations. The approach treats the work as an empirical science rather than a theoretical one. Success comes from releasing previous assumptions and remaining open to trying approaches again.
Students should still learn certain skills the traditional way. The recommended approach is to learn computer science practically by teaching oneself to code in order to solve real problems. The speaker first learned to code on a TI-83 calculator in middle school, writing a guide for programming these calculators that remains available online. The initial language was BASIC. Programming began as a way to improve math test performance.
As problems grew more difficult, moving from algebra to calculus required learning assembly language to write more capable solvers. Programming has always been viewed as a practical activity. The advice for students is to learn not only computer science theory, which is intellectually valuable, but also how to apply it. This includes building startups and products, developing design sense and business sense, learning data science, and learning to talk to users. Combining these skills with computer science and engineering creates substantial value.
The approach begins with making something wanted for oneself, then progressing to building something people want. Attendees received access to Max 20x. The recommendation is to look for the code in email and to build something that runs for multiple months using thousands of agents.
Keep Y Combinator in your library
Save the videos and channels worth coming back to, and find them again in one place.
