How Claude Code Is Built

Gergely Orosz · pdf · 2025-09-23 source ↗ Reader 🖥️

Agent-Native Design Agentic Engineering Claude Code Multi-Agent Orchestration Pull Requests & Async Code Review Risk Tiering SRE & Incident Response Test-Driven Development

Claude Code is built by a small team that treats the Claude model itself — not its own surrounding code — as the real product, deliberately minimizing scaffolding, choosing an "on-distribution" tech stack the model already masters, deleting code whenever a new model release subsumes it, and restructuring code review, testing, incident response, and prototyping around AI doing the first pass; Orosz presents this as a plausible preview of how "AI-first" engineering teams will operate, while flagging that Anthropic's unlimited, cost-free access to its own frontier model and its identity as a research lab (not a product company) limit how directly the specifics transfer elsewhere.

practical · mixed — Primarily expository/narrative reporting (an interview-based case study of how one team builds a product), structured around seven numbered sections, but it closes with an explicitly argumentative claim: that this team's practices preview the future of AI-assisted engineering teams generally — a claim the author himself partially undercuts with caveats about Anthropic's atypical context.

Structure

Part	Role
Origin story: a music-controlling AppleScript prototype given filesystem/bash access, Boris Cherny's early solo use, internal viral adoption, and the internal debate over whether to release Claude Code publicly at all	context/evidence
Tech stack and architecture: TypeScript/React+Ink/Yoga/Bun, chosen to be 'on distribution'; no virtualization/sandboxing; a seek-permission system as the safety mechanism; a feature list (hooks, MCP, output styles, enterprise IAM, SDK)	evidence
Building and shipping features in days, not weeks: 60-100 internal releases/day, ~5 PRs/engineer/day, the 20-prototype todo-list case study	evidence
Redesigning the terminal UX: contextual loading messages, tooltips, a vibe-coded Markdown renderer	evidence/example
What 'AI-first' software engineering looks like: AI first-pass code/security review, TDD renaissance, AI-assisted incident response, framework migrations, BigQuery/monitoring dashboards, deliberately minimal feature-flagging, and 'multi-clauding' (parallel agents)	core argument
Building subagents: the three-day hackathon that discarded a complex multi-agent topology for the simplest viable orchestrator design	evidence/case study
Future of AI-assisted engineering teams: obsessive dogfooding, 5+ prototypes/day as a new baseline, product-minded engineers as a hiring implication, 'developer joy,' and an explicit caveat section on how Anthropic is a 'different type of startup'	conclusion, partially self-undermining

Key terms

Product overhang
Boris Cherny's term (attributed to AI-industry usage) for the gap between what a model is already capable of doing and what the product built around it is designed to let it do — i.e., the model has latent capability the product hasn't caught up to exposing.
On distribution / off distribution
Whether a chosen technology (a language, framework, or stack) is something the model already has deep training exposure to and is good at using ("on distribution": TypeScript, React) versus something more exotic the model would need to be explicitly taught ("off distribution").
AI-first software engineering
Not merely using AI tools alongside a normal process, but restructuring the process itself so AI does the first pass by default — on code review, security review, test-writing, incident triage, and monitoring-dashboard construction — with a human providing a second pass only where warranted.
Multi-clauding
Running several separate Claude Code agent instances in parallel on different tasks at once, as a single engineer, rather than working on one task at a time.

Propositions

