- LLMコーディングツールの頻繁な誤りは人がすべてレビューすればよい、という解決策は、コードレビューの処理限界のため、品質と生産性を同時に保証しにくい
- 実証研究によれば、効果的なレビューは1回あたり1時間・400 LOC程度が上限で、これを超えると疲労と集中力低下により欠陥検出効果が急速に低下する
- この基準を適用すると、LLMが書いた400 LOCごとに熟練開発者の集中的なレビュー1時間が必要となり、現実的な1日の処理量は1,000 LOC未満になり得る
- 人間はLLM生成コードで欠陥をあまり見つけられない一方で、より強い確信を示すという初期的な証拠があり、レビューだけで誤りを十分に排除できるとは考えにくい
- LLMコードの欠陥検出率・レビュー速度・1日あたりの持続可能量を直接測定し再現する実証研究があってこそ、ツールの実効性を逸話ではなく根拠で判断できる
LLMコーディングツールを懐疑的に見る理由
- 問題の焦点は、知的財産権、生態学的コスト、資源消費、あるいはLLMの出力がすべてひどいという評価にあるわけではない
- 現在の科学的根拠だけでは、LLMコーディングツールが開発者のコードをより良く、あるいはより速く書く助けになる仕組みを確認しにくい
- 擁護論は関連する問題や証拠を直接扱っておらず、懐疑論への反論がむしろ問題を強めることもある
- 約1年前に書かれた文章のため、現在ではほぼ置き換えられたCoding Assistantsという表現を使っているが、生成AIの多様なコーディング用途をすべて包含する別の用語が見つからないため、そのまま維持する
「インターン」比喩と全面レビューという解決策
- LLMコーディングツールは、動作構造やインタラクションインターフェースなどの理由から、比較的高い誤りリスクを持つ
- ハルシネーションやタイプミスを生むことがある
- 要求と無関係な結果を出したり、別の経路で作業を進めたりすることがある
- ユーザーはこうしたツールをしばしばインターンにたとえる
- 結果はある程度間違っていると予想すべきである
- 何をしているのか十分に理解しないまま作業していると見なすべきである
- 広く使われている対処法は、インターンやジュニア開発者のコードと同様に、熟練者が結果をすべてレビューする方式である
- 人間のほうがよく理解しており、最終責任も負うという前提に基づく
- コードベースに入るすべてのコードは本来レビュー対象だ、という理屈も続く
LLMの監督に必要なレビュー水準
- 業界と研究文献におけるレビューは、互いに異なる複数の実務を含んでいる
- 軽く、複数人に分散されたレビューは、変更内容に関する知識共有や表面的なルールの適用には有用だが、LLMコードを監督する基準としては不十分である
- 過去の委員会式レビューのように、何時間もかけて全行を苦痛のうちに確認する必要まではないが、かなり深く完全なコードレビューが必要である
- LLMは複雑なコードを書け、ソフトウェアの細部に欠陥が潜むため、軽い確認だけでは不十分である
コードレビューが直面する実証的な限界
- 実証研究で確認された効果的なレビューの主な限界は次のとおりである
- 1回のレビューセッションが1時間を超えると長すぎる
- その時間で効果的にレビューできる量は最大400 LOC程度である
- 1時間を超えたレビューは、コード量に関係なく効果が急速に逓減する
- すでに大半を見終えたからだけではない
- 高い集中を1時間維持すると、疲労や退屈が生じ、休憩が必要になる
- 1時間のセッション間に必要な回復時間を調べた研究は見つからない
- 極端な上限として、1日に数回を仮定できる
- 平均的に可能な回数として1日2回程度が提案されるが、確定した数値ではない
- 1時間あたりにレビュー可能なコード行数は、コードの文脈や種類、レビュー担当者の経験と知識によって大きく変わる
- 絶対的な基準ではないが、400 LOC/Hより速いレビューで欠陥を効果的に見つけて指摘した事例は実証データでほとんどなく、これを実効的な最大速度と見なせる
LLMコードに適用した処理量の計算
- LLMコードの問題をレビューで解決するには、最良の場合でも生成された400 LOCごとに熟練開発者1時間が必要である
- 開発者に許容されるレビューセッションは週あたり約10〜40回で、各セッションの間には長さ不明の回復時間が必要である
- 回復時間は少なくとも1〜2時間かもしれないが、これを裏づける直接研究はない
- こうした集中時間は、会議、設計、障害対応、直接書くコードについての思考にも使わなければならない
- 最良の条件では、LLMを使う開発者が書いてレビューしコミットできる量は1日あたり数千LOCである
- 現実的なシナリオでは、1日の処理量は1,000 LOC未満になり得る
- これにはボイラープレート、テスト、マイグレーション、設定ファイルがすべて含まれる
- 単一のテストファイルでも400 LOCを超えることがある
- コードの大部分が単純でレビューしやすい最良条件でも、レビューが生産性向上の上限として作用する
人間のコードとLLMコードのレビューの違い
- 既存の根拠は、人間が書いたコードの欠陥を人間のレビュアーが見つける状況から得られたものであり、同じ効率がLLMコードにも適用される証拠はない
- 初期的な証拠では、LLM生成コードをレビューした人はより少ない欠陥を発見しながら、すべての欠陥を見つけたという確信はより強まる傾向が見られる
- 人間の作者と人間のレビュアーの組み合わせより、LLMコーディングツールと人間のレビュアーの組み合わせのほうが、より低品質な結果を生みながら、後者のレビュアーが自分の成果をより高く評価する可能性がある
- 全面レビューはLLMの生産性上の利点を制限するだけでなく、頻繁な誤りを実際に解決するという確かな根拠も乏しい
欠陥修正以前から発生するコスト
- この計算には、発見した欠陥を修正するコストは含まれていない
- 専門開発者が業務環境でコードをレビューし、問題を指摘する能力とコストだけを扱っている
- LLMが作った欠陥の数や深刻度に関係なく、生成コードをレビューするコストは発生する
- LLMコーディングツールが非常に高品質なコードを生み出したとしても、すべての結果をレビューするという条件では同じコストと生産性の限界が残る
レビューしにくいコードを任せるという矛盾
- LLM擁護論は、人が書くのが苦痛なコードをツールが代わりに生成できることを利点として掲げる
- ある事例では、今後必要な**Bashコードの100%**をLLMに書かせることが提案されている
- シェルスクリプトは構文解析が緩く、意味が過度に重なり合っているため、句読点1つのタイプミスが無害なこともあれば、コンピュータ全体を削除する結果につながることもある
- こうしたコードは誤りを生みやすく、理解やレビューが難しく、致命的なミスに気づくのも難しい
- ランダムに誤りを出すツールに最もレビューしにくいコードを任せ、その後で人間が確認すればよいというやり方は、LLM出力が本当に効果的なレビュー対象なのかをまず証明できていない
- レビューが誤りを解決するのか、十分な生産性向上が残るのかに答えないまま、最もレビューしにくいコードを代表的な活用事例にすることが問題である
検証すべき実証課題
- 第1の課題は、人間のレビュアーがLLM生成コードの欠陥をどの程度うまく見つけられるかを測定することである
- 欠陥検出能力
- レビュー速度
- 1日を通じて持続できるレビュー量
- 人間が書いたコードを対象とした研究と同様に、人間がLLMコードをレビューするデータが必要である
- 既存の実験と実証データは規模と文脈が限定的であるため、さらなる再現研究が求められる
- 現在の科学的データは、人間がLLMの結果をうまくレビューできないか、その問題を検出しにくい方向を示している
- LLMが検出回避するよう訓練されるという特性と一致する可能性がある
- 既存の結果が偶然だった可能性も検証しなければならない
- 第2の課題は、LLM生成物のレビューが人間の書いたもののレビューと質的に異なる問題なのかを確認することである
- 既存のコードレビュー研究が適用できないほど差が大きければ、現在の批判論理は崩れる可能性がある
- ただし初期的な証拠は、LLM生成コードのレビューが容易というよりむしろ難しい可能性を示しており、この場合、批判はむしろ強まる
逸話ではなく専門ツールの実証評価
- コードレビューについて分かっている事実を踏まえると、現在のインターフェースと手順を使うLLMツールが専門開発者にどんな利益をもたらすのかは確認しにくい
- ベンダーが根拠と衝突するツールや手順を繰り返し提供すること以上に、問題を扱わないまま懐疑論者を異常視する態度のほうが大きな不満の対象である
- TDD、型システム、テストと開発組織の分離、CI/CD、DevOpsでも、実証的証拠より逸話が優勢になる傾向が繰り返されてきた
- 「今回は自分には効果があった」という事例に頼るのではなく、コードレビューの実証的根拠が作られた方法にならって、実際の研究を行うべきである
- LLMコーディングツールを専門的な開発ツールとして扱うなら、人間工学と実証的証拠を中心に効果と限界を検証しなければならない
1件のコメント
Lobste.rs の意見
速さだけが唯一の目標である必要はない。バグ修正は別の準備コミットとして切り出して独立にレビューし、不正な状態を表現できてしまう型構造を直し、テストの信頼性が足りなければプロパティベーステスト・ファジング・形式手法を試せる
以前ならこうした作業を1つのコミットに詰め込むか、技術的負債の TODO として残していたが、今ではきちんと実装するための限界費用が驚くほど低くなった。LLM はオープンな道具なので、ユーザーが重視する価値に応じた効用を返してくれる
ただし、完成しないまま本番運用に到達しないプロトタイプが増えるリスクもあるが、全体として厳密さを重視するエンジニアリングには大いに役立つ
会社文化の問題かもしれないが残念であり、業界が目を覚まして、より高品質なソフトウェアを作るようになることを望む
過去のプロジェクトにエージェントを単一のプロンプトで投入すると、大きな労力なしに実際のバグを次々と見つける。人間も雑だし自分もミスをするが、LLM は速い一方で多くの面でより愚かなので、その問題が早く露呈するだけだ
ミスは蓄積するため、エージェントにやみくもにコードを変更させるとすぐに壊れるが、素朴な使い方が不安定だからといって道具そのものが役に立たないと見るのも怠惰な判断だ
今は変更のたびにアーキテクチャ、保守性、信頼性・セキュリティなどを含む専門レビュー5件を自動実行し、設計文書体系として整理することで、エージェントの意思決定を大きく改善している。完璧ではないが素朴なやり方よりはよく、さらに改善の余地がある点も新しい道具を扱う面白さだ
プロンプトでより速く生成しても、検証して理解するのに余計な時間がかかり、最初から自分で書いたほうが速かったのではないかと考えてしまう。どちらがよいか判断すること自体にも時間とエネルギーがかかり、そのリソースを別のところに使いたい
ただし PR 提出者が所有権と責任を負うなら、LLM を使ったかどうかは重要ではない。品質・正確性・一貫性の基準を満たすなら、より速い方法を選べばよく、責任は人間の作者にそのまま残る
個人的には、AI は学習し理解を広く深くするにはよいが、入力時間だけでなくプロセス全体を考えると、まだ自分でコードを書くほうが生産的だ
この記事がほぼ1年前に書かれたという点からして問題だ。直近6か月、特に直近3か月で、最新の有料クラウドモデルの有用性は大きく高まった
監査業務で発展させたMFIC 原則のように、失敗カテゴリ全体を防ぐ統制手段があるかを確認すべきだ: https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
既存コードとプロジェクト構造をコンテキストに保つ https://github.com/pmarreck/dirtree や https://github.com/pmarreck/codescan のようなツールも必要で、これはコードベースを忘れた、または慣れていない人間の開発者にも有用だ
結局、これを適切に活用して利点を得るか、自分でカスタムコードを書きながらバグやセキュリティ脆弱性も作り、より速い競合に追い抜かれるかだ。Desk.com の廃棄された百万行規模の Ruby on Rails コードベースに2人年を費やした立場から言えば、企業コードは一時的なので LLM 生成コードと相性がよい
Erlang の内部実装なら信用しにくいだろうが、関数単位で書かせてからレビューすることはでき、時には期待以上かもしれない。編み針と織機のどちらか一方だけを選ぶより、状況に応じて両方使うのが理想だ
個人的な経験と周囲の信頼できる熟練開発者たちを見ると、LLM はよりよく、より速いコーディングを繰り返し可能にしてきたので、科学的証拠上は役に立ち得ないという記事を真剣に受け止めるのは難しい
査読付き論文がなくてもすでに十分見ており、METR の研究 1本が開発者たちの生産性向上の見積もりに反論したからといって、既存の判断を変えるつもりはない
厳密で方法論的に妥当な形で、既存の堅固な実証研究とどこが違うのかを示してくれれば、考えを変える用意はある。だが個人的経験や説明のない逸話が十数個あっても不十分だ
科学と工学は数十億人の生活を改善してきたので、誰かが自分のほうが優れていると信じているという理由で、それを捨てることはできない
個人をカルト信者と呼ぶつもりはないが、信念への挑戦を個人的に受け止める一方で、他人を説得する方法は分からないという態度は、カルト集団のコミュニケーション様式に似ている
ほとんど LLM で作られた PR でも提出者が責任を負い、他の人が理解しやすいコンテキストとサイズに分けるべきだ。コードは依然としてソフトウェアの最終仕様であり、開発者が所有し理解しなければならないという事実は変わらない
1年前に AI エージェントが多くのミスをしていたという主張は正しいが、今もそうかは不明で、昨年11月頃に最前線モデルの転換点を体感した
LLM がコード量を増やし、レビュー能力に新たな圧力をかけるのは事実だが、エンジニアはこれにブレーキをかけ、レビュー量が実際の処理能力に見合うよう保証すべきだ
さらに悪いのは、新しいコードがたいてい動くため、整理されないままマージされる可能性が高いことだ
最前線モデルが膨大な量のコードを書くにもかかわらず、コードを削除しようと提案する負の貢献を真剣に探求していない点が不思議だ。“The Best Code is No Code At All” - Jeff Atwood のように、抽象化レイヤーで肥大化したコードベースの複雑さを解きほぐし、行の削除を提案できるなら新鮮だろう
すでに可能かもしれないが、まだ自分では見たことがない
訂正すると、「The Limits Of Reviews」の節は効率的な最大速度を時間あたり400行としており、最初に思ったレビュー1件あたり400行ではなかった
ただし、1時間と400行という数値が正確にどのコードレビュー論文から来たのかは今も気になる。論文名を別に保存していないなら、探し直すのに多くの時間を使う必要はない
今は旅行中なので、数日後にもう一度知らせてほしい
週40時間のうちレビュー比率が25%なら時間あたり約540行、15%なら900行、5%なら2,700行だ。実際の処理量は時間あたり500〜1,000行程度と推定され、出典が示されていない数値とある程度近い
AI 生成コードだからといって、人間が書いたコードより多く、または少なくレビューすべきだという論理は理解しにくい。承認基準は同じなので、同じ水準でレビューする