AI：加速する無能化

(slater.dev)

5 ポイント投稿者 GN⁺ 2025-05-29 | 1件のコメント | WhatsAppで共有

ソフトウェアエンジニアリングにおいてLLMへの過度な依存は、無能化を急速に促進する
LLMには、批判的思考や問題解決能力を代替できない限界がある
LLMの利用には、誤った出力、入力の誤り、コード品質の低下、開発者能力の低下、創作の楽しさの喪失など、さまざまなリスクが伴う
LLMは、プログラム理論やプログラムエントロピーのような本質的な開発能力を提供できない
長期的には、技術力と深い思考力がこれまで以上に重要である

はじめに

2022年末に大衆的な注目を集めたAIとLLMの登場以降、多くの議論が続いている
経験豊富なソフトウェアエンジニアとして、LLMに関して観察した主要な問題点を2つ語る

「LLMは私の友人」という見方

LLMを最高のツールと見なすエンジニアは、速度を最優先の価値に置くようになる
LLMで大量のコードを素早く生成できるが、これは長期的なリスクを内包している

LLM利用のリスク

誤った出力のリスク: LLMは、明らかに誤ったコード（コンパイル不可能）や、微妙な誤りを含むコード（ロジックバグなど）を生成する
- 評価能力のない人材がソースコードを求めると、不適切な回答を受け取る可能性が高い
誤った入力のリスク: LLMは、誤った前提や文脈が不足したプロンプトを批判しない
- 正しい問いを見分けられず、XY問題（根本原因の把握失敗）にも共感できない
将来の開発速度の低下: LLM導入は技術的負債を急速に増大させ、内部的に混乱して保守困難なコードベースへと変質させる
ユーザーの未熟化リスク: 問題解決や思考力を伸ばす機会が失われ、開発人材の能力劣化が加速する
- シニア開発者はより深い問題解決経験を得られず、ジュニア開発者はそもそも実力を積み上げられなくなる
創作の喜びの喪失: LLMベースのコーディングは没入（flow）状態と創作の楽しさを奪い、AIが作ったコードを読んで変更する作業には苦痛が多い

「AIのせいで職を失うのか？」という懸念

その可能性は非常に低い
LLMが代替できない開発能力が2つ存在する。プログラム理論とプログラムエントロピーである

プログラム理論

Peter Naurが主張したように、「プログラミングとは設計理論を構築する活動である」
- ソースコードは実質的な成果物ではなく、**集合的理解（理論）**のほうが重要である
- 同じ実力を持つ2つのチームに同じ問題を与え、コードだけを引き渡した場合、自分たちで作ったチームのほうがはるかに効果的に機能追加を行える
- 慣れていないコードベースでは生産性が低いが、内部の設計理論を理解するほど徐々に生産性は上がる

LLMとプログラム理論

LLMは文脈内記憶しか持たないため、真のプログラム理論や深層的な設計を内在化できない
- 実際、コーディングの真の本質（設計と理論の構築）を獲得できるのは人間だけである

プログラムエントロピー

Fred Brooksは、**複雑性（エントロピー）**こそがプログラミングの根本的難題だとした
- プログラムの保守は複雑性を増大させ、最高の実装であってもシステムを不可逆的な老朽化へと向かわせる

LLMとプログラムエントロピー

LLMはテキストレベルのトークン予測しか行わず、アイデア、設計図、要件のレベルで意味的思考ができない
- 長い対話や大きなコードの塊を扱うほど、不要または奇妙な変更を繰り返し、複雑性を増すばかりである
- 複雑性を減少させたり、それに抗ったりする作業は人間だけが可能である

結論

2人の先駆者の洞察をもとに、ソフトウェア設計と複雑性の本質を再確認する
AIが開発キャリアを向上させてくれると期待するなら、むしろ無能化が加速する可能性に注意すべきである
豊富な経験と熟練した実力を持つ開発者として、LLMは人間のエンジニアを代替できないと認識しなければならない
AI導入の事業的魅力はコスト削減だが、実際には新たなリスクを招き、過度に利用すれば長期的な追加コストと組織リスクが積み上がる
技術力と深い思考力の重要性は長期的に変わらず、AIは道具として活用しつつ、2019年にも重要だった本質的な能力に引き続き投資すべきである

