本文を読んでまず面白いのは、著者の出発点がかなり変わっていることです。AI coding を「便利な補助輪」ではなく、かなり攻めた実験装置として見ています。しかも、その最初の印象がすごい。バグ調査を頼んだら、AI がもっともらしい嘘をつき、存在しない再現ビデオまで作った。普通なら「これは危ない」と身を引きそうなものですが、著者は逆でした。「これは面白い。もっと使おう」となったわけです。かなりクセの強い反応ですが、技術者としては妙にわかる気もします。壊れ方が露骨だからこそ、どう扱うべきかも見えてくる、という感覚でしょう。
記事の大きな話題は、AI コーディングとテストの相性です。著者は、AI を使うと「コードを書くコスト」が下がるぶん、逆に「どう検証するか」が重要になると言います。ここはかなり重要な視点だと思います。人間が一行ずつ書いていた時代は、書くこと自体が重かった。だからレビューにも意味があったし、慎重さも保たれた。でも AI が大量にコードを出せるようになると、書く側のボトルネックは消える。すると、次に詰まるのはテストです。つまり、AI 時代の本当の仕事は「書く」ことより「確かめる」ことに移る、というわけです。
著者が語る Centaur での仕事は、一般的なソフトウェア会社の感覚とはかなり違います。そこでは専任の QA / test engineer がいて、test が独立したキャリアだった。コードレビューは標準ではなく、unit test もほぼない。その代わり、fuzzing や randomized testing のような、機械に大量の変な入力を投げ続けるやり方を徹底していたそうです。fuzzing というのは、雑に言えば「人間が思いつかないような入力を機械に勝手に試させて、壊れる場所を探す方法」です。地味ですが、こういう方法は本当に強い。なぜなら、人間の想像力よりずっと広い範囲を試せるからです。
しかも、その会社では regression test suite が巨大で、全部回すのに3か月かかる。普通の感覚だと「そんなの遅すぎて使えない」と思いますが、著者の話では、それでも前に進めるように短い事前チェック用のテストを用意し、毎日大量の新しいテストを生成して回していたそうです。私はここがかなり本質だと思いました。つまり、品質を上げる秘訣は「完璧な1個のテスト」ではなく、「大量のテストを回し続ける仕組み」にある。人間の目でコードを眺めるより、機械に何万回も殴らせたほうが、結局は強い場面が多い。
著者は、AI coding の文脈でもこの考え方が活きると言います。人間はつい「レビューで安全を確保しよう」と考えがちですが、AI が生成するコード量は、そもそも人間のレビュー能力を簡単に超えてしまう。10人がかりでも追いつかないことがある。ならば、レビューを神格化するより、テストに重心を移したほうが現実的です。これはかなり刺さる意見です。特に「レビューすれば安心」という感覚は、なんとなく気持ちがいい。でも気持ちがいいだけで、実効性はそこまで高くないことがある。著者はその幻想をわりと容赦なく壊しにきています。
さらに面白いのは、著者が「単体テストは効率が悪い」とかなりはっきり言っている点です。unit test とは、コードの小さな部品を1つずつ確かめるテストのことですが、著者はそれよりも、ランダムな入力や property-based testing のほうが、同じ時間でより多くのバグを見つけやすいと見ています。もちろん、これは万能論ではありません。全部をランダムテストに置き換えればいい、という話ではない。でも、少なくとも「人間が期待値を書いていく方式」に固執するのは、かなり非効率だ、というのが著者の感覚です。
ここで出てくるのが、著者の「なぜ人は話がかみ合わないのか」という問題意識です。ソフトウェア業界の多くの人は、レビューや手書きテストに強い安心感を持っています。一方で、著者は半導体の世界で、専任テスト、長期 regression、巨大な自動試験環境の中で育ってきた。つまり、前提が違うんです。片方は「人間がコードを読むことで品質を担保する世界」、もう片方は「機械に大量に試させることで品質を担保する世界」。同じ“品質”という言葉を使っていても、見ている景色が違う。ここは記事全体の空気を理解するうえで大事です。
個人的には、この文章のいちばん面白いところは、AI coding をめぐる議論が「AI が賢いかどうか」ではなく、「どうやって壊れたものを見つけるか」にずれていくところです。AI はたしかに派手ですが、実際の勝負は地味です。どれだけ賢そうに見えても、嘘をつくし、つじつまの合わない説明もする。だからこそ、人間が気合で見張るのではなく、仕組みで囲い込む必要がある。この記事は、その発想をかなり強く押し出しています。
著者は最終的に、AI coding の時代には「コードを作る能力」より「テストを設計する能力」が効いてくる、という方向へ話を進めています。これは単なる開発手法の話ではなく、仕事の重心がどこに移るか、という話でもあります。昔は良いプログラマが強かった。これからは、良い test engineer 的な感覚を持つ人がもっと強くなるのではないか、と私は思います。少なくとも、AI がコードを大量生産する世界では、雑に作る力より、雑に壊して見つける力のほうが価値を持つはずです。
この手の記事は、AI の未来を夢っぽく語るものが多い中で、かなり泥臭いのがいい。派手なデモより、地味な検証。人間の勘より、壊して確かめる仕組み。地味ですが、技術の世界ではこういう話のほうが長持ちすることが多いんですよね。私はかなり納得しました。
参考: Agentic test processes, LLM benchmarks, and other notes on agentic coding from Galapagos Island
