AI・機械学習
2x、10xではない:2026年のLLMによるコーディング
2x, not 10x: coding with LLMs in 2026 (obryant.dev)
要約
この記事は、2026年における大規模言語モデル(LLM)がコーディング生産性に与える影響について考察しています。LLMは、明確で客観的に検証可能な基準を満たすコード生成において2倍程度の生産性向上をもたらすものの、コードの保守性やドキュメント作成といったより複雑なタスクでは依然として限界があるとしています。著者は、LLMの能力向上だけでなく、既存のモデル能力を最大限に活用するためのワークフローやツールの再構築が、今後の生産性向上の鍵となると予測しています。
全文翻訳
2x、10xではない:2026年のLLMによるコーディング
過去6ヶ月で学んだことは、もしハリー・ポッターがノンフィクションで魔法が実在すると知ったとしても、私の反応は「なるほど、それは興味深い。でも、この魔法はユニットテストを書く以上の複雑なことには役立つの?」という程度だろうということです。LLMは確かに有用性の閾値を超えましたが、2026年7月現在、私の直接の観察に基づくと、依然として根本的な限界があり、「ソフトウェアエンジニア」という職業が絶滅する職業になった場合の代替計画として木工を始めるには至っていません。LLMが有用になった理由についての私のメンタルモデルに基づくと、それがすぐに変わるとは思えません。
私の仮説はこうです。2026年にLLMの採用率が大幅に増加したのは、主に自動フィードバックループで効果的に実行できるほど信頼性が高まったためです。その閾値を超えた今、モデルパフォーマンスのさらなる向上は、以前ほど生産性に大きな影響を与えなくなるでしょう。例えるなら、階段を上るには少なくとも一歩ずつ上れるだけの身長が必要ですが、一度に二歩、三歩と上れるほど背が高いことの重要性ははるかに低くなります。
LLMがコーディングに役立つのは、「Xをするボタンを作成し、そのボタンをクリックしてXをするか確認せよ」と指示できるからです。それらは、無駄な試行錯誤ではなく、意味のあるステップでその目標に向かって反復でき、人間が「はい、ボタンはXをするようになりました」または「いいえ、ボタンはまだXをしません」と言うであろうタイミングを確実に予測できます。そのため、LLMは、あなたが明示的に提供する、容易かつ客観的に検証可能な受け入れ基準を満たすコードを生成するのに役立ちます。そしてそれは信じられないほど、驚異的で、人生を変えるほど素晴らしいことです。おそらく2倍の改善でしょう。
しかし、この仕事には、LLMがまだ十分な精度で予測できない、私の意見では有用とは言えない重要な質問がまだ残っています。例えば、「このコードをより保守的に構造化する方法はありますか?」、「このドキュメントには適切な情報が含まれており、無関係な情報は省略されていますか?」といった質問です。
そのため、私はLLMを主にコードのラフドラフトを作成するために使用し、その後、少なくとも全体的な構造が気に入るまで、大幅に反復します。個々の行や関数の可読性については、少しずさんでした。(同僚がこの記事を読む可能性があるので、この注意書きは含める必要があります)。そして、行レベルでのずさんさをもってしても、その反復にどれだけの時間がかかるかを常に過小評価しています。動作する実装がかつてはタスクの80%完了を意味していましたが、今では20%程度です。
ドキュメントに関しては、LLMの出力を大幅に改善する簡単な指示を見つけました。README、docstring、コメントは絶対に書かないでください。後で自分で書きます。そして、本当にそうします。
これらの限界に対する合理的な反応として、「LLMは過去1年で大幅に改善したので、来年のさらなる改善でドキュメントや保守性の高いコードを書く能力が大幅に向上するだろう」と言うかもしれません。しかし、私の階段の仮説を受け入れるなら、その反応ははるかに不確かです。高い階段を上れるからといって、泳げるわけではありません。
したがって、私の現在の推測では、モデルの改善だけでは、2025年の暗黒時代からの10倍の生産性向上には到達しない可能性が高いということです。代わりに、予見可能な将来の生産性向上のほとんどは、私たちが今日すでに持っているモデルの能力を中心に業界が再編成されることから生まれると考えています。
私はこの分野の早期採用者ではありません。これまでのところ、LLMを単なる検索エンジン/Stack Overflowの代替(RIP)として使用することから、対話型チャットでコードを書かせること、そして私が望む最終状態の宣言的な仕様を書くことへと移行しました。サンドボックス化された環境もMVP(Minimum Viable Product)となり、30秒ごとにLLMに何かを実行する許可を与える必要がなくなりました。これらのワークフローとツールの洗練には、まだ多くの作業が必要です。
また、仕事や本番以外のものについては、バイブコーディング(「すべてを読んだり理解したりせずにコードを生成すること」と定義しています)も行いました。仕事以外でもこの分野をさらに探求することに興味があり、もちろん他の多くの人々が熱心に先駆けています。長期的な実現可能性がどれほどあるかはまだわかりません。なぜなら、まだ長期が存在しないからです。
しかし、何かがあるかもしれません。特定のテストプラクティスやツールが、たとえ運用クリティカルインフラストラクチャであっても、ブラックボックスLLMコードに依存することを安全にするかもしれません。LLMの根本的な弱点を回避することで、10倍の改善を達成できるかもしれません。しかし、それまでの間、私は手作りのREADMEにこだわり続けます。
公開日 2026年7月25日