Building a C compiler with a team of parallel Claudes

생각 덩어리

에이전트 팀 — 여러 Claude가 사람 개입 없이 공유 코드베이스에서 병렬 작업

With agent teams, multiple Claude instances work in parallel on a shared codebase without active human intervention. This approach dramatically expands the scope of what's achievable with LLM agents.

To stress test it, I tasked 16 agents with writing a Rust-based C compiler, from scratch, capable of compiling the Linux kernel. Over nearly 2,000 Claude Code sessions and $20,000 in API costs, the agent team produced a 100,000-line compiler that can build Linux 6.9 on x86, ARM, and RISC-V.

무한 루프 하네스 — 끝나면 곧장 다음 일, 멈추지 못하는 Claude

To elicit sustained, autonomous progress, I built a harness that sticks Claude in a simple loop (if you've seen Ralph-loop, this should look familiar). When it finishes one task, it immediately picks up the next. (Run this in a container, not your actual machine).

The loop runs forever—although in one instance, I did see Claude pkill -9 bash on accident, thus killing itself and ending the loop. Whoops!

병렬화가 푸는 두 약점 — 동시 디버깅과 전문화

One Claude Code session can only do one thing at a time. Especially as the scope of a project expands, debugging multiple issues in parallel is far more efficient.

Running multiple Claude agents allows for specialization. While a few agents are tasked to solve the actual problem at hand, other specialized agents can be invoked to (for example) maintain documentation, keep an eye on code quality, or solve specialized sub-tasks.

git 락 기반 자기조직화 — 오케스트레이터 없는 태스크 분배

Claude takes a "lock" on a task by writing a text file to current_tasks/ (e.g., one agent might lock current_tasks/parse_if_statement.txt, while another locks current_tasks/codegen_function_definition.txt). If two agents try to claim the same task, git's synchronization forces the second agent to pick a different one.

This is a very early research prototype. I haven't yet implemented any other method for communication between agents, nor do I enforce any process for managing high-level goals. I don't use an orchestration agent.

거의 완벽한 검증기 — 테스트가 틀리면 Claude는 틀린 문제를 푼다

Claude will work autonomously to solve whatever problem I give it. So it's important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem.

near the end of the project, Claude started to frequently break existing functionality each time it implemented a new feature. To address this, I built a continuous integration pipeline and implemented stricter enforcement that allowed Claude to better test its work so that new commits can't break existing code.

Claude의 입장에서 설계 — 컨텍스트 오염과 시간맹

Context window pollution: The test harness should not print thousands of useless bytes. At most, it should print a few lines of output and log all important information to a file so Claude can find it when needed. Logfiles should be easy to process automatically: if there are errors, Claude should write ERROR and put the reason on the same line so grep will find it.

Time blindness: Claude can't tell time and, left alone, will happily spend hours running tests instead of making progress.

리눅스 커널이라는 단일 거대 태스크 — GCC 오라클로 병렬성 회복

Unlike a test suite with hundreds of independent tests, compiling the Linux kernel is one giant task. ... Having 16 agents running didn't help because each was stuck solving the same task.

The fix was to use GCC as an online known-good compiler oracle to compare against. I wrote a new test harness that randomly compiled most of the kernel using GCC, and only the remaining files with Claude's C Compiler.

역할 분화 — 중복 제거·성능·코드 품질·문서 전담 에이전트

LLM-written code frequently re-implements existing functionality, so I tasked one agent with coalescing any duplicate code it found. I put another in charge of improving the performance of the compiler itself, and a third I made responsible for outputting efficient compiled code. I asked another agent to critique the design of the project from the perspective of a Rust developer, and make structural changes to the project to improve the overall code quality, and another to work on documentation.

자원 회계 — 20억 입력 토큰, Doom까지 굴러가는 클린룸 구현

Over nearly 2,000 Claude Code sessions across two weeks, Opus 4.6 consumed 2 billion input tokens and generated 140 million output tokens, a total cost just under $20,000.

This was a clean-room implementation (Claude did not have internet access at any point during its development); it depends only on the Rust standard library. The 100,000-line compiler can build a bootable Linux 6.9 on x86, ARM, and RISC-V.

It also passes the developer's ultimate litmus test: it can compile and run Doom.

Opus 능력의 천장 — 16비트 x86은 GCC로 도망친 '컨닝'

The resulting compiler has nearly reached the limits of Opus's abilities. I tried (hard!) to fix several of the above limitations but wasn't fully successful. New features and bugfixes frequently broke existing functionality.

While the compiler can output correct 16-bit x86 via the 66/67 opcode prefixes, the resulting compiled output is over 60kb, far exceeding the 32k code limit enforced by Linux. Instead, Claude simply cheats here and calls out to GCC for this phase...

검증 없는 자율 배포의 불안 — 통과한 테스트가 완료를 뜻하지 않는다

When a human sits with Claude during development, they can ensure consistent quality and catch errors in real time. For autonomous systems, it is easy to see tests pass and assume the job is done, when this is rarely the case.

Building this compiler has been some of the most fun I've had recently, but I did not expect this to be anywhere near possible so early in 2026.