Boris Cherny on Claude Code

Guest: Boris Cherny, head of Claude Code at Anthropic
Host: Lenny Rachitsky (Lenny’s Podcast)
Date: Feb 2026 (one-year anniversary of Claude Code’s external release)
Source: raw/lenny/Boris Cherny.txt

Overview

Boris Cherny created Claude Code as a solo hack inside Anthropic, shipped it as a terminal-first tool, and watched it grow to account for 4% of all public GitHub commits within a year. This episode covers the product philosophy that shaped Claude Code, Anthropic’s approach to agentic safety, and Boris’s views on the near-term future of software engineering and the broader role of technology in society.

Origins

Claude Code started as a one-month prototype inside Anthropic Labs — a team that also produced MCP and the desktop app. The sequence was intentional: coding → tool use → computer use mirrors Anthropic’s safety-first model development roadmap.

The terminal interface was not a design decision. It was simply the fastest way to build alone. When the team considered other form factors, they realised the terminal was also the only interface flexible enough to keep up with rapid model improvement.

The first internal post received two likes. Boris traces Claude Code’s trajectory: external release in February 2025 → slow early adoption (not an immediate hit) → first sharp inflection with Opus 4 / Sonnet 4 in May 2025 → continuous compounding acceleration through 2025–2026.

Boris’s personal crossing of 100% AI-written code happened in November 2025. He has not edited a single line by hand since.

Core product philosophy

Latent demand

Boris calls this “the single most important principle in product.” See Latent Demand.

Form 1 — user latent demand: look at how people already hack or misuse your product to do something it wasn’t designed for. Facebook Marketplace began when 40% of Facebook Groups posts were already buying/selling. Facebook Dating began when 60% of profile views were non-friends of opposite gender.

For Claude Code: people used a coding CLI to grow tomatoes, analyse genomes, recover corrupted wedding photos, and interpret MRIs. A data scientist (Brendan) figured out how to open a terminal just to run SQL queries — then the entire data science team followed within a week. That signal was the origin of Cowork.

Form 2 — model latent demand: look at what the model is trying to do, not what you designed it to do. In research, this is called being “on distribution.” In product terms: expose the model, minimise scaffolding, let it choose its own tool sequence. The product is the model.

Build for the model six months from now

Claude Code had poor product-market fit in its first months because the model was not yet capable enough. Boris designed for the model that would exist, not the model that existed. The design paid off when Opus 4 arrived.

Practical bets on model trajectories worth building around: (1) better and longer tool use; (2) longer autonomous operation — from 15–30 seconds with Sonnet 3.5 to 10–30 minutes unattended with Opus 4.6, with some runs spanning hours or weeks.

For startups: accept below-par PMF for 6 months; when the model arrives, you hit the ground running.

The bitter lesson

Bitter Lesson: the more general model will always eventually outperform the more specialised one. Applied to AI products:

Don’t impose strict multi-step orchestration workflows.
Don’t fine-tune for specific tasks unless there is a compelling reason.
Don’t add extensive context injection upfront — give the model a tool to retrieve context when it needs it.
Scaffolding gains of 10–20% are typically wiped by the next model release.

“Don’t try to put it into a box. Give it a tool so that it can get the context it needs.”

Don’t box the model

Claude Code inverted the standard LLM product architecture. Instead of “model is a component of my system,” Claude Code’s architecture is “the product is the model.” Minimal scaffolding. Tools provided; execution sequence decided by the model.

A year ago, scaffolding was often necessary. With Opus 4.6, it rarely is.

Team operating model

Under-fund to force Claude-ification. Putting one engineer on a project creates intrinsic motivation to automate with Claude. Scarcity produces the habit of reaching for Claude first.

Speed is the only early advantage. When Claude Code was just Boris, speed was the sole competitive differentiator. “If you can do it today, do it today” remains a team norm.

Maximum tokens first, optimise later. Give engineers unlimited token access during exploration. Optimise cost only after something works at scale — switch from Opus to Sonnet or Haiku, or distil into refined prompts. Token costs at individual scale are small relative to other costs.

Everyone codes. PM, EM, designer, finance person, data scientist — everyone on the Claude Code team codes, many without deep engineering backgrounds. Claude Code enables this. One engineer shipped a Go service over a month and “still doesn’t really know Go.”

Safety model

Anthropic’s three-layer approach to agentic safety:

Layer 1 — Alignment + mechanistic interpretability. During training. Understanding which neurons encode which concepts, monitoring for deception-related activations. See Mechanistic Interpretability.

