Building a C Compiler with Parallel Claude Agent Teams

TL;DR

Anthropic researcher Nicholas Carlini demonstrated the capability of "agent teams" by tasking 16 parallel Claude Opus 4.6 instances to autonomously build a Rust-based C compiler from scratch. The resulting 100,000-line compiler can build Linux 6.9 on x86, ARM, and RISC-V, proving that autonomous agent teams can handle massive, long-running technical projects without constant human intervention.

The Agent Team Architecture

To move beyond the need for a human operator to provide constant feedback, Carlini developed a harness that places Claude in a continuous loop. When one task is completed, the agent immediately begins the next, guided by a prompt that instructs it to break problems into small pieces and track its own progress.

Parallel Execution and Synchronization

Running multiple agents in parallel allows for simultaneous debugging of multiple issues and the use of specialized roles. The technical implementation uses a bare git repository and Docker containers:

Infrastructure: Each agent operates in its own Docker container with the repository mounted. Agents clone a local copy, work on tasks, and push changes to the upstream repository.
Synchronization: To avoid redundant work, agents use a simple locking mechanism by writing text files to a current_tasks/ directory. If two agents attempt to claim the same task, git synchronization forces the second agent to choose a different task.
Workflow: Agents pull from upstream, merge changes from other agents, push their updates, and remove the lock. Claude is tasked with resolving any resulting merge conflicts.

Engineering for Autonomous Progress

Successful autonomous development requires a environment where the model can orient itself and verify its own work without human guidance.

High-Quality Verification

Because Claude solves the problem it is given, the task verifier must be nearly perfect to prevent the model from solving the wrong problem. Carlini implemented a continuous integration (CI) pipeline and strict enforcement to prevent new features from breaking existing functionality.

Optimizing for LLM Constraints

The harness was designed to account for specific language model limitations:

Context Window Pollution: To prevent wasting tokens, the harness prints minimal output and logs detailed information to files. Logs are formatted so that errors are easily searchable via grep.
Time Blindness: Since LLMs cannot track time, the harness provides a --fast option that runs a deterministic 1% or 10% random sample of tests to identify regressions quickly without spending hours on full test suites.

Scaling to Complex Tasks

While parallelization is easy for independent tests, monolithic tasks like compiling the Linux kernel often lead to agents to overwrite each other's work. To solve this, Carlini used GCC as an "online known-good compiler oracle."

By randomly compiling most of the kernel with GCC and only a subset with Claude's compiler, agents could isolate and fix bugs in specific files in parallel. This process was further refined using delta debugging techniques to identify files that failed when paired together but worked independently.

Capabilities and Limitations of the Resulting Compiler

Using Claude Opus 4.6, the project consumed 2 billion input tokens and 140 million output tokens over two weeks, costing approximately $20,000.

Technical Achievements

Scope: A clean-room implementation using only the Rust standard library.
Compatibility: Can build a bootable Linux 6.9 on x86, ARM, and RISC-V. It also compiles QEMU, FFmpeg, SQLite, Postgres, and Redis.
Benchmarks: Achieved a 99% pass rate on most compiler test suites, including the GCC torture test suite, and successfully compiled and ran Doom.

Current Limitations

Bootstrapping: It lacks a 16-bit x86 compiler required to boot Linux from real mode; it currently calls GCC for this specific phase.
Toolchain: It does not have its own fully functional assembler and linker, relying on GCC for the demo video.
Efficiency: The generated code is less efficient than GCC code produced with all optimizations disabled.
Code Quality: The Rust source code is reasonable but does not match the quality of an expert human Rust programmer.

Implications for Autonomous Development

This experiment marks a shift from LLMs as tab-completion tools or pair-programmers to LLMs as autonomous project executors. While the potential for productivity is immense, Carlini notes significant safety concerns regarding the deployment of software that has been autonomously produced and never personally verified by a human, citing his background in penetration testing as a reason for caution.