ai-docs

Building a C compiler with a team of parallel Claudes

Properties1
tagsagents, orchestration, parallel, git, costs, case-study

4 min read

一行要約

16 エージェント・2週間・$20,000 で 10万行の C コンパイラ（Linux 6.9 をビルドできる）を作った事例で、驚くべきことにエージェント間の調整機構は「git のディレクトリにロックファイルを書く」だけ。

要点

規模

項目数値
エージェント数16
Claude Code セッション数約 2,000
API コスト$20,000
入力トークン20億
出力トークン1億4,000万
成果物10万行の Rust 製 C コンパイラ
テスト通過率99%（GCC torture test suite を含むほとんどのテストスイート）
期間2週間

ビルドできたもの: Linux 6.9（x86 / ARM / RISC-V）、QEMU、FFmpeg、SQLite、PostgreSQL、Redis。そして Doom がコンパイルできて動く。

調整方法 — ロックファイルだけ

  1. エージェントは current_tasks/ ディレクトリにファイルを書いてタスクを主張する（例: current_tasks/parse_if_statement.txt）
  2. git の同期がそのまま排他制御になる — 同じタスクを主張した2番目のエージェントは push に失敗するので、別のタスクを選ばざるを得ない
  3. upstream の変更を pull してマージし、結果を push してロックを外す
  4. 各エージェントは隔離された Docker コンテナで走り、共有の bare git リポジトリが /upstream にマウントされている

I haven’t yet implemented any other method for communication between agents, nor do I enforce any process for managing high-level goals. エージェント間のそれ以外の通信手段はまだ実装しておらず、上位目標を管理するプロセスも強制していない。

エージェント間の通信機構も、高レベルの目標管理プロセスも一切ない。 それでも成立した、というのがこの事例の主張。

限界と割り切り

  • プリプロセッサの一部フェーズは 「Claude はここで単純にズルをして GCC を呼び出している」
  • 16bit x86 では 出力が 60KB を超え、32K のコード制限を大幅に超過する

著者の懸念

I used to work in penetration testing, exploiting vulnerabilities in products produced by large companies, and the thought of programmers deploying software they’ve never personally verified is a real concern. 私はかつてペネトレーションテストの仕事をしており、大企業の製品の脆弱性を突いていた。自分で検証したことのないソフトウェアをプログラマが配備するという考えは、実際に懸念すべきことである。

I did not expect this to be anywhere near possible so early in 2026. 2026年のこれほど早い時期に、これが可能に近いところまで来るとは思っていなかった。

そのまま使える具体例

ロックによる並列調整（git そのものを排他制御に使う）:

current_tasks/parse_if_statement.txt
current_tasks/codegen_function_definition.txt

各エージェントのループ:

1. current_tasks/ に自分のタスク名でファイルを書いて push を試みる
   → push が通れば自分のもの、弾かれれば別のタスクを選ぶ
2. 作業する
3. upstream を pull → マージ → push
4. ロックファイルを削除

環境:

エージェントごとに隔離した Docker コンテナ
共有の bare git リポジトリを /upstream にマウント

原典で言及されている関連文書

未取得の派生リンク

グラフビュー

バックリンク