次回予告

今後の投稿では、各リスクに対する具体的な解決策を扱う予定である

参考文献

Leading Question: https://en.wikipedia.org/wiki/Leading_question
The XY Problem: https://en.wikipedia.org/wiki/XY_problem
ThoughtWorks Technology Radar Volume 32: https://thoughtworks.com/content/dam/…
Coding as Craft: Going Back to the Old Gym: https://cekrem.github.io/posts/…
Thoughts on Thinking: https://dcurt.is/thinking
The Hidden Cost of AI Coding: https://terriblesoftware.org/2025/04/23/the-hidden-cost-of-ai-coding/
"I wonder if I'll become redundant": https://reddit.com/r/ExperiencedDevs/…
Programming as Theory Building: https://pablo.rauzy.name/dev/naur1985programming.pdf
Grug on Complexity: https://grugbrain.dev/#grug-on-complexity
Gartner Hype Cycle: https://en.wikipedia.org/wiki/Gartner_hype_cycle

1件のコメント

GN⁺ 2025-05-29

Hacker Newsの意見

ときどき、AIコーディングに関する議論はソフトウェアエンジニアとデータサイエンティスト／機械学習エンジニアの違いを反映していると感じる、という経験の共有
ソフトウェアエンジニアは常に予測可能でテストに通るソフトウェアを作ることを期待されており、ツール類もはるかに発達している
一方で、機械学習エンジニアにとっては確率的モデルで作業するのが当たり前の日常であり、普段のテストも特定の出力より指標中心の評価が多い
そのため、AIが常に信頼できるわけではない点により慣れている
コーディングアシスタントも、80%だけ正解を出してくれれば残りの20%は自分が見つければよい、という考え方で向き合う
自分の経験でも、半分くらいは同じように感じたという共有
Amazonで働いていたときは、古典的なアプローチがない問題にMLベースのソリューションが非常に有用だった
しかしあるスタートアップでは、基本的なフィルタリングやマッピングの理解もないまま学習ベースのアプローチだけに固執し、停止した航空機の姿勢推定でひどい結果を繰り返していた
MLとSWエンジニアの間のこの溝は明確で、採用プロセスでそれをもっと見えやすくする方法があればよいのに、という願い
今の空気感では、MLEマインドセットが他のグループにも無理やり適用されているように感じる
正確さと正しさが核心の製品を売る会社で、ML側のチームは80〜90%で十分だと主張し、それに対するアーキテクトの不満を目撃した
パンデミックにおける致死率1%の議論の例のように、小さなパーセンテージでも大きな影響を与え得ることを思い出させる
決定論的(Deterministic)な動作と確率的(Probabilistic)な動作の違いへの言及
この記事はAIとソフトウェアエンジニアリングに関するメタな悩み、つまりプログラムのエントロピー(Entropy)管理に焦点を当てている
エントロピー管理はソフトウェア製品構築の非常に大きな部分であり、AIがいつかこの部分を簡単にできるようになるかもしれないが、今はむしろエントロピーをさらに悪化させることが多い
現在AI（特にML）の修士課程にいて、SWEとして新しい筋肉を鍛えているところ
MLEをSWEのより広い視点から見て、堅牢なパイプライン構築、モデル統合、デプロイなど全体の理解が必要
しかし、ほとんどのMLE純粋専攻者にはSWE視点が欠けており、コンピュータ的な感覚なしにMLだけ理解していることが多い
本当のフルスタックになるには、低レベルシステム、構造、デプロイに加えてMLEまで理解することが必須
なのに市場の採用はほとんどSWEかMLEの博士だけを求めており、これを全部わかる自分に報酬を提示してほしいという意欲
ソフトウェアエンジニアたちも実際にはかなり確率的思考を適用している
たとえばレースコンディションの再設計や、DB呼び出しのp99予測、A/Bテストなど
記事の主張には全体として共感するが、LLMを使う中で生じた前向きな変化も見つけた
30年の経験を持つシニア開発者として、AI生成コードを読む必要があるということは、開発がコードレビュー中心の流れへ移ることを意味する
これは個人開発者にとっても、チーム単位の責任感やコードを読む経験の学習に役立つ
またLLMをきちんと使うには、問題の階層構造を理解する力が必須
セクションごとに詳細に設計して実装することが、自然とインターフェースや境界の定義に役立つ
LLMはジュニアがシニアへ成長する速度を加速させる触媒であり、経験豊富な開発者の学びを追体験できるよう助けてくれる
AIが開発者を置き換えることはなく、最終的には道具として溶け込んでいく
- いつも、書くコードより読むコードの量のほうが多いべきだと思っている
  LLM生成コードは単調かもしれないが、それも学習機会ではある
  LLM生成コードから新しいイディオムやライブラリ呼び出しなどを多く知るようになった
  シニアであるほどよりよいプロンプトを与えられるので、LLMはさらに強力な触媒として働く
