2025/12/30 4:14
ソフトウェア開発の未来は、ソフトウェア開発者にあります。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
メインメッセージ
大規模言語モデルは熟練したプログラマーの代わりにはなりません。彼らは開発を支援するツールであり、置き換えではありません。
証拠と理由付け
- 43年にわたるプログラミングキャリアが著者に深い歴史的視点を与えている。
- 過去のサイクル―VB/Delphi、マクロ、Executable UML、No‑Code/Low‑Code―は開発者を排除すると約束したが、むしろ需要を増やした。これらのツールは信頼性と決定論的だった。
- 現在のLLMは非決定論的なコードを生成し、バグが多く保守が難しく、チームの速度を遅くすることがある。
- 大規模障害は「AI生成」コードに起因しており、その信頼性の欠如を浮き彫りにした。
- ディクストラは50年前に自然言語で計算論理を信頼的に表現できないと警告し、これはLLMへのプロンプトでも依然として問題となっている。
- 超大規模LLMは構築コストが高く適応性が限られており、長期的な将来性は疑問である。より控えめなAIアシスタント（例：Javaヘルパー）はプロトタイピングやインライン補完に有用かもしれない。
文脈
現在AIが開発者を置き換えているという信頼できる証拠はない。人員の変動はパンデミックによる過剰採用、借入コストの上昇、およびデータセンター投資に起因しており、AI導入ではない。
影響と推奨事項
熟練したプログラマーへの需要は供給を上回る。企業は今すぐ採用し、ポスト・マニア採用波に備え、リードタイムの短縮、信頼性の向上、および変更コストの低減が可能な開発者の育成に投資すべきである。AIツールと実証済みの技術的プラクティスを組み合わせることで、生産性を高めつつリスクを軽減できる。
本文
私は43年間、コンピュータプログラマとして「全てのことを知っている」状態で過ごしてきました――それは電子的にプログラム可能なコンピュータの歴史全体の半分以上に相当します。その期間、数多くの変化を目撃しましたが、いくつかの事実はほぼ同じままでした。
私は「プログラマの終焉」と称されるテクノロジーサイクルを何度も経験してきました。WYSIWYGやドラッグ＆ドロップエディタ（Visual Basic、Delphi）がプログラマの必要性をなくすと噂され、Microsoft Office のウィザードやマクロが同様に予言された。そして実行可能なUML（Executable UML）やノーコード・ローコードプラットフォームも「プログラマ不要」と宣伝されました。現在では、大規模言語モデル（LLM）が、毎日読む記事の中で「プログラマを終わらせる」と語られています。
こうしたサイクルは新しいものではありません。1970年代と1980年代には4GLや5GLが「プログラマの終焉」と称されました。その前にFortranやCOBOLなどの3GL、さらにそれ以前にはA‑0のようなコンパイラで、カードの穴を打ち込むことでコンピュータに命令する必要がなくなると語られました。
もっと昔に遡れば、電子的にプログラム可能なコンピュータの最初期（機密）も同様です。COLOSSUS は物理的に配線を変えるだけでプログラムされていました。そのマシンで働いたエンジニアたちは、最初のストアド・プログラム方式のコンピュータで「本当のプログラマではない」と嘲笑したかもしれません。
すべてのサイクルにおいて予測は極めて誤っていました。結果としてプログラマが減るどころか、より多くのプログラムとプログラマが生まれました――これはジェヴォンズ逆説（1兆5千億ドル規模）の典型例です。
そして私たちは再びそのサイクルに直面しています。「でも今回は違うんだ、ジャスソン！」確かにそうです。前回よりも大きな規模で、Visual BasicやExecutable UMLが全国紙の表紙を飾ったことはなく、4GLに賭ける国全体の経済もありませんでした。
もう一つ重要な違いがあります。以前のサイクルでは技術は信頼性を持って動作していました。VBやMicrosoft Accessでより速く動作するソフトウェアを構築できました。しかしLLMの場合、ほとんどのチームにとって実際には速度低下を招き、ソフトウェアが不安定になり保守性も低下しています。これは多くの場合ロス・ロス（負けたら負け）です（ただし、開発プロセスの真のボトルネックに対処したチームは例外かもしれません）。
しかしこのすべては理論的な話です。技術が実際に多くのチームでポジティブな差を生むとしても、プログラマが不要になるわけではありません。
コンピュータプログラミングの難しい部分は「機械に何をさせたいか」をコードとして表現することではなく、人間の思考――そのあいまいさや矛盾を含む―を論理的で曖昧さのない計算思考へ変換し、それをプログラミング言語の構文に正確に落とし込むことです。カードに穴を打ち、COBOL を入力し、Visual Basic のGUIを実現し（恐らく殺人犯のIPアドレスを追跡するため）、そして今は言語モデルにプロンプトを与えて「見た目が妥当な」Python コードを生成させる―これまでずっと同じ難題でした。
この難問は長年続き、将来も続くでしょう――正確に何を求めるかを知ることです。エドガー・ディジャクスタは約50年前にこう呼びました：英語やフランス語、スペイン語でプログラミングすることは決してないだろう。自然言語は十分に正確で曖昧さのないものへ進化していません。意味的あいまいさと情報エントロピーは常にこの野望を打ち砕きます。
誰でもそのような思考法を学べるかもしれませんが、すべての人が楽しめるわけではなく、得意になる人も限られています。プログラミングスキルを持つ人への需要は常に供給を上回り、企業が数年間採用・訓練を停止すると、その差はさらに拡大します。これまでのバブルと崩壊のサイクルも私のキャリアで頻繁に経験したものです。このサイクルもただのテクノロジーハイプサイクルに過ぎません。
「AI」が実際にソフトウェア開発者を大規模に置き換えているという信頼できる証拠はありません。パンデミック時の過剰採用、借入コストの上昇、大規模データセンターへの投資が人件費から多くを奪っています。「AI」がすぐにでも人間プログラマと同等に理解・推論・学習できる段階になるという根拠はありません。AGI（汎用人工知能）はいつまでも遠い未来の話であり、コンピュータプログラミングの難問は本質的に一般知能を必要とします。
さらに「AI」コーディングアシスタントは以前のサイクルのコンパイラやコードジェネレータとは全く異なります。同じプロンプトでもほぼ同じプログラムが生成される保証はなく、生成されたコードには実際に人間プログラマが認識し対処する必要がある問題が必ず存在します。
私がコードを書くとき、私は頭の中でそれを実行しています。私の内部モデルは単なる構文的なものではありません。私はパターンを照合し統計的に妥当なトークンを予測するだけでなく、実際にコードを理解しているのです。
Cレベルでも、主要な障害やインシデントが「AI」生成コードと大きく結びついているという相関は認識されています。プロンプトが新たなソースコードであり、元モデル入力から全ての稼働システムを再構築できるという主張は間違いだと証明されます。現実は常に勝ちます。
したがって、「AI」がプログラマの終焉を意味するわけではありません。今後1〜3年でこの熱狂が消えるかもしれませんし、結局は再び戻る可能性があります。結局、人々はいつも勝つのです。
「このテクノロジーは永続的に存在しない」と言う人には、これらモデルを構築するコストと膨大な損失を思い出させたいと思います。ハイパースケールモデルから微細化された小規模モデルをローカルで使い続けることは可能ですが、年々プログラミング言語やライブラリのバージョンに縛られると制約が増します。
そのため私はハイパースケールLLMが長期的に持続可能かどうか懐疑的です。彼らは「AI」のアポロ・ムーンミッションと言えるでしょう。結局、コスト対効果を考えれば多くの場合それほど価値がないかもしれません。博物館で展示されるような存在になる可能性もあります。
ソフトウェア開発の近い将来は、「AI」をより控えめに利用するケース（例：Java コーディングアシスタント）でプロトタイプを生成したり、稼働コード上でインライン補完を行ったりする程度かもしれません。しかし重要な場面では必ずやソフトウェア開発者が舵を取るでしょう。ジェヴォンズの仮説を信じれば、むしろより多くの人が必要になるはずです。
雇用主の皆さんへ：今すぐ採用を始めて、この熱狂から目覚めたときに追い付けられないようにしたいと思います。そしてもし「AI」を含む技術的実践で、デリバリーリードタイムを劇的に短縮し、信頼性を向上させ、変更コストを削減できるスキルを育てたいと考えているなら、ぜひご連絡ください。それはウィン・ウィン・ウィンです。