HN428428
AI依存が招くエンジニアの技術力低下、このままではヤバい？
Coding expertise is going to collapse from AI reliance
larsfaye・約9時間前
議論
11件AIへの依存が強まることで、プログラミングの現場から「真の技術力」が失われていくのではないかという懸念が広がっています。AIにコード生成を頼り切ることで、基礎的な思考能力やデバッグ能力が退化し、いざという時に何もできないエンジニアが増殖するのではないか――そんな未来の崩壊リスクについて、皆さんはどう考えますか？
その通りですね。エンタープライズレベルではすでにこの現象が起きています。「手作業でコードを書いているなら、やり方が間違っている」というトップダウンの指示が現場に下りてきているんです。
まあ、しばらくの間はそれなりに機能するでしょう。確かにコードの山は作られていますが、実際には人間が理解したりレビューしたりできる速度をはるかに上回るスピードでコードが生成されています。「Claude、このJiraチケットを読んで機能実装して」という指示に、年俸20万ドルもの価値があるのかという疑問には、正直言って疑問符がつきます。
さらに状況をややこしくしているのは、経営層がAIで生成したマニフェストをプロダクトオーナーに丸投げし、プロダクトオーナーはそれを1500語のJiraチケットに変換するためにAIを使っているという現実です。そのチケットの中身といえば、10%が必要な機能開発で、残りの90%はLLMによる定型文です。
そんなわけで、今のソフトウェアエンジニアの仕事は激変してしまいました。エンジニアであることの最大の難関は、コードを書くことではなく、あらゆる方向から飛んでくるAI生成の残骸をフィルタリングして、なんとか機能をリリースすることになってしまったんです。
LLMによるソフトウェア開発における「自分の尻尾を食べる蛇（ウロボロス）」現象について指摘しても、みんな肩をすくめるだけですね。運が良くても、AIに脳を焼かれないようにしている小規模な開発者グループが残る程度でしょう。しかし彼らの報酬は、AIで脳が焼き切れた人々が書いたひどいコードをレビューさせられることになりそうです。
完全に持続不可能な状態です。
// 長期的なスキル形成には、継続的な摩擦が必要である。
この物語のサブタイトルがすべてを物語っていますね。
自らあえて摩擦を求める人たちがいます。アスリートや筋金入りのオタクを想像してみてください。
最高のエンジニアとは、子供の頃からコンピュータや学習に夢中になり、あらゆる機会を逃さず追求してきた人々です。言い換えれば、自分で摩擦を見つけ出してきた人たちですね。
そういった人々にとって、摩擦を求めることは恒常的な習慣であり、LLMが行ったのはその摩擦が発生するポイントを移動させたことだけです。
例えば、私がこれまで一緒に働いた最高のエンジニアたちは、必ずしもアセンブリ言語でのコーディング経験が豊富だったわけではありません。なぜなら、その種の摩擦はもはや必要なくなったからです。しかし、彼らは難問を解決することができました（もし本当にアセンブリが必要な問題なら、学習して対応するでしょう）。
AIによって最も大きな打撃を受けるのは、スキルの低いエンジニアだと思います。好奇心が薄く、献身的な姿勢を持てず、単なる「仕事」としてしか捉えていない人々。例えば、典型的なオフショアのチケット消化マシンみたいなタイプですね。ああいう人たちは自分から摩擦を見つけに行くことがない。これからの時代、そんなやり方は通用しません。「平凡な出来でいい」ならLLMで十分ですから。
認知的な摩擦こそが学習の原動力であるという考え方に強く同意します。
何よりも重要なのは「依存」の問題です。論理や推論という「筋肉」を鍛えるのをやめれば、使わない物理的な筋肉がそうであるように、徐々に萎縮していきます。かつて自分自身で持っていた能力を、外部ツールに代替させることで依存してしまうのです。
この構造の変化を象徴する歴史的例があります。生産プロセスが職人の頭と手からフォード主義の工場（および流れ作業）へと移行したとき、ものづくりのスキルは人間の職人技から、匿名の構造化されたプロセスへとシフトしました。
少しずつ、伝統的な職人たちは知識やノウハウを失っていきました。今日、家にある家具を使うには巨大な生産・供給チェーンに依存しており、「平均的な」人は自分で家具を作る能力を持たなくなっています。
ソフトウェアでも全く同じことが起きています。
私たちは、かつては「ソフトウェア職人」だった存在なのです。
技術教育者として100%同意します。LLMは、私たちがコードについて悩む必要がなくなる「新しいコンパイラ」にはなりません。決定論的なシステムを信頼するのには理由があるのです。
このことについて常々懸念していて、初心者開発者（あるいは経験者も、萎縮を避けるために）向けの「do-i-understand」というエージェントスキルまで作りました。これはLLMが、提出しようとしているPR（プルリクエスト）について質問を投げかけてくるものです。かなり効果的だと感じています：https://github.com/AnthonyPAlicea/skills/blob/main/skills/do... (https://github.com/AnthonyPAlicea/skills/blob/main/skills/do-i-understand/SKILL.md)
遅かれ早かれ、スキルの格付けの瞬間がやってくるでしょう。
AIの普及によって最も評価されるようになるのはジェネラリストでしょう。特定のドメインの専門知識を持ち、分野横断的に活動でき、LLMを正しい方向に導くための十分なプログラミング知識を持っている人です。過去10年間ほど「純粋な」ソフトウェアエンジニアが高く評価される時代は終わると思いますが、それは他の専門分野でも同じことが言えるでしょう。例えば信号処理の分野では、全体的なアルゴリズムを設計する人と、それを組み込みシステムに実装する専任の人を分けるのは珍しくありませんでした。しかし、コーディングエージェントの品質を考えると、もう両方の役割を分ける必要はありません。両方の知識をそこそこ持っている人が一人いれば十分仕事をこなせます。
悲しいかな、まさにその通りだと思います。
昨日、少し厄介なJavaScriptを書いていたときのことです（メイン言語ではありませんが）。ホバー時に左右に隣接するn個の要素を表示し、どちらか片方が足りなければもう片方に拡張するという処理です。オフセットの微調整に20分ほど苦戦した後、結局エージェントに投げかけて実装させてしまいました。
自分でもやろうと思えばできたはずですが、以前のようにサクッと解決できなかったことに少し落ち込みました。もう萎縮が始まっているのかもしれません。
ヘッドレスなエージェントによる「雰囲気コーディング」に注目が集まっていますが、みんな「ガイド付きコーディング」がいかに素晴らしいかについてはあまり語りませんね。
私は15年以上のソフトウェア開発経験がありますが、ガイド付きコーディング、つまりZedやVSCodeにLLMを統合して、普段通りコードを書きつつ、フラッシュモデルを使って面倒な部分を補完させたり計画させたりする方法は、雰囲気コーディングと同等に生産性が高く、品質も格段に良く、何より楽しいですし、エンジニアとしての感性も鋭く保てます。
DeepSeek v4 flashのようなフラッシュモデルは非常に高速なので、並列エージェントの終了を待つ必要もありません。集中してプロンプトを連打し、コードを書きながらインクリメントにレビューしていく。悪い編集は即座にVETOしてやり直すか、手動で書き直す。
対照的に、ヘッドレスなエージェントコーディングはレビュー不可能なブラックボックスになりがちです。人間がループに入っていたとしても、欠陥が蓄積してしまい、最終的には硬直化したコードベースの些細な修正のために何百万トークンも消費することになります。
結局のところ、Qwenの27b/3bやDeepSeek flashのような、キャッシュが効きやすく軽量で高速なモデルは非常に有能で、実行コストも低いです。みんなが14兆パラメータの巨大モデルなんて不要だと気づいて、ワークステーションのRAMを増設できる余裕ができることを祈っています。
私の経験では、AIの登場によって「質の高いコードベース」の価値が飛躍的に高まりました。良いコードベースは基本的に自己増殖するように動きます。
私がゼロから構築したプロジェクトの中には、技術に詳しくない「雰囲気コーダー」たちに任せても安心して見ていられるものがあります。既存のコードベースが、私が大切にしているパターンと原則をすべて反映しているからです。
雰囲気コーディングによるロジックが上に積み重なれば、徐々に質は低下していくかもしれませんが、ソフトウェアの信頼性を維持しながら機能を追加するという点では、彼らでも十分遠くまで行けるはずです。
しかし、そういったコードベースの価値が高まっているにもかかわらず、人々はこの新しい現実に適応できていません。良いコードを見極められる人はひどく少ないのが現状です。単純な話で、良いコードとは「拡張と保守が容易なコード」のことであり、今はイテレーション（反復）が非常に速いため、その判断はすぐにできるはずなんです。
機能の実装に莫大なトークンを消費してしまうなら、そのコードベースはあまり良くない可能性が高いと言えます。
崩壊とまでは言いません。しかし、2025年11月（Claude Codeの広範な導入から）がスタート地点だとすれば、品質への広範囲な影響が現れるまで3か月から15か月といったところでしょう。