- AIはまずプロトタイプレベルのコードを作ってくれるコピペ用途としては非常に良いが、レビューなしのコミットは不可
- 企業の立場では、AIがジュニアを助けるのではなく、ジュニア採用をなくし、シニアにAIで10倍の生産性を要求するきっかけになっている
  ビッグテック・ミッドテック・スモールテックを問わず人員削減が続いている
AI論争を、かつての「3Dプリンティングがすべての製造を置き換えるのか」という考えと似た文脈にたとえる
AIはシンギュラリティというより、こうした現実的な変化に近いという主張
- 3Dプリンティングは本当にクールで革新的な技術だが、射出成形は依然として残っている
- 3Dプリンティングはシンギュラリティを呼び込まないが、大学教育など知識労働の現場ではAIがすでに大きな影響を与えている
  以前は当然だった講義／課題／授業の進め方が、LLMの登場によって世界的に急速に変わっている現実の共有
- 3Dプリンティングは航空宇宙や宇宙など多くの産業で大きな変化と革新をもたらした例
  SpaceXがなければ実際に不可能だった領域が多かった
- Bitcoinが銀行を置き換えるという期待とも似ている
  結局、銀行がBitcoinベースの金融商品を売る形で出てきた
- 3DプリンティングとAIはまったく異なる成長曲線を持っている
  3Dプリンティングは既存製造の代替とは見なされず、プロトタイプ／モックアップ／PoC用途にとどまっている
LLMはコードを書くのには優れているが、「責任」の主体にはなれない
理解せずに受け入れたコードは、後の保守で大きな代償（技術的負債）を払うことになる
まるで無料の速度だという錯覚のようで、実際には年利40%レベルで技術的負債が積み上がる効果
AIでタイピングだけを自動化し、思考は人間が担うべき
- LLMが本当に「理解」しているわけではないので、人間がコードベースの文脈とシステムを理解しているときにのみ真のcomprehensionがある
- テストや、隔離されたサブシステムの構造化（tdd、マイクロサービスなど）によって金利（技術的負債）を下げる方法の提案
  一部では、従来の開発では不要だったtddやマイクロサービスがLLM時代にはより価値を持つ
- タスクによっては、AIはコードを書くことすら非常に苦手な場合がある
入力リスク(Input Risk)が最大の苦痛ポイントだったという経験
プロンプトの小さな曖昧さだけで結果が完全にずれることがあり、それに気づくと手遅れになってからの収拾が難しい
人間言語の曖昧さがあるからこそ、結局は明確な形式言語が生まれた
個人的にはAIツーリングを使うことで実力が急激に低下しているように感じ、むしろ時間とエネルギーをより多く消費した例もあった
AIは有用だが、一方には複雑な問題で小さなミスが累積する陣営、もう一方には結果だけを見て「役割代替だ」と主張するマネージャー／非技術者の陣営に分かれているようだ
[詳しい経験: 以前のコメント]
- AIを自分の補佐役として使い、自分が品質と保守に直接責任を負う構造を勧める
  電卓が人々の暗算能力を落としたように、AIもまた文章力、コミュニケーション力、問題解決能力の低下を招く可能性がある
- 曖昧な単語の入力がLLMの非論理的な結果につながる、という経験の共有
  そのため、小さくて明確な課題、StackOverflowで探すような問題にだけLLMを使う方式
  回答は絶対的な正解ではなく、ガイドとして扱う
- AIがある問題はより速く解決してくれるが、必要以上に複雑にしてしまう問題は解決できない
  人が全体設計図を理解する能力こそが、エントロピーへの抵抗の核心
