The Man Who Stopped Writing Code (And Started Running a Fleet)
There’s a specific kind of irony that only happens in software. The person who built the tool that millions of developers now use to write code hasn’t written a single line of code himself since late 2025.
Not a typo. Boris Cherny, creator of Claude Code at Anthropic, sat on a Sequoia stage at AI Ascent 2026 and said, quite casually, that he ships dozens of PRs a day from his phone. His personal record: 150 pull requests in a single day. Zero keystrokes of actual code.
He didn’t say it like a party trick. He said it like someone describing how they switched from a gas stove to induction. Obviously better. Why would you go back?
Most coverage since has been about the headline: coding is solved, the engineer is dead, AI will take your job (Read this to debunk the myth). That conversation is, frankly, exhausting and mostly surface-level. So I want to do something different here.
I want to pull apart the actual technical system Boris has built, and then ask the questions that aren’t getting asked. Because when you look at the architecture carefully, you start noticing gaps. Things Boris glossed over. Tradeoffs he didn’t mention. Assumptions baked into the setup that don’t transfer cleanly to most engineering environments.
And those gaps are, honestly, more interesting than the PRs-from-phone story.
The Origin: A Product Built for a Model That Didn’t Exist Yet
When Boris joined Anthropic’s Labs team in late 2024, the prevailing paradigm for AI coding was tab completion. A model sitting in your IDE, finishing your sentences. Glorified autocomplete wrapped in VC funding.
The insight was almost uncomfortably simple: the underlying models were capable of far more than the UX allowed. The product was the bottleneck, not the intelligence. So instead of building yet another IDE plugin, they asked: what if the agent wrote all the code?
For the first six months, Claude Code was mediocre. Adoption was flat. The setup was ahead of the model’s capabilities.
Then Opus 4 shipped in May 2025. And everything changed.
Here’s what gets buried in that origin story: they shipped a subpar product on purpose, and it worked. They weren’t optimizing for the current model. They were building for the next one. Six months of friction, flat adoption, and probably some internal pressure to show results. Then the model caught up, and suddenly the scaffolding they’d already built was sitting on top of a rocket.
That’s a difficult product bet to make and a harder one to survive politically. Most teams would have pivoted, simplified, or been shut down. The fact that they didn’t is less a story about AI and more a story about conviction in a roadmap that required the future to arrive on schedule.
Food for thought: how many products are being killed today because the underlying model isn’t there yet, when it might be there in six months? And how do you tell the difference between “too early” and “wrong”?
The Architecture: What Is Actually Running
Let me lay out the full system before I start poking holes in it.
The full system. Not a chatbot. A cognitive infrastructure with a human in the interrupt handler role.
This is what “surprisingly vanilla” looks like when the person describing it built the tool. Let’s go through each component, what it actually does, and what it implies.
CLAUDE.md: The Smartest Dumb File in Engineering
Every AI session starts fresh. No memory, no context, no recollection of the ESLint rule you spent two hours debugging last Tuesday. Standard LLM amnesia.
Boris’s solution is almost offensively simple: a single file called CLAUDE.md, checked into git, maintained by the entire team. The operating rule is mechanical: whenever Claude does something wrong, you add a note so it doesn’t repeat it. Not a Notion doc. Not a comment in the code. A living instruction file that travels with the codebase.
The effect compounds over time. Every mistake becomes a rule. Every code review where a human corrects the agent is a potential new line in CLAUDE.md. The codebase no longer just stores source code. It stores accumulated judgment. The file stays lean, around 100 lines, ruthlessly operational. Anything not relevant in the past two weeks gets deleted.
Here’s what I find genuinely interesting about this architecture: CLAUDE.md isn’t a new idea dressed up in AI clothing. It’s a solution to a problem that organizations have always had. Most teams make the same mistakes repeatedly because lessons learned in one sprint die in a post-mortem nobody reads. Boris’s answer is to institutionalize memory directly in the artifact layer, where the agent that needs to remember it can actually access it.
The question enterprise teams never ask: where does institutional knowledge actually live? Usually, it’s in the heads of the three people who’ve been there longest. When they leave, it evaporates. CLAUDE.md is a forcing function to write it down, in a place that’s actually used.
But here’s where I’d push back. CLAUDE.md works beautifully for a small, high-context team on a well-understood codebase, like the Claude Code team itself, building on TypeScript and React with the model’s highest training distribution. Scale this to a 200-engineer organization with 15-year-old Java services, inconsistent conventions, and tribal knowledge spread across time zones, and the “100-line file” philosophy runs into real friction. The discipline required to maintain it cleanly doesn’t scale linearly with team size. It scales with trust, shared context, and review rigor. Those are the actual prerequisites Boris didn’t mention.
Plan Mode: The Oldest Software Wisdom, Finally Enforced
Most developers use AI coding tools as very fast typists. Describe what you want, get code, discover it’s wrong, iterate. Speed without direction.
Boris inverts this. About 80% of his sessions start in Plan Mode, activated with Shift+Tab twice in Claude Code. In Plan Mode, the agent reasons without executing. No files written, no commands run. Just structured thinking about scope, sequence, and approach.
He iterates on the plan until both he and the agent agree. Then, and only then, he switches to auto-accept execution, where Claude implements the entire PR in one uninterrupted pass.
The technical reason this matters: agents without explicit planning will confidently sprint in the wrong direction. They’ll build something technically impressive that misses the actual goal entirely, while making 40 changes you didn’t ask for. This is the AI equivalent of a contractor who starts tearing down walls before reading the blueprints, except the contractor works at superhuman speed and the demolition takes three seconds.
What I think is less understood: Plan Mode isn’t an AI feature. It’s a forcing function for something senior engineers have been preaching for decades: design before you build. The fact that it needed to be baked into a tool as a distinct mode says something uncomfortable about how developers actually behave without guardrails, AI-assisted or not.
Food for thought: if Plan Mode 2-3x’s your output quality with an AI, what’s the honest implication for how we’ve been building software without it? Is this a new discipline the AI era introduced, or a discipline we always needed and the AI just made the cost of ignoring it high enough to feel?
Parallel Sessions: Distributing Cognition Like Compute
Boris runs five Claude Code instances in his terminal simultaneously, numbered tabs 1 through 5, with iTerm2 OS-level notifications that fire when a session needs human input. He also runs 5 to 10 more sessions in his browser in parallel. Plus mobile sessions started before bed, reviewed over morning coffee.
Peak concurrent sessions: 15 or more.
The mental model here isn’t “a helpful assistant.” It’s closer to a distributed workforce with a human interrupt handler. Boris is the architect. The agents are the execution layer. His attention is the scarce resource, and the entire system is engineered to require as little of it as possible, surfacing only moments that genuinely need a decision.
The practical engineering detail that makes parallelization actually work: each session runs on an independent git worktree. Without that, multiple agents writing to the same files creates the kind of merge conflict chaos that ruins afternoons. Worktrees give each agent an isolated execution context. They share the codebase, they just don’t collide.
Here’s where I want to slow down. The “15 parallel sessions” setup goes viral because the number sounds impressive. But the real leverage isn’t concurrency. It’s task decomposition. Breaking a codebase’s work into independent, well-scoped chunks that can genuinely proceed in parallel is a non-trivial skill, and Boris has been doing this with Claude Code’s own codebase, which he knows intimately.
Most developers’ codebases are not cleanly sliceable. Most features touch shared state, have unclear ownership boundaries, and require context that lives in one person’s head. Running 15 agents against that kind of codebase doesn’t give you 15x productivity. It gives you 15 agents competing for the same files and a debugging session that’ll make you nostalgic for sequential commits.
/loops and Routines: The Part Everyone Is Sleeping On
This is the section of the talk that got the least coverage and deserves the most.
/loop is a Claude Code feature that uses cron to schedule an autonomous agent job that repeats on a defined interval: every minute, every five minutes, every day. The agent wakes up, does its work, goes back to sleep.
Boris runs dozens of these at any given time:
A PR babysitter that monitors CI, fixes failures, and handles automatic rebasing.
A CI health monitor that detects and patches flaky tests.
A feedback aggregator that scrapes X/Twitter every 30 minutes, clusters the feedback, and surfaces it.
Routines are the server-side version: same concept, but running on Anthropic’s infrastructure. Close your laptop. The loop keeps going.
And here’s where it gets genuinely interesting: newer models like Claude 4.7 can initiate loops autonomously. If an agent detects data drift in a query, it can proactively offer to schedule a recurring report, invoke the Slack MCP to deliver it, and own the recurrence, all without you asking. The model decides the tool. The model schedules the recurrence. You get a Slack message.
At that point you’ve crossed a threshold. The agent isn’t responding to prompts. It’s managing work on an ongoing basis, proactively.
The engineering underneath is almost boring: cron jobs have existed for decades, and scheduled tasks are ancient infrastructure. What’s new is the reasoning layer running inside the schedule. Instead of a bash script that checks a CI endpoint and pages someone, you have an agent that understands what CI failure means in your codebase, knows its history, and can often fix the failure without human involvement.
Here’s the food for thought I keep returning to: loops fundamentally change the relationship between a developer and their codebase. Traditionally, software responds to events: a click, a webhook, a cron running a fixed script. Loops introduce something different: a continuous cognitive process that monitors, decides, and acts in the background while you sleep. The question of what you trust an autonomous background agent to decide versus what requires human approval is a system design question most teams haven’t seriously thought through. And the answer probably isn’t “trust it with everything” or “trust it with nothing.” It’s somewhere in between, and that boundary needs to be designed intentionally.
Slash Commands and Subagents: Automating the Inner Loop
Boris uses slash commands for every workflow he repeats multiple times per day.
The canonical example: /commit-push-pr. A single command that pre-computes git status using inline bash, then commits, pushes, and opens a PR. He runs this dozens of times daily. The inline bash pre-computation is a subtle but important detail: it avoids a round-trip with the model to figure out what’s changed, keeping the command fast and deterministic without burning context window.
Commands live in .claude/commands/, checked into git. The whole team shares them. Improve a workflow, and everyone gets it on the next git pull. That’s compound engineering applied to workflow automation: returns accumulate with team size and time.
Subagents go a level deeper. Where slash commands are invoked by the human, subagents are invoked by Claude during its own reasoning. code-simplifier runs automatically after changes to reduce complexity. verify-app has detailed end-to-end testing instructions, launching a browser, exercising the UI, and iterating until the code works.
PostToolUse hooks are the deterministic layer underneath all of this. A hook on Write|Edit tool calls runs bun run format || true automatically. Claude generates well-formatted code about 90% of the time. The hook handles the remaining 10%, reliably, mechanically, no model intelligence required.
Here’s a pattern worth naming explicitly: the system has three distinct memory mechanisms working at different layers. CLAUDE.md stores behavioral rules. Slash commands store workflow procedures. PostToolUse hooks store mechanical invariants. They serve different functions and shouldn’t be conflated. Most people using these tools mix them up and end up with an over-stuffed CLAUDE.md that tries to be all three things at once and becomes none of them.
Teleport: Session Portability as Infrastructure
Boris starts sessions in his terminal, hands them off to the browser with &, and teleports back and forth with --teleport. A local session becomes a cloud session, continuable from any device.
This solves a real but underappreciated problem in long-running agentic work: sessions shouldn’t be tied to a device. You can start a deep background task in your terminal, teleport it to the cloud, close your laptop, and pick it up from your phone when the agent surfaces something requiring a decision.
Here’s why this matters more than it looks: as agent tasks get longer and more autonomous, the “session” stops being an interactive conversation and starts being a unit of work with its own lifecycle. It needs to survive laptop closes, network interruptions, and context switches across devices. Teleport treats the session as a first-class persistent object rather than a temporary process. That’s a quiet but fundamental shift in how we think about the unit of computation in agentic systems.
The Verification Loop: The Most Important Component, and the Most Underinvested
Boris saved this for last in his original thread. It deserves disproportionate emphasis.
Give the agent a way to verify its own work.
Claude Code tests every change Boris ships using the Chrome extension. The agent opens a browser, tests the UI, identifies failures, fixes them, iterates. The measured impact: a proper feedback loop increases output quality by 2 to 3x.
The technical reason: agents without verification signals optimize for code that looks correct rather than code that is correct. These are not the same thing. Plausible and correct diverge quietly and often. An agent writing into a void produces code that passes a syntax check and fails at runtime. An agent running against a live test harness produces code that actually works.
TDD proponents have been making this argument for twenty years. What’s new is the scale: when an agent runs thousands of test iterations in the time a human would run ten, the verification loop becomes the primary quality lever, not the reviewer.
And here’s the uncomfortable implication: if verification is the most important component, then the actual prerequisite for Boris’s setup isn’t Claude Code. It’s test infrastructure that’s robust enough to give an agent meaningful feedback signals. Most codebases have tests that are partial, flaky, slow, or brittle. Running agents against that kind of test suite doesn’t give you 2-3x quality. It gives you fast feedback that’s often wrong, and agents that confidently fix the wrong thing.
The dirty secret of “AI-native development”: the teams that benefit most from autonomous coding agents are the ones who already did the boring groundwork. Good tests, clean interfaces, modular architecture. The AI era doesn’t reward shortcuts. It accelerates existing quality, in both directions.
Claude Code’s Own Future: 100 Lines
Boris made an offhand prediction that landed harder than most of the conference’s planned content: Claude Code itself might be 100 lines of code a year from now.
Currently, the “harness” layer (the scaffolding around the model: context management, tool calling, session handling, permission systems) is substantial. But models keep getting more capable, and the complexity that required explicit tooling yesterday gets absorbed into model intelligence today.
Sonya Huang at the same conference framed the three ingredients of agentic systems: models, tools, and harnesses. The thesis is that as models improve, the harness layer shrinks. You need less scaffolding to hold a smarter agent.
If Claude Code is 100 lines of code in a year, it means the intelligence has fully internalized what the scaffolding used to enforce. That’s a deeply strange thing to contemplate. The product roadmap of a tool like Claude Code isn’t “add features.” It’s “delete features as the model learns to do them natively.”
Food for thought: we’re entering a category of software where the product gets simpler as it gets more powerful. That inverts almost every product intuition we have. How do you build a business on a product whose competitive moat is an underlying model you don’t control, one that’s progressively making your own codebase redundant?
The Printing Press, the Job Market, and Why Both Analogies Are Half Right
Boris invoked the printing press comparison, and it’s worth unpacking carefully because it gets misread almost every time.
Before Gutenberg, roughly 10% of Europeans were literate. Within 50 years of the press, more literature was published than in the previous thousand years combined. The press didn’t replace writers. It created an explosion of them, while also collapsing the scribing profession that had existed for centuries.
The analogy isn’t “AI replaces software engineers.” It’s: software creation, currently accessible to a small fraction of humans who can write code, is about to become accessible to a far larger population. The total volume of software being built will increase dramatically.
I’ve written at length about the AI job market question before. The Substack version (and the one on Medium) is that the panic is misplaced, and the real shift is more nuanced than most headlines suggest. The printing press framing clarifies something important: the scribes who lost their jobs weren’t replaced by other scribes. The entire category of manually copying manuscripts stopped existing. But the number of people who could participate in written communication exploded.
Boris’s own team is the early signal. The PM writes code. The designer writes code. The data scientist, the finance person, the user researcher: all of them write code on the Claude Code team. Not because they became engineers. Because the barrier to expressing intent as working software dropped dramatically.
The title “software engineer” might be heading toward “builder” by the end of 2026, in Boris’s framing. Not because engineers disappear, but because the definition expands until the boundary between engineer, PM, designer, and builder becomes too blurry to maintain. The question isn’t whether your current job is safe. It’s whether you want to be the person who knows how to coordinate a fleet of agents producing that software, or the person who gets coordinated by someone who does.
What Boris’s Setup Actually Requires (The Part That Doesn’t Go Viral)
The setup sounds clean when listed as components. It isn’t.
Running 15 parallel sessions productively requires genuine task decomposition skill. Most developers don’t have strong opinions about how to slice their codebase into independent work units, because historically there was no incentive to develop that skill. Running agents in parallel forces you to think like a technical program manager.
Maintaining a useful CLAUDE.md requires team discipline and shared standards. Add rules carelessly, and the file becomes a graveyard of outdated instructions that confuse more than they help. Add them consistently, and it becomes institutional memory.
The verification loop requires test infrastructure that’s actually good. This is a non-trivial prerequisite for most engineering teams, and the ROI on Boris’s setup is partially a function of Anthropic’s codebase being reasonably well-tested.
And Opus 4.5 is not cheap. Boris uses the heaviest, slowest model for everything, on the logic that a smarter model requires less steering and fewer correction cycles, making it net faster. That’s correct, and it also means a significant compute bill. At Anthropic, Boris has essentially unlimited tokens. Most engineers and most startups don’t.
The honest framing: Boris’s setup is optimized for Boris’s context. A deep understanding of one codebase, in a high-distribution language stack, with an employer who provides unlimited compute, within a team that has already bought into AI-native workflows and shared conventions. The architecture is genuinely impressive. The transfer function to other contexts requires work that the 24-minute video doesn’t show.
The Strangest Part
Boris described running a few thousand AI agents overnight from his phone like someone describing a recurring calendar event.
“That’s just like the way that I coded.”
He said it with mild surprise that anyone found it unusual. 104,000 saves and 8.1 million views on a post he described as “surprisingly vanilla.”
There’s a version of what Boris has built that’s about productivity metrics and PR counts. That version is boring and misses the real architecture.
The more interesting version: he’s built a system where intelligence is scheduled, distributed, and persistent. Where memory compounds across sessions. Where verification is structural rather than incidental. Where the human is an architect of workflows and an interrupt handler for edge cases, not an executor of tasks.
And the quietest part of the whole 24-minute video is the 100-lines prediction. Because if Claude Code, the tool enabling all of this, compresses to 100 lines of code as the model internalizes the harness, then what Boris has actually built isn’t a product.
It’s a proof of concept for what software development looks like when intelligence becomes infrastructure.
At that point, the question isn’t whether coding is solved.
It’s whether the system you’re running is the solver, or the solved.
The original Sequoia AI Ascent interview with Boris Cherny is 24 minutes. The Q&A section is where the real questions get asked. Worth watching in full.
-Hardik