LLMは実際にプログラマーの生産性をどれほど向上させているのか？
(lesswrong.com)- LLMベースのコーディング支援ツールが登場してから約2年が経過
- 一部の開発者は、生産性が最大5倍から10倍まで向上したと報告している
- しかし、ソフトウェア業界全体の生産性が5～10倍向上したという明確な証拠はない
- 実際には、コードベースに単純なボイラープレート機能を追加する以上の作業では、LLMツールは扱いが難しい
- ほとんどのプログラマーは、LLMツールを効果的に使う方法を知らないか、関心がない
生産性向上が特定のユーザーに集中する理由
- もし生産性が5倍から10倍向上しているのだとすれば、それはLLMをうまく扱える少数のパワーユーザーや熟練開発者に限られる可能性が高い
- ソフトウェア業界全体が急激により多くの有用な機能を提供したり、品質が目に見えて向上したりしている兆候はない
- 筆者はこの1～2年のあいだ、LLMの影響力をほとんど実感していない
実際にLLMがどのようなプロジェクトを可能にしたのか？
- LLMの性能によって実現されたプロジェクトが何なのか、明確には確認できていない
- 研究結果でも具体例はほとんど見つからない（COBOLのリファクタリングがほぼ唯一の例）
- AGI研究所のLLMベース製品も、特に印象的な成果を示していない
- ダイアログボックスでPDFをアップロードできるといった基本機能を提供する程度
- LLMが多様なソフトウェアやデータ型とシームレスにインターフェースする機能は不足している
問い: 実際に生産性が向上した分野はあるのか？
- どのプロジェクトがLLMのおかげで素早くリリースされたのかを示す明確な証拠がない
- ソフトウェアのエコシステムで、特定分野が10倍成長した痕跡も見当たらない
求めているのは明確で実質的な証拠
- 以下のような種類の情報は不要
- 生産性10倍向上についての曖昧な主張
- 抽象的な経済指標やコード生産量増加への言及
- 単純なLLMベースのツールや機能生成の事例
- 「ChatGPTでSnakeクローンを作る」のような些細な例
仮説: LLMは実際の生産性を高められていない可能性
- LLMが生成したコードの修正や問題解決に、かえって時間が費やされる
- LLMが生成した大規模コードベースは、ある複雑さを超えると修正不能になり、結局最初から書き直さなければならない場合がある
- LLMが新しいソフトウェアを作ったとしても、その多くはワンオフのツールや使われない概念実証コードにとどまる可能性が高い
- 実際に有用なソフトウェアでコード量が増えたとしても、不要な機能やブロートウェア(bloatware)が増えるリスクがある
- プログラマーは、LLMによって即座に結果が得られる「魔法」のような体験に惑わされている可能性がある
現実的な生産性向上の範囲
- 筆者の経験では、LLMが有用なのは次のような特定の場合に限られる
- 些細な機能の作成
- 特定ライブラリやコードベースの学習支援
- 簡単なリファクタリング作業の実行
- 生産性向上の幅は、おおよそ10～30%程度である可能性が高い
- 生産性の最大化は、AGI（汎用人工知能）が登場するまでは難しいとみられる
[Richard Horvathのコメント]
特定の状況ではLLMが10倍の速度向上をもたらし得る場合
- 小さな独立型スクリプトを書くこと
- 簡単な作業（例: ファイル操作のためのbashスクリプト、Excel VBAコード）の作成で大きな効果を発揮する
- 短い説明だけで簡単に作成でき、検証もしやすい
- 言語に関する深い知識がなくても書ける
- 保守性、モジュール化、ユニットテストなどを考慮する必要がない
- 特に正規表現(regex)に関する作業で非常に効果的
- 不慣れなスタックで作業するときの学習速度向上
- 新しいライブラリのクラスやメソッドを素早く把握できる
- コードが完全には動かなくても、問題解決へのアプローチを提供してくれる
- 以前はドキュメントや講義を探すのにかかっていた時間を大幅に短縮できる
- ただし、生成されたコードは自分で修正やリファクタリングを行う必要がある
10倍の生産性向上を報告する人たちは、次のようなケースに当てはまる可能性が高い
- 開発知識が乏しい場合
- 基礎的なコーディング能力が不足している場合、LLMの助けで書かれたコードが以前よりはるかによく見えることがある
- しかしこの場合、LLMコードは長期的には悪影響をもたらす可能性が高い
- 小さく独立したソリューションを大量に書かなければならない場合
- Excel自動化やDevOpsでのシェルスクリプト作成などは、LLMが特に有用
- さまざまなスタックやライブラリを頻繁に試さなければならない場合
- 長期的に特定スタックで作業する場合よりも、実験中心の作業が主になるケースに当たる
- アンカリング効果(Anchoring Effect)が生じる場合
- LLMが特定作業で即座に成果を出すと、それを長期的な生産性向上だと過大評価しやすい
[Davidmanheimのコメント]
- 一般的な企業でコーディングする人や経営陣の視点では、LLMによる生産性向上は実際には限定的にならざるを得ない
- これは制約理論(Theory of Constraints) の観点で説明できる:
- 以前は次のような作業プロセスで仕事が完了していたと仮定する:
- ビジネスアナリスト(Business Analyst) → 1日
- QAテスター → 1日
- プログラマー → 1日
- プログラマーの生産性が2倍または5倍になっても、全体の作業時間は短縮されない
- 他の段階（ビジネス分析やQA）がボトルネックになるため、全体プロセスの速度はそのまま維持される
- 以前は次のような作業プロセスで仕事が完了していたと仮定する:
- 企業プロセスの再構成が必要
- LLMの生産性向上を最大限活用するには、企業全体のプロセスを再構成する必要がある
- しかし現在、このようなプロセス再構成に着手している企業は一部に限られる
[faul_snameのコメント]
- LLMでは特にUIモックアップ生成で次のような成果を経験した:
- 以前はUIモックアップ生成が全作業時間の約10%を占めていた
- LLMのおかげでUIモックアップ生成速度が約5倍になった
- しかし、作業時間そのものが減ったわけではない
- その代わり、UIモックアップのディテールとインタラクティブ性が大きく向上した
- より多くの反復が可能になり、結果的に製品の品質が改善した
- 「捨てられるコード」が必ずしも無価値という意味ではない
- プロトタイプや概念実証コードでも、より良い最終製品の開発に貢献し得る
- またLLMは、検索エンジンでは見つけにくい特定のエラーへの答えも提示してくれる
- 例: 「xyzスタックで動作しているジョブで発生したエラーの解決方法」
- 具体的なスタックやKubernetes設定の状況でデバッグを助けてくれる
- 全体の生産性向上率はおよそ**10～30%**程度だと評価している
- ただし、すべての作業で均等に生産性が向上したわけではない
- 特定の作業で飛躍的な速度向上（例: UIモックアップ、デバッグなど）
- 複雑またはレガシーなコード作業では大きな成果はない
- プロジェクト初期には生産性向上が目立つが、複雑な保守段階では効果が薄れる
- したがって、ここでの限界はエージェンシー(Agency)の不足ではなく、コンテキスト管理(Context Management) の問題だと見ている
[Noosphere89のコメント]
- Ajeya Cotra の見解を引用し、LLMによるプログラマー生産性向上効果について次の点を述べている:
- コーディング作業におけるAIの生産性は予想より高い
- AIはコーディング作業でかなりの成果を上げている
- しかし、コーディング以外の作業では性能が大きく落ちる
- そのため、AIの産業全体への影響はまだ限定的である
- コーディング作業におけるAIの生産性は予想より高い
- Ajeya Cotraの関連発言リンク
- 「長期的な成果を出すにはAGIが必要だ」という主張については
- 現在のAIの発展経路には、一般性(Generality)が予想より少ない
- AIの性能が特定作業で急激に向上したり、特定領域で弱点が現れたりすることが多い
- このような性能の不均衡のため、AGI（汎用人工知能）という概念は予想より有用でないかもしれない
[yo-cuddlesのコメント]
- 私のオフィスでロボティック・プロセス・オートメーション(RPA) を担当している人の例
- 彼は自分がはるかに生産的だと強く主張している
- しかし実際には非効率で信頼性も低く、他の人が彼の作業を修正するために時間を浪費している
- 同僚たちは彼をワークフローから外そうとしている
- 人は自分の生産性を正しく測定できず、特定の成果や損失だけを認識しやすい:
- 目立つ成果に注目する
- 自動化された方法で作業を素早く終えると、即時の達成感が大きい
- 速い成果はすぐ目に見えるため、ポジティブな効果として認識される
- 長期的なコストは認識しにくい
- 作業後に発生した時間コストは簡単には追跡されない
- とくに問題を他人が修正した場合、そのコストは見えにくい
- 自動化作業で発生したエラーが修正されても、それによる時間の浪費は実感しにくい
- 目立つ成果に注目する
- LLMコードが引き起こす問題は、次のような理由で認識しにくい:
- バグ発生時に、原因がLLMコードだと正確に追跡しにくい
- 問題を修正する過程で、他の人が追加の時間を浪費することがある
- 問題発生の根本原因を認識できず、自分が自動化ツールを使ったせいだと気づかない
- 「自動化のおかげで早く終わった」という達成感は大きいが、「自動化のせいで浪費された時間」は体感しにくい
- LLM利用が一般化しているにもかかわらず、業界全体の生産性向上が明確に見えない
- 人々は「2倍生産的になった」と主張するが、実際には隠れた問題のためにむしろ生産性が低下している可能性が高い
- つまり、問題解決に費やされた時間やリソースが見えにくいため、成果認識が誇張されている
6件のコメント
私の体験とも似たような感じですね。
上のようなケースでは、かなり多くの時間が短縮されました。Google+Stack Overflowの組み合わせではうまく見つからない場合も多いですし、特にStack Overflowでは、ある回答があってもコメントで異論がいつも多く出たり、古いバージョンの実装方法なので使ってはいけないと言われたり、そういう問題があってイライラすることが本当に多かったのですが...
10倍の生産性というのは、プロトタイピングをするときに出てくるようです
私は甘いですね。
> ほとんどのプログラマーは、LLMツールを効果的に使う方法を知らないか、関心がない
周囲の多くの開発者は、意外にも技術にあまり関心がない。彼らは新しい、あるいは繰り返し流れてくるYouTube Shortsを機械的に眺めることに、ほとんどの時間を費やしている。
Hacker Newsの意見
シアトルの人気テック企業で働いており、AIの使用が半ば強制されている。経営陣は開発者がどれだけAIを使っているかを追跡しており、個人的にAIをもっと使わない理由を尋ねられたこともある。適切なツールを適切な作業に使うことが重要だと考えており、AIが常に適しているわけではない
ソフトウェアプロジェクトの最後の10%が時間の90%を占める、という古い格言がある。AIは最初の90%では有用だが、最後の10%では役に立たない
FAANGでLLMをIDEに統合して使っており、やや前向きな効果がある
実際に10倍の改善を経験した開発者の例として、Pieter Levelsが3Dマルチプレイヤー飛行シミュレーターを数日でコーディングしたケースがある
LLMを使ってコード生成を試みたが、当初は生産性が落ちた
GitHubでCopilot Autofixを開発するチームの一員で、CodeQL警告に基づいて修正提案を提供している
LLMコーディング支援の回答品質は、プログラマーのコミュニケーション能力に大きく左右される
ソフトウェアの生産性が5〜10倍向上していないという前提自体が誤っているのかもしれない
Hacker News意見要約翻訳の最後の項目である「ソフトウェアの生産性は5〜10倍向上していないという仮定は誤りである可能性がある」は誤訳のようです。原文を見ると、「ソフトウェアの生産性が5〜10倍向上したとするのは、生産性向上に関する誤った仮定に基づいている」くらいのほうが、より無難な要約だと思われます。