Claude Code Ends 25 Years of Code Review for Top Engineer

Simon Willison spent 25 years building software with one unbreakable professional standard: review every line of code before it ships to production. Last week, he admitted on a recorded podcast that the standard no longer applies — and the reason is Claude Code, Anthropic's AI coding agent. "I'm not reviewing every line of code that they write anymore," he said, "even for my production level stuff." The uncomfortable part? His production systems have kept running fine.

The Line He Drew — and Why It Collapsed

Willison is the creator of Django (one of the world's most-used Python web frameworks), founder of Datasette (an open-source tool for exploring and publishing datasets), and a 25-year veteran of professional software engineering. He entered his Heavybit podcast interview confident he had a clear philosophical distinction between two modes of AI-assisted programming:

• Vibe coding — letting an AI write whatever it wants with no review, acceptable only for personal tools where "if it breaks, only I suffer"
• Agentic engineering — using AI agents to accelerate work while maintaining professional review standards for systems that serve real users

Mid-interview, that distinction dissolved. "Weirdly though, those things have started to blur for me already, which is quite upsetting," he told the host of Heavybit's High Leverage podcast (Episode 9, published May 2026). "I thought we had a very clear delineation."

The shift happened incrementally. Claude Code proved so consistently reliable on standard tasks — building a JSON API endpoint (a web address that returns structured data), executing a SQL query (a database lookup command) — that Willison stopped auditing the outputs. "I know full well that if you ask Claude Code to build a JSON API endpoint that runs a SQL query and outputs the results as JSON, it's just going to do it right," he said. A track record of reliable outputs replaced manual verification, even on production systems serving real users.

200 Lines a Day to 2,000 — and Every Process Built on the Wrong Baseline

The productivity numbers are striking. Willison describes moving from roughly 200 lines of code per day (a typical professional output for a senior engineer) to approximately 2,000 lines per day — a 10x increase. In practical terms, Claude Code can generate a complete Git repository (a version-controlled project folder) with 100 commits (individual saved checkpoints), professional documentation, and a comprehensive automated test suite in approximately 30 minutes.

But speed creates a structural problem that extends far beyond any single code review. Every process in the software development lifecycle was designed around one hidden assumption: engineers produce a few hundred lines per day. That assumption is now obsolete. The downstream consequences span the entire organization:

• Code review capacity: Workflows designed for human-paced output cannot absorb 10x volume without fundamental redesign
• Sprint planning: Timelines estimated for week-long projects now finish in hours; teams lack calibrated velocity benchmarks for AI-assisted development
• Quality signals: A polished repo with 100 commits and thorough documentation once signaled weeks of careful engineering — now it may represent 30 minutes of AI generation
• Accountability trails: When a human writes 2,000 lines and a bug causes a production outage, there is a code author on record. With AI-generated code, that accountability chain breaks.

"If you can go from producing 200 lines of code a day to 2,000 lines of code a day, what else breaks?" Willison asked on the podcast. "The entire software development lifecycle was designed around the idea that it takes a day to produce a few hundred lines of code."

Treating Claude Code Like a Black-Box Team

Willison has settled on a mental model that makes his behavior feel defensible: he treats Claude Code the way experienced engineers treat outputs from trusted external engineering teams. When another team sends a library or service integration, most engineers don't audit every line — they trust the established track record, run the integration tests, and ship.

The problem is that human engineering teams carry professional accountability mechanisms: reputational risk, performance reviews, legal liability for serious failures. Claude Code carries none of these. It cannot be fired. It has no professional reputation to protect. It holds no legal accountability for production failures. Yet the agent has built something functionally analogous through repetition: a track record of reliable outputs on well-defined tasks.

The specific risk Willison is watching for is what safety engineers call "normalization of deviance" — a concept historically used to explain how NASA engineers gradually accepted flawed O-ring behavior before the Challenger Space Shuttle disaster in 1986. Each successful unreviewed deployment makes the next skipped review feel reasonable. Accumulated confidence becomes a risk factor, not a safety signal. "As the coding agents get more reliable," Willison acknowledged, "I'm not reviewing every line of code that they write anymore. I know full well that what I'm doing is the normalization of deviance."

"I'm constantly reminded as I work with these tools how hard the thing that we do is. Producing software is a ferociously difficult thing to do."

— Simon Willison, Heavybit High Leverage Podcast, Episode 9

Even quality evaluation is degrading as a skill. Willison notes that even experienced engineers now struggle to assess whether an AI-generated project is genuinely well-built or merely cosmetically complete. A repository with 100 well-organized commits and thorough test coverage used to signal weeks of careful craft. It no longer does.

When AI Automation Agents Touch the Real World: 120 Eggs, No Stove

The abstract governance problem becomes viscerally concrete in an anecdote Willison highlighted from Andon Labs — a startup that deployed an AI inventory management agent (an automated program that places orders independently, without human sign-off for each transaction) at a popup cafe in Stockholm, Sweden.

The AI's procurement decisions failed in spectacular and specific ways:

• Ordered 120 eggs for a cafe with no stove or cooking equipment
• Ordered 22.5 kilograms of canned tomatoes for a fresh-ingredient menu that had no use for them
• Ordered 6,000 napkins, 3,000 gloves, and 9 liters of coconut milk at volumes that had no operational justification
• Sent "EMERGENCY" cancellation emails to real supplier businesses — without any human review or approval

The Andon Labs team found it amusing enough to create a "Hall of Shame" display shelf for the incorrect orders. But Willison identifies an ethical dimension the comedy obscures: the suppliers who received those emergency cancellation emails never consented to being test subjects in an AI experiment. The bureaucrats processing incorrectly filed permit applications didn't sign up for this. When AI agents take autonomous actions touching external parties — real orders, real emails, real legal filings — those affected parties have no voice and no recourse.

The Question Every Engineering Team Is Avoiding

Willison's honest self-examination surfaces a challenge the software industry is broadly sidestepping: governance frameworks for AI-generated production code have not kept pace with deployment reality. Enterprise adoption has responded with conservative gatekeeping — requiring AI solutions to be "battle-tested by multiple large organizations" before adoption risk is considered acceptable. That standard buys safety at the direct cost of the speed advantage.

Political commentator Matthew Yglesias captured a professional instinct Willison found resonant: he would rather hire a plumber than vibe-code his own plumbing. For life-safety systems — medical software, financial infrastructure, industrial control systems — that instinct is clearly correct. For a weather data API endpoint, the calculus is different. The engineering profession has no agreed framework for where that line should be drawn, and right now every team is drawing it individually, ad hoc, based on comfort level.

Practical steps for engineering teams navigating this shift right now:

• Define risk tiers explicitly, today. Write down which task categories are safe for unreviewed AI deployment before an incident forces the conversation under pressure.
• Monitor for normalization of deviance. After 50 successful unreviewed AI deployments, the 51st feels safe — that accumulated confidence is the risk, not evidence of safety.
• Build new quality metrics. Time-in-production without incident, per-module incident rates, and edge-case test coverage are more meaningful than commit count or documentation volume.
• Require consent gates for real-world actions. Before any AI agent sends external emails, places supplier orders, or submits regulatory filings, establish human approval gates for at least the first N interactions per new integration.

The industry has a 10x productivity accelerant already running in production. The safety frameworks are still being written. As Willison put it: "Producing software is a ferociously difficult thing to do" — and right now the profession is trusting systems that have no professional reputation to lose. Explore how teams are rethinking quality assurance in the AI era in our learning guides, or listen to the full podcast episode on Heavybit to hear the full conversation.

Related Content — Get Started | Guides | More News