Layer 2 — Evals. Laboratory setting: synthetic situations, controlled inputs, pass/fail measurement. See Evals.

Layer 3 — In-the-wild behaviour. As models become more capable, the first two layers become insufficient. Real deployment surfaces alignment failures that controlled settings miss.

Claude Code was used internally at Anthropic for 4–5 months before external release specifically to study in-the-wild safety on the first broadly-deployed coding agent. Cowork followed the same progression.

Race to the top. Anthropic open-sourced its agent sandbox — which works with any agent, not just Claude Code — to raise the industry’s safety baseline rather than treating safety practices as competitive advantage.

Mechanistic interpretability

Boris credits Chris Olah with inventing the field. Core idea: study neural networks at the same granularity as neuroscientists study biological brains — tracing individual neurons to concepts.

Key findings: model neurons behave similarly to biological neurons in some important ways. Specific neurons map to specific concepts. In large models, a single neuron can correspond to a dozen concepts simultaneously (superposition); co-activation with other neurons resolves meaning.

The field now has “quite strong evidence” that models do something deeper than next-token prediction — they perform planning and forward reasoning that is visible in the activation patterns.

See Mechanistic Interpretability and Chris Olah.

The future of software engineering

Coding is virtually solved

For the kinds of programming Boris does, AI writing 100% of the code is already the reality. He predicts this will generalise across codebases and tech stacks within months.

Role collapse

Title “software engineer” will begin to disappear; “builder” is the likely replacement. By end of 2026, Boris expects 50% overlap between PM, engineer, and designer roles on high-functioning teams. Everyone will be a product manager; everyone will code.

The printing press analogy

Pre-Gutenberg: fewer than 1% of Europeans were literate. In the 50 years after the printing press: more material printed than in the prior 1,000 years; printing costs fell ~100×. Over the following 200 years: global literacy rose to ~70%.

Boris’s parallel: coding is transitioning from a specialist skill (<1% of population) to a universal one. Short-term disruption is real. Long-term unlock is unimaginable — just as no one in 1450 could have foreseen the Renaissance.

A scribe interviewed post-Gutenberg said: “I hated copying. What I love — illustrating, binding — is now freed up.” Boris feels the same: the tedious work (dependencies, tooling, minutia) is automated; what remains is deciding what to build, talking to users, designing systems.

The generalist advantage

Engineers who cross disciplines — hybrid product/infrastructure, strong design sense, business intuition, user empathy — will be disproportionately rewarded. Being AI-native is necessary but not sufficient; curiosity and cross-domain thinking are the differentiating variable.

Claude Code tips

Use the most capable model (Opus 4.6, max effort). Less capable models often use more tokens via correction loops; the best model is frequently not more expensive overall.
Start in plan mode (~80% of tasks). Shift-tab twice in terminal. Agree on the plan; then auto-accept edits. With Opus 4.6, one-shot execution is the norm once the plan is aligned.
Try all form factors. Terminal, desktop app (code tab), iOS, Slack integration. The same Claude agent runs everywhere. Boris splits ~1/3 terminal / 1/3 desktop / 1/3 iOS.
Run multiple Claudes in parallel (multi-Claude-ing). Boris typically has 5 agents running concurrently across different tasks. Start a task, kick off another while it runs, review asynchronously.

Cowork

Built in 10 days using Claude Code itself. Came directly from latent demand — non-engineers using Claude Code in a terminal for tasks having nothing to do with code. Cowork is Claude Code packaged into the desktop app, with a VM-based sandbox for safety, aimed at non-technical tasks: project management, email, web forms, calendar, Slack.

The Chrome integration allows Claude to act in the browser on your behalf. Boris uses it for parking tickets, subscription cancellations, team status management, and email responses.

Boris’s getting-started advice: (1) start with a concrete tool use task (clean up desktop, summarise email); (2) connect tools to unlock multi-step workflows; (3) run multiple tasks in parallel.

The Cursor interlude

Boris briefly left Anthropic for Cursor (~two weeks) before returning. His stated reason for leaving: Cursor is an excellent team that saw where AI coding was going early. His reason for returning: Anthropic’s mission (safety) is something he needs personally to feel his work has meaning. No product, however exciting, substitutes for that.

Key concepts

Claude Code — the product
Latent Demand — core product philosophy
Bitter Lesson — general model always wins
Mechanistic Interpretability — safety’s layer 1
Agentic Engineering — broader context
Evals — safety’s layer 2
Tool Use — model capability axis
Scaling Laws — “we think in exponentials” (three co-founders were first authors of the scaling laws paper)