explicitClaude Code originated from an internal prototype that gave Claude filesystem and bash access, which revealed "product overhang": the model could already explore a codebase (reading files, following imports, chaining reads) far beyond what any existing product captured.conf: high
explicitAnthropic debated whether to keep Claude Code as an internal competitive advantage rather than release it publicly, and decided to release it because exposing a tool that "almost certainly" gets heavy real-world use serves Anthropic's core business — model-safety research — better than hoarding it.conf: high
explicitAnthropic's engineering team saw a 67% increase in pull-request throughput per engineer even as team size doubled, inverting the usual pattern where fast headcount growth drags per-engineer output down; the team credits Claude Code for this.conf: high
explicitThe team deliberately chose an "on-distribution" tech stack (TypeScript, React with Ink, Yoga, Bun) specifically because the model is already strong with it, which lets Claude Code build and maintain roughly 90% of its own code without the team having to teach the model an unfamiliar stack.conf: high
explicitThe team's governing design principle is to write as little business logic and UI scaffolding as possible so users "feel the model as raw as possible," and to delete code — e.g., roughly half the system prompt with the 4.0 models — whenever a new model release can do what that code used to do.conf: high
supportsHow building software is changing at Anthropic · p13 — The team's concrete practice of deleting scaffolding code (e.g. half the system prompt) whenever a new model release subsumes it is a specific instance of the later article's broader claim that design assumptions must be re-tested at every new model generation.
explicitClaude Code runs locally with no virtualization or sandboxing, and relies instead on a tiered, user-granted permission system (grant once, grant for future sessions, or reject) as its safety mechanism — a choice driven by the same "pick the simplest option" heuristic rather than by a safety-first architecture.conf: high
extendsHow Anthropic Teams Use Claude Code · p4 — Claude Code's own grant/grant-persistently/reject permission system is the tool-level mechanism underlying the checkpoint-heavy, revert-friendly workflow that other Anthropic teams report adopting at the practice level to make autonomous agent work safe without sandboxing.
explicitA team of roughly a dozen engineers sustains 60-100 internal releases and about one external release per day, and treats disposable prototyping as cheap enough that one engineer built and evaluated 20 distinct UI variants for a single feature (todo-list visibility) within two days.conf: high
explicitClaude now performs the first pass on all code reviews and security reviews across Anthropic (not only on the Claude Code team), with a human engineer always required to provide a second pass.conf: high
supportsHow building software is changing at Anthropic · p10 — Orosz's earlier reporting (Sep 2025) that Claude does first-pass code/security review with a mandatory human second pass is the concrete layered-review pattern that the later 'building software' piece (Jul 2026) generalizes into a broader claim about trust in AI-generated code coming from layered automated review.
explicitTest-driven development — described as having fallen out of favor industry-wide in the 2010s because writing tests first felt slow — has had a practical renaissance on the Claude Code team specifically because Claude 4.0-era models are capable enough to write most tests themselves, giving the agent a concrete target (a failing test) to iterate against.conf: high
explicitClaude Code is used for oncall and incident response — triaging incidents by pulling in relevant Slack contacts and Sentry logs, finding root causes, and (with permission) auto-bisecting or reverting changes — and Boris claims it is often faster at finding root causes than a human engineer.conf: medium
explicitFeature flags at Anthropic are used sparingly, mainly as compile-time switches to strip unreleased code from external builds rather than as a runtime risk-mitigation or gradual-rollout mechanism, because the team ranks security, then reliability, then speed of iteration, and treats a feature as either ready to ship externally or not.conf: high
extendsHow building software is changing at Anthropic · p9 — The earlier 'multi-clauding' data point (25% of Max users run parallel agents, reported as an open question) is the precursor observation that the later article generalizes into 'running 3-10+ parallel agents per person is now normal working practice.'
explicitAbout 25% of Claude Max subscribers run multiple ("multi-clauding") Claude Code agents in parallel on a given day — evidence, in the author's view, that programming may be shifting from a historically single-threaded activity toward a parallel one, though he explicitly flags this as an open question rather than a settled finding.conf: high
supportsHow Anthropic Teams Use Claude Code · p7 — The subagents feature's own founding design (a simple orchestrator invoking narrowly-scoped agents, no inter-agent chat) is the underlying mechanism that other Anthropic teams are later reported applying when they decompose a complex workflow into specialized sub-agents.
explicitThe subagents feature was built in a three-day internal hackathon in which the team spent the first two days designing, then discarding, a complex multi-agent topology with inter-agent message buses, before converging on day three on the simplest viable design: a single blocking orchestrator invoking agents defined only via the existing "/" command and markdown files, with no agent-to-agent communication.conf: high
explicitAnthropic researchers' own (separately referenced, and explicitly described as inconclusive) research into multi-agent patterns reinforced the subagents team's decision to favor a simple architecture over a complex one.conf: high
explicitThe author identifies specific conditions at Anthropic — being a research lab rather than a product company, treating the LLM itself (not the surrounding code) as the real product, and giving every engineer unrestricted, cost-free access to its most expensive model — as factors that may limit how directly other companies can copy the Claude Code team's AI-first practices.conf: high
explicitcontestedBoris and Sid both report that AI agents have made software engineering more fun and energizing overall — not despite the mechanical parts of the job being automated, but because of the sheer velocity and breadth of experimentation agentic tools now allow — comparable to the feeling of programming as a hobbyist discovering the craft for the first time.conf: high
contradictsPodcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle · p2 — Boris and Sid report AI agents making engineering more fun and energizing overall; this directly conflicts with the AI Joy Gap podcast's claim that AI has absorbed the creative, enjoyable parts of development and left developers with the least enjoyable residual work.
explicitAnthropic credits Claude Code with helping engineers at other companies complete framework migrations far faster than estimated — one cited case: an estimated two engineer-years (or 10 engineers over roughly 2.5 months) completed by a single engineer in two weeks — a claim the author says he would normally be skeptical of but treats as credible because he has heard similar reports from other teams.conf: medium
implicitClaude Code's founding engineers' product-minded, experimental profile (deep craft experience, zero-to-one product experience, entrepreneurial, willing to discard their own prototypes) is implicitly what let a team with no designers, researchers, or product managers reach a strong product-market fit, suggesting more startups may seek out similarly profiled engineers because AI agents amplify exactly that kind of judgment.conf: medium

Arguments

Claude Code should run locally with no virtualization/sandboxing and rely on a user-granted permission system as its safety mechanism. strength: medium

Explicit premises:

Simplicity is the team's default heuristic for every design decision
The simplest answers to 'where do you run shell commands' and 'where do you read/write files' are locally
A tiered permission system can intercept a dangerous action (e.g. deleting a file) before it happens, and lets users grant, grant-persistently, or reject

Implicit premises:

The marginal safety benefit of a VM/container sandbox is smaller than the complexity cost it would add to the product
Users will reliably notice and correctly respond to permission prompts, rather than habitually auto-approving them over time
A team-, project-, and company-tiered settings file (allow-listing commands like source-control check-ins) will not itself become a new, under-scrutinized source of silently over-broad permission

Inferences:

This design pattern externalizes safety responsibility from the architecture onto the end user's permission decisions, which only works as long as users remain an effective last line of defense

Claude Code's AI-first restructuring of code review, testing, incident response, and monitoring previews how general engineering teams will work in the near future. strength: low