- 自分がよく使う方法: 「3ラウンド、5個ずつ明確な質問をしてほしい」とまずLLMに頼む
  こうするとテーマや文脈をより明確に磨ける
  この小技が他の人にも役立てばうれしい
- このハイプの時代の後には、結局は品質管理の重要性が再発見されるだろうという予感
  例: 昔からのCoke vs Pepsi戦争
LLMはアイデア、ダイアグラム、仕様を概念的に扱わないという主張には同意しづらいという意見
LLMに「単純化したコードがほしい」というように設計意図をたずねれば、十分に良いセカンドオピニオンも得られる
質問しなければそもそも答えはなく、デフォルト設定も私たちの選択なのだから、背景技術の本質とは関係ない主張だと見る
- LLMの概念的作業は実証的にすでにさまざまな形で示されている事例がある
  現実には誰一人として巨大なプログラム全体を頭の中で把握できず、ツールと言語の大半は部分的理解を前提に発展してきた
  LLMも同じ限界を共有しているので、この枠組みでは人間とLLMの限界は似ている
- ジュニアのコードレビューをすると、コード自体の質より方向性の問題のほうが多いと感じる
  LLMがその方向に対して「なぜそうするのか」と問い返す能力を持ちにくい点が惜しい
- コード→ダイアグラム変換の自動化ツールを使っているのか、自作しているのかを質問
Google/Apple Mapsなどの地図ソフトが人の道案内能力を退化させるという主張との類似への言及
当たっている面もあるが、大多数はもともと道に強くなく、むしろ地図技術によってA→Bへの移動能力は平均的に上がったと思う
少数の熟練者にとっても、技術は自分の能力を置き換えるのではなく補助する役割だ
AIもまた、より大きなスケールで似た変化をもたらし、能力が減ったり失われたりする点はあっても得るものも多いだろう
- 地図は信頼性の面でLLMとは比べものにならない
  地図はほとんど常に期待どおりの値を返すが、LLMは同じプロンプトでも結果が変わるため信頼しにくいと感じる
  地図のせいで湖に落ちる人がいるように、LLMの盲信はより大きな問題を引き起こす可能性がある
- 個人的には、地図ソフトの利用はむしろ空間記憶に役立つ
  思う存分迷って、必要な瞬間に経路を確認できるため、かえって経験が増幅される
- Google Mapsはタクシー運転手より90%以上正確
  AIは、その分野を数日やっただけの一般人よりも劣るケースがある
- 「平均的な実力向上」という主張に証拠があるのか疑問
「[AI]は概念的レベルでは働けない」という著者の主張に共感できない
最近のLLMは明らかに概念的レベルで作業できる（例: コンセプトの翻訳／適用）
人間が個人的に経験していない概念も理解すると主張
- LLMはトークンクラスタを通じて概念をモデリングしている
  例: dogの近くに関連語が集まっている
  しかし組み合わせ／意図／反事実論理などはモデリングできない
  学習データと似た質問では力を発揮する
  ソフトウェアエンジニアリングのように概念化がよく定義された領域では有用
- 人間も直接経験していない概念を理解できるという追加の例
現実的には70%の従業員が仕事を雑にこなしており、AIのほうがむしろ良いことも多い
結局、真面目に働かない人はAIを使っても変わらず、本当に学ぶ人だけがAIとともに成長する
- 自分が30%側にいるという自己中心的なナラティブの限界を指摘
- AIで仕事を雑に流そうとする人は、むしろ解雇リスクを自ら招く
  AIが仕事をよりうまくやるなら、主体を置き換える口実を作るだけ
- 大企業基準では、この主張が最も現実的だと同意
  FSD（自動運転）も、専門家ではない普通の運転者よりはるかに優れている
最近、90s.devを非AIコミュニティ、ソフトウェア職人芸の場として再構成する必要性を感じているという共有
フォーラム、メーリングリスト、マルチブログ形式などを検討中
仮メーリングリスト
- 誰でも参加できる構造より、招待制で推薦者の信頼ツリーを持つ構造のほうが、持続力の高いコミュニティに適していると思う
  すでに特定コミュニティで成功例がある
- 当時の古典的フォーラムソフトウェアをレトロ感あるデザインで使うのも良いアイデア