← Back to Blog
AI Engineering Developer Tools Software Architecture

How Anthropic Built a C Compiler With 16 Parallel Claude Agents

Sean Breeden August 7, 2026 6 min read
How Anthropic Built a C Compiler With 16 Parallel Claude Agents

On February 5, 2026, Anthropic researcher Nicholas Carlini published an engineering post describing what happened when he pointed sixteen parallel instances of Claude Opus 4.6 at a blank repository and told them to build a C compiler in Rust from scratch. Two weeks, roughly 2,000 Claude Code sessions, approximately 2 billion input tokens, and $20,000 in API costs later, the result was a 100,000-line compiler called CCC that can build a bootable Linux 6.9 on x86, ARM, and RISC-V, compile QEMU, FFmpeg, SQLite, PostgreSQL, and Redis, achieve a 99% pass rate on the GCC torture test suite, and run Doom. Carlini works on Anthropic's Safeguards team, which gives this experiment a particular flavor: it was conceived as much as a study in agent use design as a demonstration of what Claude can write.

The compiler is a drop-in GCC replacement. Build systems can point the CC environment variable at CCC via make, CMake, or ./configure scripts, and the handoff is transparent. The agents handled everything from lexical analysis and parsing through semantic analysis, intermediate representation generation, optimization passes, and final code emission targeting x86-64 assembly. Crucially, Claude had no internet access at any point during development, and the finished compiler depends only on the Rust standard library. That clean-room constraint is not a footnote. For teams thinking about auditable, provenance-safe agentic projects, it is a replicable template: you can run a capable agent system on a sensitive codebase without giving it a live connection to the outside world, and the output is still verifiable.

How Anthropic Built a C Compiler With 16 Parallel Claude Agents

The architecture Carlini built around the model is where the real design work lives. His core approach was straightforward in concept: stick Claude in a simple loop where the agent keeps working on a given task until it is solved, then immediately picks up the next one. Sixteen instances ran in parallel, each inside its own Docker container, all reading from and writing to a shared Git repository. To prevent agents from trampling each other's work, Carlini used a lock-based synchronization scheme where an agent claims a task by writing a text file to current_task. Simple, readable, and auditable. He then specialized agents into distinct roles: compiler work, deduplication, performance, and documentation. Some agents spent their cycles on code quality; others handled prose. This kind of role separation emerged from practical necessity rather than theory, and it's the kind of detail that gets lost when people focus only on the output artifact.

The lessons Carlini draws from the use are pointed. First, tests have to be extremely high quality, and the test output has to be designed with the agent's perspective in mind. His framing: "put yourself in Claude's shoes." If the test use floods its output with thousands of useless bytes, the agent has to wade through noise to find the signal. That degrades performance in ways that compound over thousands of sessions. Second, since Claude will autonomously work to solve whatever problem the verifier describes, the verifier itself has to be nearly perfect. If the task definition is slightly wrong, the agent solves the wrong problem, and there is no human in the loop to catch it. This is a real operational risk for teams deploying agent systems, and Carlini is direct about it.

There is a ceiling here, and Carlini does not obscure it. The compiler lacks a 16-bit x86 implementation needed to boot Linux out of real mode, so it hands that specific step off to GCC. It also has no assembler or linker of its own; Carlini notes that Claude had started automating these components but they remained buggy, and the demo video used a GCC assembler and linker. The code generation is inefficient in a measurable way: even with all optimizations let, CCC produces slower output than GCC with all optimizations disabled. These are not minor gaps. Efficient code generation and a complete toolchain are the kind of problems that take compiler teams years to solve, and it is honest to say that CCC sits below that bar today.

Carlini describes this ceiling as representing the current limits of LLM capabilities on this class of problem, and he says he plans to keep having Claude push new changes to address the limitations. That iterative framing matters. The compiler is a live artifact, not a finished product. The repository is open under anthropics/claudes-c-compiler, and anyone can read the code and run it. That openness is consistent with the broader point: the experiment is meant to teach, not just to impress.

The big shift Carlini identifies is worth sitting with. Prior generations of language model tooling followed a predictable loop: a user defines a task, an LLM runs for a few seconds, returns an answer, and the user decides what to ask next. Tab completion in IDEs, function-body generation from docstrings, pair programming in Claude Code: all of these operate within that human-paced interaction model. Agent teams break the loop. The model keeps working without waiting for a follow-up. Carlini notes that this excites him and also makes him uneasy, and that reaction seems calibrated rather than performative. When the human is no longer the rate-limiting step in a multi-week engineering effort, the design of the scaffolding around the model becomes as consequential as the model itself.

The Modular blog framed the broader significance well: "AI has moved beyond writing small snippets of code and is beginning to participate in engineering large systems... Crossing from local code generation into global engineering participation." That is a precise description of what CCC represents. It is not a claim that AI has replaced compiler engineers. The people who built GCC and LLVM spent decades on the problems CCC still cannot solve. But as a demonstration that a well-designed agent use can sustain coherent engineering work across 2,000 sessions and 100,000 lines of non-trivial systems code, it is a concrete data point that teams building AI-assisted development pipelines should study carefully. The compiler is interesting. The use is the part worth copying.

About the Author

Sean Breeden is a Full Stack Developer specializing in Artificial Intelligence, Machine Learning, Mage-OS, Shopify, Magento, Python, and PHP.