AIコードのレビューは有効な主張ではない

著者のThomas Depierreは、LLM（大規模言語モデル）のソフトウェア開発における有用性に懐疑的な立場をとる。その理由は、知的財産権の問題や環境・資源消費の問題、あるいは単に「すべてが駄目だから」というわけではなく、科学的事実に基づいている。彼は、LLMコーディングアシスタントがどのようにしてコードをより良く、より速く書く助けになるのか、その証拠を見いだせないのだ。

彼を苛立たせるのは、LLMコーディングアシスタントの推進者が、この問題や証拠にほとんど触れずに自らのツール選択を擁護することだ。さらに悪いことに、彼らが懐疑論者を反駁しようとするたびに、かえって彼の主張を強化しているように見える。そこで彼は、問題の核心、それを支持する実証研究、推進者がどのように反論できるか、そして実際には彼らが逆のことをしている現状を分析する。

Depierreは、LLMコーディングアシスタントの根本的な問題は、エラーを起こすリスクが比較的高いことだと指摘する。幻覚、タイプミス、要求と無関係な処理など、様々な理由で間違える。多くの開発者は、これを「インターンのようだ」と表現する。つまり、多くを期待せず、彼らの成果は多かれ少なかれ間違っていると想定すべきだ。そして、その解決策としてよく聞かれるのが「すべてをレビューすればよい」というものだ。しかし、Depierreはこの主張に疑問を呈する。

まず、「レビュー」の実際の意味を明確にする必要がある。業界で一般的な「軽量で分散されたレビュー」は、知識共有や表面的なルールの確認には有効だが、LLMが生成したコードの監視には不十分だ。本当に必要なのは、しっかりとした「コードレビュー」であり、1時間以上かけて1行1行をチェックするような形式ではないが、それでもかなりの集中力を要する。

ここで問題となるのは、コードレビューに関する実証研究の知見だ。レビュー時間が1時間を超えると、どれだけコード量が少なくても効果は急速に低下する。また、効果的なレビューの速度は最大でも400行/時間程度であり、それを超えると欠陥発見率が著しく下がる。つまり、LLMコーディングアシスタントが生成した400行のコードに対して、シニア開発者が1時間のレビューを要し、週に10～40回のレビュー枠しかない（さらに回復時間も必要）。会議や設計などの他のタスクを考慮すれば、実際の生産性は1日あたり数千行程度に過ぎず、多くは見込めない。

さらに悪いことに、人間がLLM生成コードをレビューする場合、人間が書いたコードをレビューする場合よりも欠陥発見率が低い可能性が示唆されている。レビューアはより自信を持っているにもかかわらず、実際に見つける欠陥は少ないのだ。したがって、「ただレビューすればよい」という主張は、生産性の限界を無視しているだけでなく、その効果自体も疑わしい。

Depierreはさらに、LLMコーディングアシスタントの支持者が、最もレビューが難しいコード（例えばBashスクリプト）こそLLMに任せるべきだと主張している点を批判する。Bashは構文が緩く、意味的に過負荷で、ちょっとした句読点の間違いが致命的な結果を招く可能性がある。まさにレビューが最も困難なコードを、ランダムに間違えるLLMに書かせて、レビューでカバーできると考えるのは矛盾している。

最後に、著者は自分を納得させるにはどうすればよいかを提案する。彼は、人間がLLM生成コードをレビューする能力、速度、および1日あたりの限界についての実証研究を求めている。そのようなデータが示されない限り、彼は懐疑的な立場を変えるつもりはない。この記事は約1年前に書かれたため、一部の用語は現在のものと異なるかもしれないが、核心的な論点は今も有効である。