AI：加速する無能化
(slater.dev)- ソフトウェアエンジニアリングで LLM に過度に依存すると、短期的な速度は上がっても、批判的思考と問題解決能力が弱まる可能性がある
- 誤った出力よりも大きなリスクは、欠陥のあるプロンプトをそのまま受け入れ、その結果として技術的負債とユーザーの能力低下が急速に積み上がることにある
- LLM は現在のコンテキストウィンドウを超えてプログラム理論を記憶したり内面化したりできないため、設計と保守に必要な共有メンタルモデルは人間のエンジニアの領域として残る
- 複雑性は保守の過程で増え続け、テキストレベルのトークン予測器である LLM は、不要または奇妙な変更によってプログラムエントロピーを高める可能性がある
- AI はツールとして使えるが、松葉杖のように依存してはならず、2019年にも価値があった基礎的なエンジニアリング能力と深い思考に投資し続けるべき
LLM 依存が生むエンジニアリング上のリスク
- LLM を「友だち」のように呼ぶ態度は、実際の伴侶というより、ユーザーに利益をもたらすという婉曲表現に近い
- こうした見方をするエンジニアは、たいてい速度を優先するか、速度を優先するよう圧力を受けている
- LLM は多くのコードを素早く作れるが、その利用にはロングテールのリスクが伴う
コード生成で現れる5つのリスク
-
出力リスク
- LLM はコンパイルできないコードのように、明らかに間違った結果を出すことがある
- さらに危険なのは、論理バグのように微妙で検出しにくい誤った結果である
- プロンプトを書いた人が結果を評価する資格を持たない場合、リスクは大きくなる
- 例として、プロジェクトマネージャーがソースコードを求める状況が挙げられている
-
入力リスク
- LLM は誘導的な質問、誤った前提、不完全な文脈を含むプロンプトに異議を唱えない
- たとえば「C# でスレッドセーフなリスト実装を提供せよ」という依頼には、200行のもっともらしいコードが出てくるかもしれないが、実際の問いは「このコードをスレッドセーフにするには？」かもしれない
- この場合、答えは
System.Collections.Concurrentを使う1行のコードかもしれない - LLM は依頼されていないため、XY Problem の事例だと認識できない
-
将来の速度低下
- LLM はコードベースの品質を非常に速く低下させる可能性がある
- 強力なガードレールがなければ、LLM 生成コードは外見上は問題なく見えても、内部は不衛生で機能しない空間のようになり得る
- これは一般的な技術的負債の議論よりも緊急性の高い問題として扱われる
-
ユーザーの幼児化
- 思考と問題解決を LLM に委ねる個人や組織では、才能が失われる可能性がある
- シニアエンジニアは、生産的な苦闘を通じて学ぶ機会を失い、問題解決力と批判的思考が弱まる可能性がある
- ジュニアエンジニアは、そうした能力を最初から育てられず、その後に未来のジュニアをメンタリングすることも難しくなる
- ThoughtWorks Technology Radar Volume 32 は、AI による自信が批判的思考を犠牲にする場合があると扱っている
- Coding as Craft: Going Back to the Old Gym は、コーディングを工芸として保つための意図的な AI 協業を強調している
- Thoughts on Thinking は、LLM は完成された考えを与えることはできても、自ら発展させる知的成長は与えられないと見ている
-
楽しさの喪失
- 多くの開発者が、AI の利用によってフロー状態と創作の楽しさが奪われると報告している
- AI 生成コードは、読んで変更するのがつらいコードになり得る
- 関連記事として The Hidden Cost of AI Coding がリンクされている
LLM が代替できない2つの能力
- 熟練エンジニアが AI によって不要になるのではないかという懸念に対し、LLM が提供できないプログラミング能力は2つに整理される
- その能力はプログラム理論とプログラムエントロピーである
プログラム理論：コードはプログラムそのものではない
- Peter Naur の Programming as Theory Building は、プログラミングを問題に対する洞察や理論を形成する活動と見ている
- Naur の観点では、プログラムはソースコードではなく、共有された精神的構成物、すなわち理論または設計である
- コードはその設計から派生するが、価値ある成果物はコードよりも設計にある
-
2チームの思考実験
- 同じ能力を持つ2つのチーム A と B が、互いにコミュニケーションできない別々の部屋にいる
- A チームはターミナルベースのチェスゲームのようなプログラムを書き、B チームは待つか実際にチェスを指す
- A チームが終えた後、ソースコードが B チームに渡され、両チームとも仮想チェスプレイヤーのような機能を追加しなければならない
- より良い解法を出すのは A チームである
- A チームは、たった今作ったプログラムの新鮮なメンタルモデルを持っている
- B チームにはそのようなモデルがない
- プログラムは初期作成後も継続的に修正されるため、ソースコードだけがあり、設計に対する内面化された理解がなければ、変更コストは高くなる
- 大きな既存コードベースに初めて入ったとき、生産性がほぼゼロに近く、プログラム理論を頭の中に読み込むにつれて生産性が上がる経験と結びつく
-
LLM とプログラム理論
- 現在の LLM はコンテキストウィンドウの先を記憶できないため、理論、設計、精神的構成物を習熟できない
- プログラム理論を獲得し維持できる存在は人間である
プログラムエントロピー：複雑性を減らす、またはそれに抵抗する能力
- 複雑性はプログラミングに立ちはだかる根本的な力であり、エントロピーと関係している
- Fred Brooks の The Mythical Man-Month は、プログラム構築をエントロピー低減の過程、保守をエントロピー増大の過程と見ている
- Brooks の観点では、初期構築後のプログラム変更は、ソースコードをより複雑にせざるを得ない
- ただし、設計と調和する変更は複雑度の増加速度を遅らせることができる
-
LLM とプログラムエントロピー
- LLM はトークン予測器であり、テキストレベルでのみ動作する
- LLM はアイデア、図、要求仕様のような概念レベルでは推論できない
- 大きなコードの塊を LLM に入れたことがある人は、LLM が不要で奇妙な変更を適用する傾向を見ることになる
- 会話が長くなるほど、結果はさらに逸脱し得る
- コードの複雑性を減らしたり、複雑性に抵抗したりする能力は人間にある
エンジニアリングにおける AI の使い方
- AI がエンジニアリングのキャリアを次の段階に引き上げてくれると期待していたなら、逆に作用する可能性がある
- LLM は無能化を加速し得るが、人間のエンジニアリングを代替することはできない
- AI の事業上の魅力は、エンジニアリングをコモディティ化してコストを下げる点にある
- ただし海外のエンジニアリング人材活用が混在した結果をもたらすように、LLM も限界とリスクを伴う
- AI のハイプサイクルはいずれ頂点に達する可能性がある
- 今 AI を過度に使う企業はロングテールのコストを背負うことになり、方向転換するか消える可能性がある
- エンジニアリングにおける人間の長期的な価値提案は変わらない
- 世界は今も技術能力と深い思考を必要としている
- そうした能力に対して対価を支払うだろう
- AI は残り続けるが、ツールとして使うべきであり、松葉杖のように依存してはならない
- 2019年に価値があると考えられていた基本的なエンジニアリング能力に投資し続けるべき
1件のコメント
Hacker Newsの意見
AIコーディングをめぐる議論は、ソフトウェアエンジニアとデータサイエンティスト／機械学習エンジニアの違いを反映しているように感じられることがある。
どちらも不明確な要件や見つけにくいバグを扱うが、一般にソフトウェアエンジニアは常に特定の方法で動作すべきソフトウェアを作り、再現性やテスト、成熟したツールが重要になる。
一方、機械学習エンジニアは本質的に確率的なモデルを扱い、テストも特定の出力を出すかどうかより、「90%のケースで正しい出力」といった評価指標が中心になる。
そのため、常に信頼できるわけではないAIを扱う考え方は機械学習側にはより自然で、「80%は正しいので手間を減らせて、残り20%は自分が拾えばよい」というようにコーディング支援ツールを評価することになる。
Amazonで働いていたときは、古典的なアプローチがない現実の問題に、機械学習ベースの解法がうまくはまることが多かった。たとえば格子地図ベースの運動予測や画像／格子地図分類は、既存の推定・制御パイプラインにうまく統合され、有用だった。
逆にあるスタートアップでは、静止した平面の向きを時間とともに推定する問題に学習ベースのアプローチを疑ったという理由で、下級マネージャーからずっと叱責されていた。チームがマッピングやフィルタリングの基本を知らず、「データをもっと入れれば解決する」と仮定していたため、車両制御パイプライン全体が、ちらつき跳ねる任意の回転推定値を食わされていた。
この隔たりは実際に大きく、面接でもっと見分ける方法があればよいと思う。
以前、会社のシニアアーキテクトが会議後に不満を漏らしているのを聞いたことがある。うちの会社の製品は精度と正しさが常に大きなセールスポイントだったのに、別オフィスの機械学習チームはそれを理解せず、80〜90%の精度なら顧客には十分だと考えていた。
パンデミック疾患の致死率1%は小さいのか大きいのか、という議論を思い出す。1は最小の整数だが、3億人の1%は300万人だ。
ただし、この文章はその話だけではないと思う。ソフトウェアエンジニアリングをする人々が持つメタレベルの懸念と、AIがそこにどう当てはまるかを扱っており、「プログラムのエントロピー」と言うときに核心を突いていると思う。
ソフトウェア製品を作る仕事の大きな部分はエントロピー管理だ。コードと人を増やしながらも適切な前進速度を保ち、全員が部品同士がどう噛み合い、新しい部品をどう足すべきかを理解できるようにする必要がある。いつかAIがこれを容易にするかもしれないが、今はむしろエントロピーを悪化させることが多い。
利害関係者たちが「そうではない、AIはすべてにすぐ使える」と説得しようとしなければ、大きな問題にはならなかったはずだ。
この前提は、論理で反論することさえ難しいほどばかげているが、これまでは巨額の投資を引き出し、収益重視の人員最適化を包み込む信仰ベースの物語としては非常に成功してきた。
記事の前提とほとんどの具体的な論点には強く同意するが、日常でLLMを使いながら、良い面も見ている。ちなみにソフトウェア業界で30年ほど働いてきた。
AI生成コードを扱うと、コードを読むことになる。開発はゼロから創造する旅というより、一連のコードレビューに近くなり、ソロ開発者にとっては、チームでしか学びにくい責任を疑似的に体験して身につけられるという利点がある。
また、LLMと働くには、開発者が問題を明確でよく構造化された階層として理解していなければならないことがすぐに分かる。大きなものを一度に頼むとたいてい自滅するので、設計の観点からアプローチし、詳細な仕様を書き、部分ごとに実装するやり方は、概念的なブロックの境界とインターフェースを定めるのに役立つ。
LLMは、ジュニア開発者がシニアの役割へ成長するのを助ける強力なアクセラレーターと見なせる。適切な案内があれば、より経験豊富な人々が時間をかけて学んだ教訓の進行過程を見せてくれる。すべてが暗いとは思わないし、AIが開発者を置き換えることもないだろう。今は非常に破壊的だが、最終的にはほかのツール群のどこかに落ち着くと思う。
LLMの助けで作られたコードをレビューすると、より味気ないコードを読むことになるとも言えるが、それでも学びはあると思う。LLM生成コードをたくさん読んできたし、慣れていないイディオムや知らなかったライブラリ呼び出しをよく学ぶ。
シニア開発者にとっても、LLMはさらに強力なアクセラレーターだ。何が存在し、何を試す必要がないかを知っているので、よりうまくプロンプトできる。
最近のニュースを見ても、Big Tech、中堅テック企業、小規模テック企業でレイオフが続いている。
3Dプリンティングがあらゆる製造を置き換えると言われていた頃を覚えている？
AIはシンギュラリティというより、この空気感に近い
LLMが何かを改善したというより、システム上の欠陥を露呈させただけだとも見られるが、影響そのものは明らかだ。2年前には標準的だった何十もの講義の進め方が、もはや機能しなくなっている
特にオンライン・遠隔教育全体がこれに含まれるが、皮肉なことに、多くの大学がCovid後にそこへ投資し始めたまさにそのタイミングでChatGPTが登場した。世界中の高等・中等教育領域全体に及ぶ規模の影響だ
航空宇宙は良い例だ。SpaceXやこの分野の若いスタートアップが行っている多くのことは、3Dプリント部品なしには実現できなかっただろう。ノズル、燃焼室、ターボポンプのような部品はよくプリントされている
それでもこの比較は公平ではないように思う。機械工学をやっていた頃、3Dプリンティングはより速く安く試作品を作り、失敗できるようにしてくれたので、むしろ自分のエンジニアリング能力を高めてくれた
あらゆる製造を置き換えたわけではないが、設計では重要な役割を果たしており、利用者の能力を退化させるものではなかった
LLMはコードを書くのには驚くほど優れているが、そのコードを所有し保守するのはひどく苦手だ
理解せずに受け入れたすべての行は借り物の理解であり、保守のときに高い利息を払って返すことになる。無料のスピードのように感じるが、実際には年40%ほどの利息が付く技術的負債に近い
私たちの集団は、AIでタイピングは自動化しつつ、思考は自動化しない方法を見つけなければならない
しかしそうではなく、仕組み上そうなることもできない
したがって、理解せずに受け入れたLLMのすべての行は、実際には存在しない理解である。確率モデルが吐き出したコードの1行にすぎず、コードベースの文脈・システム・設計を実際に理解できる存在が見るまでは、理解されていない状態だ。現在、そのような存在として知られているのは人間だけだ
従来の開発ではどちらもあまり好きではないが、現在のLLMはその両方をより簡単で有用にしている
そして「三度目の法則」は、コンポーネント間では事実上適用が止まる。コードの影響が局所的であるか、非常に堅牢な基盤ライブラリの一部であるかのどちらかでなければならない。中間的なケースはリファクタリングの複雑さを爆発させる
「LLMは誘導的なプロンプトに異議を唱えない」という入力リスクが、これまでで最大の苦痛だった
さらにもどかしいのは、自分が特定の方向へ誘導していることにさえ気づかない場合がある点。LLMの動作を考えれば筋は通っているが、曖昧に書かれた単語ひとつだけでも結果が悪い方向に偏り、自分が望んだこととは逆に進んで、誤ったウサギ穴にはまり込むことがある
気づいたときには、なんとか辛うじて動いている、場当たり的につぎはぎされたコードの泥沼の真ん中にいる。人間の言語は非常に曖昧で非特定的なので、そもそも精密さを許す規則ある形式言語を発明したのと、ほとんど同じことだ
個人的には、AIツールのせいで能力が急速に衰えている感覚もあった。かつては怠けて小さな作業のたびにAIに手を伸ばしていたが、一歩引いてみると時間もそれほど節約できておらず、むしろ数十行・数百行のコードを読んで、AIがどう間違っているのか考えて直すせいで、ずっと早く疲弊していた
測定したわけではないが、全体としてはAIツールで節約した時間より、浪費した時間のほうがはるかに多かったように思う
本当の問題は、AIが多くの作業で実際に有用である一方で、使う人が二種類いることだ。一方は、小さなミスが急速に積み重なる複雑な作業に使う人で、もう一方は主に管理職タイプで、理解していないコード200行を吐き出すのを見て、辛うじて動くTODOアプリ程度を「MVP」だと考え、「これを作れるのだから、君の仕事も簡単にできる」と思ってしまう人だ
私の使い方が悪かったとか、モデルが間違っていたとかいうお決まりの答えをするなら、これらのツールに関する私の経験の文脈として、以前のコメント https://news.ycombinator.com/item?id=44055448 を先に読んでもらえるとよい
つまりAIは私の助手だが、品質が高く保守可能な成果物を出す責任は私にある
ただし一般的な観点で見れば、素朴な電卓を考えればよい。電卓は人々の暗算能力を損なった。AIは文章を書く力やコミュニケーション能力、問題解決能力などに対して同じことをするだろう
モデルはプロンプトの流れのどこかにある特定のキーワードに固執し、従来の論理を捨て、本来の問題すらまともに解けない、より狭い道へ押し込んでいるように見える。結局、人間側の苛立ちと不幸だけが増える
能力の退化を防ぐため、もともとStackOverflow検索で解決していたような小さく明確な作業にだけAIを使うようにしている。「Xはどうやるのか？」を検索する代わりにモデルに同じ質問をし、その答えを正解ではなく問題解決の手引きとして使う
それでも、今日のAIがより簡単にしてくれることはある。たとえば「このページのように作って、ただしyの代わりにxのデータを使って」のように使える例がある場合は、ドキュメントを探すより速いことが多い。幻覚する可能性があるという但し書きはあるが、時間とともに改善する可能性も高い
見たい改善は、全体的により正確になることに加えて、毎回言わなくても最も単純な解法を探すことだ。ChatGPTやClaudeなどを自由に使わせたときの最大の欠点は、ゴミを高速に大量生成し、「これは後で扱うには複雑になりすぎる」と言って止まらない点にある。原文は、全体設計を理解する人間だけがエントロピーに抵抗できると主張しているが、この部分が永遠に改善されないかどうかはともかく、今もっとも大きな問題のように感じる
第1ラウンドでたいていモデルが置いている主な仮定が明らかになり、そこから絞り込みながら明確にできる
いろいろ試したという以前のコメントを読んだところ、LLM経験は私よりずっと広そうだった。ただこの技法は見当たらなかったので、誰かの役に立つかもしれないと思って残しておく
「アイデア、図、要求仕様を推論できない」「複雑さを減らせるのは人間だけだ」といった言葉は、興味深い概念の後ろに明らかに間違った細部の主張が付いているケースのように見える
これはとても簡単にできる。もっと単純なコードを求めればよい。私は第二の意見を得る用途でよく使っており、良い結果を得ている
モデルに問い合わせなければ、複雑な答えも単純な答えも得られない。デフォルトの選択肢として問い合わせるのも選択であって、LLMという概念に内在するものではない
コードとアイデア・図を相互に変換する用途にもよく使っている。人々が日々実務で反証している強い主張を、なぜするのかわからない
この記事は一見正しいが、詳しく見ると持ちこたえない奇妙な論理も繰り返している。Naurの話はいまやミームになり、現実で洞察であるかのように繰り返されているが、ソフトウェアエンジニアリングのもう一つの根本的で実用的な規則を忘れている。つまり、些細でないプログラムはすぐに、一人が全体の理論を頭の中に収められる能力を超えてしまうということだ
私たちは、ほとんどまともなプログラム理論を持たずに仕事をしている。プログラミング言語、技法、方法論、ツールはすべて、人々が大半のコードを理解しなくてもよりよく働ける方向へ発展してきた
この点では人間もLLMと同じ限界を共有しており、ただ私たちは別の観点を得るためにもう一度の推論ループを許されるまで待つ必要がないので、よりうまく管理できているだけだ
Google Maps や Apple Maps のような地図技術にも、同じような論理を適用できると思う。こうしたツールを使うと、物理世界を探索する能力、方向感覚や地理感覚が衰えるという主張だ
実際、間違っているわけではない。最近の人は Google Maps のような支えなしでは道を探すのに苦労することが多く、物理世界との関わり方もさまざまな面で変わった
しかし昔から、多くの人が特に道案内が得意だったわけではない。とりわけ見知らぬ場所で A 地点から B 地点まで安全かつ安定して移動する平均的な能力は、確実に大きく向上した
そして地理や道案内に天賦の才がある少数の人は、Google Maps のようなツールによって能力を代替されたのではなく、補完された
AI も、より大きな規模で似たような結末になると思う。確かにトレードオフはあり、一部の技術や能力は低下するだろうが、はるかに多くの人が以前はできなかったことをできるようになり、少数の人は自分の仕事をさらにうまくできるようになるだろう
もちろん常にそうとは限らない。世界中をマッピングするのは、無数の例外や境界ケースを伴う非常に複雑な作業だからだ。しかし LLM の出力と比べると差は大きい。温度を 0 にして同じプロンプトを何度も再生成しても、出力は大きく変わる
また LLM ははるかに広い概念領域を扱うため、人々は本来そうしてはいけない多くの状況で、自分の頭の代わりにそれを使うようになるだろう。地図だけを見ても、Google Maps が道だと言うからといって湖に車で突っ込む人がいるのに、LLM の出力を盲信して自分の思考を置き換えたときに何が起きるのか、想像もつかない
私の住んでいる場所では、Google Maps は 90% の場合タクシー運転手より優れている
AI は、その仕事を数日やったことがある人よりも優れていない
現実的には、従業員の 70% は仕事があまりに雑なので、AI がしばしば同程度、あるいはそれ以上にできてしまう
本当に難しいのは、雑にやっていた人たちは AI を使っても相変わらず役に立たず、残りの人たちは AI とともに学び成長するという点にある
完全自動運転も似ている。FSD はひどい、酔っている、またはメールを打っている人間の運転手よりは優れており、道路にはそういう運転手が多い
「[AI] は概念レベルで作業できない」という感覚を、著者がどこから得たのか気になる
最近の LLM が繰り返し示しているのは、たとえば文脈に応じてある言語の概念を別の言語へ正しく翻訳するように、明らかに概念レベルで作業できるということだ
人間のように概念を「理解」していないという話は別だ。苦痛を経験していないので苦痛を「理解」できないかもしれないが、人間も自分が直接経験していないことについて絶えず語っている。それでよいのかは別の話だ
これは、関連性のような概念の一部の特徴に対する弱いモデルだ。たとえば「dog」は「cat」と関連している。しかし合成性、内包、反事実条件文において用語が果たす役割のようなものはモデル化しない
ただし質問が訓練データに似ていれば、見かけ上の概念能力を力ずくで得ることはできる。誰かが「犬たちは火星で遊んだら幸せだろうか？」のような質問、または十分に似た質問群をしていたなら、「dog」を「文字通りの事実」クラスタや、すでに知られている反事実の一部のクラスタの周辺に置くことができる
これと本物の精神能力の違いを見るには、任意の深さの概念の組み合わせは無限であり、無限の数の反事実で構成されうるという点を見ればよい。基本構成要素と想像力だけを持つ子どもは、この無限の多様性を評価できる
だから LLM は、必要な「概念作業」が非常によく文書化され、十分に安定している狭い分野、特にソフトウェアエンジニアリングで最もよく使われているのだ
90s.dev を AI のないコミュニティに変えるべきだという思いがますます強くなっている。ソフトウェアをうまく書く古代の技術に集中し、その技術を磨いてきたすべての人を歓迎する場所だとよい
始めるには何が必要だろう？ フォーラム？ メーリングリスト？ hackernoon のように複数著者のブログを集める方式？
関心のある人向けの暫定メーリングリストは https://github.com/sdegutis/90s.dev/issues/2 に作ってあり、この話題のメールを受け取りたいなら購読するかコメントすればよい
フォーラムは LLM とボットのせいで壊れてしまったので、その選択肢は外れる。こういうものが機能するには招待制でなければならず、各推薦者が自分の招待ツリーに責任を持つべきだ
コミュニティは、アクセス権を失うことが良い行動を促すほど魅力的でなければならない。オンラインの特定のコミュニティでは、この方式は非常にうまく機能している