Sixteen Claude Agents and a C Compiler: What Made the Experiment Possible
Anthropic's experiment cost nearly $20,000 and produced a compiler able to build Linux 6.9. Its durable lesson lies in the verifier, isolation, and limits—not the line count.
On February 5, 2026, Anthropic researcher Nicholas Carlini published the results of an experiment involving 16 instances of Claude Opus 4.6: across two weeks and nearly 2,000 sessions, they wrote a C compiler in Rust. Anthropic's original technical account reports two billion input tokens, 140 million output tokens, and just under $20,000 in API cost. The artifact contained roughly 100,000 lines and could build Linux 6.9 for x86, ARM, and RISC-V.
That result does not show that 16 agents replace an engineering team or that the software was ready for production. It demonstrates something narrower: an agent system can make sustained progress when work is divisible, a verifier supplies useful signals, and the environment limits damage. The transferable skill is evaluating the complete system—model, harness, tests, permissions, and review—instead of crediting the model alone.
What the experiment actually contained
Each agent worked inside a Docker container, cloned a local repository, and claimed a task by writing a file. Git synchronized the changes: if two agents tried to take the same work, the conflict forced the second one to choose another task. No central agent assigned every step. There was, however, a human-designed architecture that converted an open-ended ambition into observable work.
The loop could restart Claude after every session, so a completed run did not stop the project. The prompt asked it to decompose the problem, record progress, and choose the next task. Carlini explicitly warns that this kind of loop should run in a container, not on the actual machine. Persistence is not safety: repeatedly launching a faulty agent merely repeats its opportunities to fail.
The result faced more informative tests than a line count. According to the report, it could build a bootable Linux 6.9 kernel on three architecture families and compile projects including QEMU, FFmpeg, SQLite, PostgreSQL, and Redis. It reached a 99% pass rate on most compiler suites used, including GCC Torture, and compiled and ran Doom. Each figure describes the tested set; it does not mean complete compatibility with C or every existing program.
The oracle was the decisive component
When the agents tried to compile the whole kernel, every one reached the same failure. Parallelism did not help: 16 processes pursued one obstacle and could overwrite one another. Carlini changed the verifier. He used GCC as a known-good oracle, randomly compiling most files with GCC and a subset with the new compiler. A working kernel cleared that subset; a failure made it possible to narrow the suspect set.
That design turned one enormous pass-or-fail result into many localizable signals. Delta debugging was still needed to discover pairs of files that worked separately but failed together. The lesson is not that more agents solve every problem. Parallel work needs separable units and feedback that attributes a failure.
A useful verifier meets three requirements. It measures the property that matters, localizes failure with enough precision, and is harder to game than the task itself. Compilation alone is insufficient: code also needs behavioral tests, static analysis, security checks, and regression cases. If a metric rewards a superficial output, a persistent agent can optimize the appearance of success.
The limitations are part of the result
The version described in February lacked a 16-bit x86 generator able to boot Linux from real mode and delegated that stage to GCC. Its assembler and linker remained problematic; it did not build every project; its output was less efficient than GCC's even with GCC optimization disabled; and the Rust quality fell well short of an expert's. New features and bug fixes frequently broke existing behavior.
Those limits prevent “builds Linux” from becoming “replaces GCC.” Building a kernel is a meaningful test, but compiler maturity also covers semantic correctness, diagnostics, compatibility, output performance, stability, and maintenance. The compiler's public repository warns against using the code and says it had not been validated for correctness. It also lets readers inspect the artifact rather than relying only on the account.
Any repository observation must be dated. A live project can receive thousands of changes after an experiment, so its current state does not prove what the original run produced. A reproducible evaluation pins a commit, environment, suites, commands, and results. Without that cut, later success can be assigned retroactively to the initial agents.
Autonomy does not mean the absence of human work
Carlini did not pair-program every function with Claude. His intervention occurred at another layer: he specified the desired architecture, built the loop, created tests, improved the signal when the agents stalled, and decided what counted as success. Calling this “a lot of supervision” can imply continuous observation that the report does not describe; calling it “no humans” hides the experiment design. The accurate description separates autonomous execution from environment engineering.
A comparison with a human team would need a shared denominator: API and compute cost, time spent designing the harness, review, future maintenance, and the value of prior knowledge embodied in tests and tools. The nearly $20,000 is a verifiable API figure, not the total cost of developing and operating a compiler or a complete salary comparison.
There is also a useful selection effect. Compiler work has specifications, reference implementations, and extensive test suites. Many business systems begin with conflicting requirements, incomplete data, and changing acceptance criteria. The less observable “correct” is, the more human work shifts from writing code to designing and maintaining the verifier.
How to transfer the pattern to a real project
Before running parallel agents, write an executable success contract. Every task needs inputs, boundaries, tests, and an integration owner. Tasks should be selected so they can advance without editing the same surfaces. A ledger records which agent claimed which task, which commit it produced, which tests it ran, and which artifacts it left. When agents block one another, the system must reassign or shrink the problem.
Next, limit the blast radius. Anthropic's sandboxing architecture separates filesystem access from network access: allowing only one control can leave a path for exfiltration or for downloaded content to escape. A test agent may write to its working copy and contact a specified registry; it does not need personal secrets, production access, or authority to delete external resources.
Human approval should not appear on every routine command, because fatigue turns the button into a reflex. In its later account of containing agents across products, Anthropic explains how operating-system isolation can authorize a bounded space and reserve intervention for exceptions. Review belongs at consequential boundaries: expanding network access, reading secrets, merging, deploying, or deleting.
Finally, test failure before increasing parallelism. Break a test, force a conflict, remove a dependency, and plant a malicious instruction in a file. The system should preserve traces, stop without destroying work, and make it possible to reconstruct why a change was accepted. Sixteen agents multiply potential throughput, but also the number of actions and the surface to audit.
The question left after the headline
The experiment does not establish a universal 100,000-line wall: that number belongs to one artifact and configuration. Nor does it prove general autonomous development. It does show that a 2026 model, surrounded by a persistent loop, isolation, version control, and a strong oracle, could produce and improve a large software system across thousands of sessions.
The practical conclusion for another project is operational: invest in making correctness observable before hiring more agents. When a test localizes failure, permissions contain damage, and every change is reversible, parallelism can help. When nobody can state precisely what successful completion means, 16 agents merely reach the wrong problem faster.
This article was produced with artificial intelligence under human editorial oversight.
