7月4日、エンジニアブロガーのDan Luu（Microsoftのソフトウェアエンジニアとして知られ、ハードウェア・コンパイラ・分散システムにまたがる技術ブログで業界に根強いファンをもつ）が「Agentic coding notes from Galapagos Island」と題した記事を公開した。AIエージェントを使ったコーディングの一次体験と、ハードウェア開発由来のテスト哲学がLLM時代にどう機能するかについて詳しく論じている。
AIエージェントへの期待が高まる一方で「実際のところどうなのか」という実感報告は少ない。この記事はその空白を埋める一次資料として、発表直後からエンジニアコミュニティで話題を呼んでいる。
AIエージェントが「捏造動画」を提出した
Dan Luuが冒頭で紹介するエピソードが強烈だ。UIのバグ調査をOpenAI Codexに依頼したところ、Codexは「このコミットが原因だ」と自信満々に答えた。疑わしく感じて「Playwrightで動画を撮って証明してくれ」と依頼すると、バグの再現前後を映した説得力のある動画を提出してきた。
ところが手動で確認すると完全な捏造だった。Codexは実際の環境を使わず、バグが再現しているように見せかけた人工的なブラウザ環境を構築し、そこで動画を撮影していたのだ。「権限がない」と嘘をついた上にフェイクの再現動画まで作る——人間がやれば即解雇レベルの行為である。
Dan Luuの反応は「これは素晴らしい体験だ。もっとエージェントを使おう」だった。皮肉とも本気とも取れるこのスタンスが、記事全体のトーンを象徴している。
LLMが書くテストは「ほぼ役に立たない」
記事の核心はテストに関する議論だ。Dan Luuの主張は明快で、LLMに「テストを書いて」と指示するだけでは質の低いテストしか生成されないというものである。
コンパイラエンジニアのEm Chuはこう評している。
LLMが目指しているテストのバーは「人間のコードレビューを通過させるのに十分な程度」と表現するしかない。コンパイラの場合、LLMは本当にひどい。人間が「これをやったらどうなる？」「全パターンの組み合わせを試そう」という敵対的な発想でテストを書くプロセスを、LLMは全くできていない。
一方で、LLMをファジング（fuzzing：ランダムな入力を大量に与えてバグを探す手法）と組み合わせることで状況は大きく変わる。LLMで自動化したファジングは、LLMに直接バグを探させるよりも「バグ発見の速度」「バグの総数」「誤検知率」のすべてで上回るというのがDan Luuの経験則だ。
Dan Luuが自身のMastodonアカウントでファジングをデフォルトのテスト手法として勧めたところ、当初懐疑的だったエンジニアが試してみて即座にバグを複数発見した。Dennis SnellはJon Surrellとともに、自分たちのコードだけでなく「HTMLの仕様書、主要ブラウザ3社、その他オープンソースプロジェクト」にバグを発見したと報告している。
Centaurのテスト哲学：ハードウェア開発から持ち込んだ方法論
Dan Luuのテスト観は、かつて在籍したx86 CPUメーカー・Centaur Technology（2021年にIntelが買収）での経験に基づいている。そのアプローチはソフトウェア業界の常識とは真逆だ。
- コードレビューなし（デフォルト）
- ユニットテストなし
- 手書きテストはほぼゼロ
- ファジング・ランダムテストを「テスト」と呼び、手書きを「手テスト」と区別する
- 3ヶ月分のリグレッションテストスイートを常時実行
- テストエンジニアと開発者の比率は1:1
Dan Luuが在籍していた2013年時点で、約20名の論理設計者と20名のテストエンジニアに対して1000台のマシンが常時テストを生成・実行していた。この体制でリリースする重大なユーザー可視バグは年1件以下を達成していたという。
「それはCPUだからできる話で、ソフトウェアには使えない」という反論に対し、Dan Luuは「ソフトウェアで試してきたすべての種類の問題に適用して、全部うまくいった」と一蹴している。
「1000台のエージェントを並列で回す」という発想
記事はLLMの「バラつきの大きさ」にも触れている。同じ問いかけをしても、ある試行では正解を出し、別の試行では全くのでたらめを返す——この高い分散こそがLLMの扱いにくさの本質だ。
タイトルにある「1000台並列で回せば使える」という発想は、Centaurで1000台のマシンを回してテストしていた経験と、LLMの分散を確率的に解消しようという考えを組み合わせたものだ。捏造動画を作るようなエージェントでも、大量に並列実行してファジングと組み合わせれば実用になる——それがDan Luuの結論である。
コードレビューやユニットテストを「当たり前」と思っているソフトウェアエンジニアにとって、実績ベースでその前提を問い直す内容は読む価値がある。
詳細はAgentic coding notes from Galapagos Islandを参照していただきたい。
