Article · 2026-07-28 · 6 moments

How building software is changing at Anthropic

A deepdive on what’s changed in how the leading AI lab makes software. Ever more code review and testing is done by AI, two-pizza teams very much alive, and more. Details from inside of Anthropic ✦ AI generated

Read original ↗

GUEST Katelyn Lesse GUEST Jarred Sumner GUEST Thariq Shihipar GUEST Author (narrator)HOST Gergely Orosz

Context

Assumptions about AI capabilities must be constantly re-tested with each new model generation, leading to significant simplifications like deleting 80% of the system prompt.

Thariq Shihipar explains that as models get smarter, teams must revisit prior assumptions—they recently deleted 80% of Claude Code's system prompt because the model had become capable enough without it, and they've discovered Claude is unexpectedly strong at working with HTML.

transcript

Thariq Shihipar: The thing with agents is that you have to revisit any assumptions you have made because it can change with a new model generation. For that reason, we deleted 80% of the Claude Code system prompt recently because the model has gotten smarter. Using HTML is another assumption we needed to re-examine. HTML is one of those things which Claude is a lot smarter at than many of us expected. I've started preferring HTML as an output format over Markdown, and see this being used by others on the Claude Code team.

explains mechanism · 1extends · 1

Example◆

A year-long, multi-engineer rewrite of Bun from Zig to Rust was completed in 11 days using 64 parallel AI agents and $165K in tokens.

Jarred Sumner rewrote Bun's 535,496 lines of Zig to Rust in 11 days using 64 parallel Claude agents and $165,000 in API tokens—a project he estimates would have taken three engineers a full year by hand.

transcript

Jarred Sumner: Historically, rewrites are a terrible idea. Excluding comments, Bun is 535,496 lines of Zig. A rewrite in another language would take a small team of engineers a full year. It would mean freezing bugfixes, security fixes or feature development for that time. The least risky approach to getting something shippable would be a mechanical port from Zig to Rust, with the minimal number of behavioral changes, using the exact same test suite we already use for testing Bun. By hand, I think this would've taken three engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features. We never would've done that.

rebuts · 1supports · 2

Mechanism

Code review and testing are increasingly done by AI, enabling trust in code merged at a pace no human can manually review.

Jarred Sumner describes how AI-powered code review, security scanning, fuzz testing, and out-of-process testing allow merging over 100 PRs per day with confidence, because automated AI review catches bugs that would take an hour of human reading.

transcript

Jarred Sumner: Critiquing the code and testing it with agents is a new approach we do a lot more of. I think a lot about trust when you merge a lot of code. How do you merge 100+ PRs a day, and make sure the code works? At this pace, you need to trust the code without the ability to read it all yourself. And I think it's a few things: Code review: it needs to be really good and automated. I'm clearly tooting our own horn here, but I find Claude's code review to be really good. Claude's code review catches bugs that would take me an hour of closely reading the code to figure out. The caveat is that it's expensive! Security scanning: for this Rust rewrite we did 11 runs of the Claude Security Scanner. Fuzz testing: we've also been doing different types of fuzzing (fuzz testing), where we had Claude write a fuzzer for things like parser fuzzing.

Claim◆

The most complex project (Claude Managed Agents) took six months and required a pre-AI-style planning process with PRDs, not rapid prototyping.

Katelyn Lesse describes how building Claude Managed Agents required extensive upfront planning, a PRD, and coordination across teams—much like pre-AI complex projects—and took six months, though that is still faster than the estimated two years pre-AI.

transcript

Katelyn Lesse: There are products you can jump straight to prototyping, but then there are ones where you need to start by architecting it properly. For example, if we build a TypeScript CLI – which is pretty trivial for what needs to be built – we could go straight to prototyping. But with Claude Managed Agents, we needed to first figure out what we are doing. Of course, we did some upfront prototyping for Managed Agents: hacking and spiking things. But prototyping itself was more about understanding the requirements. Our planning process looked more like a typical pre-AI planning process.

Claim

Traditional engineering practices like two-pizza teams, PRDs for complex projects, and the challenge of context switching remain unchanged despite AI.

Despite rapid AI-driven changes, several fundamentals persist at Anthropic: two-pizza sized teams, the importance of planning and PRDs for complex projects, and context switching remain challenges—though design has become more ongoing and less upfront, and teams work on more projects simultaneously.

transcript

Author (narrator): Still the same: two-pizza teams, planning is important, PRDs are relevant in complex projects, context switching is a challenge, the ratio of time spent on coding vs testing not changing that much. Just like before, we had a PRD, it was a Google Doc. We used a Google Doc because we needed to coordinate all interested people. This has not gone away.

rebuts · 1supports · 1

Data

Verification now takes far longer than implementation: roughly 85% of time on fixing and validating versus 15% on initial coding.

Jarred Sumner reports that in his Bun rewrite, implementation took about 15% of the effort while 85% went to fixing compile bugs, passing tests, and verifying correctness—a pattern Thariq Shihipar confirms holds broadly at Anthropic.

transcript

Jarred Sumner: Implementation of the Rust rewrite took far less time than fixing it up, then validating that it works as expected. The 'implementation' part of rewriting the code from Zig to Rust took about 15% of the time, while 85% went on fixing things up: getting it to compile, fixing tests, verifying that it worked.

explains mechanism · 2

Highlight slides

535K Lines of Zig → Rust in 11 Days✦ from: A year-long, multi-engineer rewrite of Bun from Zig to Rust was completed in 11 days using 64 parallel AI agents and $165K in tokens.Managed Agents required pre-AI-style planning✦ from: The most complex project (Claude Managed Agents) took six months and required a pre-AI-style planning process with PRDs, not rapid prototyping.Why This Was Unthinkable by Hand✦ from: A year-long, multi-engineer rewrite of Bun from Zig to Rust was completed in 11 days using 64 parallel AI agents and $165K in tokens.Pre-AI planning vs. direct prototyping✦ from: The most complex project (Claude Managed Agents) took six months and required a pre-AI-style planning process with PRDs, not rapid prototyping.

Related episodes

Article · Simon Willison's Weblog

Claude Code uses Bun written in Rust now

→

Article · ByteByteGo Newsletter

AI Customer Support at Scale: The Travel Industry’s $Billion Bet

→

Video · The Cognitive Revolution

Intelligence on the Edge: Liquid AI's Ramin Hasani on the Search for Device-Native Foundation Models

→