How a C Compiler Was Built with a Parallel Claude Team

16 instances of Claude were combined into a parallel agent team to build a Rust-based C compiler from scratch and use it to build the Linux kernel 6.9. This experiment consumed about 2,000 Claude Code sessions, 200 million input tokens, 14 million output tokens, and cost around $20,000.

The key was harness design rather than the model itself. Instead of using Claude as a single conversational session, the author put it into an infinite loop where it moved on to the next task after finishing one, and had each agent choose its own small unit of work. To prevent conflicts, each agent locked tasks via files under current_tasks/, then used a simple synchronization approach of pulling upstream, merging, and pushing.

The author emphasizes that for this approach to work well, tests need to be nearly perfect. Since Claude follows whatever verifier it's given, inaccurate tests lead it to solve the wrong problems. So the author observed repeated failure modes and added new tests, and later in the project introduced a CI pipeline and stricter break-prevention safeguards to reduce cases where existing functionality broke.

Output design also mattered for agents to operate independently. Logs weren't printed verbosely but saved to files, and errors were written on a single line with ERROR plus the reason attached, making them easy to find with grep. Progress was shown only intermittently, and a --fast option ran only 1% or 10% samples so that the model, which has no sense of time, wouldn't get stuck on a single task for too long.

Parallelization worked best when different failure points could be assigned to different agents. When many tests were failing, each agent could pick up a different failing test, but for something like the Linux kernel—a single massive target—all agents would collide by getting stuck on the same bug. To solve this, the author used GCC as an online known-good compiler oracle, splitting the work so that most of the kernel was compiled with GCC and only the remainder with the Claude compiler.

Role division was also central to parallelism. One agent cleaned up duplicate code, another improved compiler performance, and yet another refined the efficiency of generated code. A separate agent critiqued the project structure from a Rust perspective, and another handled documentation.

The resulting compiler was about 100,000 lines in scale, with fairly broad functional coverage. This compiler can build a bootable Linux 6.9 on x86, ARM, and RISC-V, compiles QEMU, FFmpeg, SQLite, postgres, and redis, and showed a 99% pass rate on several compiler test suites. By the developer's own standard, it could also compile and run Doom.

However, the limitations were also clear. A 16-bit x86 code generator was never directly implemented, so GCC had to be invoked for x86 real mode booting, and the assembler and linker weren't self-implemented either, remaining incomplete to the end. The quality of generated code fell short of GCC's, and as more features were added, existing functionality kept breaking repeatedly—revealing that this system was approaching the limits of Opus's capability.

Ultimately, what this experiment showed is that the success of long-horizon autonomous development depends far more on environment design, test quality, task decomposition, and feedback loops than on the model's standalone intelligence. Today's agent teams can already push fairly complex projects forward autonomously, but without equally strong quality assurance and safeguards, they can just as easily head in the wrong direction.