エージェンティックコーディングは罠である

2026年5月4日原文(larsfaye.com)

概要

AI によるコーディングが主流となりつつあり、人間は オーケストレーター としての役割に移行
コーディングエージェント活用の進展に伴う スキルの衰退やベンダーロックイン などの課題
Spec Driven Development（SDD） の普及と、その影響の現実的なリスク
AI活用による 開発者の思考力や問題解決力の低下 が懸念
責任あるAI利用と バランスの取れたスキル維持 の重要性

AI時代のコーディングと人間の役割変化

AIエージェント がコードを書く時代の到来
人間は 仕様策定・計画立案・レビュー を担うオーケストレーター役
開発の流れは、要件定義→計画→AIによる繰り返し生成・修正→最終レビューというプロセス
コードとの距離が広がり、 人間の直接的な実装機会が減少
エージェントの非決定性による システム全体の複雑化 が進行

コーディングエージェント活用のトレードオフ

AIの非決定性 による曖昧さを補うため、周辺システムの複雑化
コーディングスキルの衰退 が広範囲で発生
Claude Code の障害などによる ベンダーロックイン のリスク
ツール利用コストの 変動と増加 （トークン課金モデル）
成功には 高度な批判的思考力とアーキテクチャ設計力 が必要

スキル衰退とパラドックス

AI活用の過剰 がコーディングスキルの急速な劣化を招く
Junior開発者 は実装経験が減り、レビューのみで学習機会が半減
Seniorエンジニア もアプリケーションの全体像把握が困難に
Anthropicの調査 では「監督のパラドックス」：AI管理には失われつつあるスキルが必要
LinkedInの事例 ：クリティカルシンキングや問題解決力が養われにくい

抽象化とAI時代の違い

過去の新言語や抽象化導入時の懸念は 理論的・予測的 だった
AIツールは 実際にスキル低下や混乱を生んでいる 点で異なる
コードを直接書く摩擦が 学習や深い理解 を生む
AI主導のワークフロー では、十分な経験を積まずに高レベルな管理を求められる
Seniorエンジニア でも「精神的モデル」の喪失を感じ始めている

コーディング＝プランニングの重要性

コードを書く過程自体が 思考や設計の一部
仕様書だけでなく、 型定義や構造設計 を通じて初めて理解が深まる
LLM は曖昧さを前提とし、意図しない出力や「幻覚」も頻発
レビューや修正の手間、トークン消費の増加 が生じやすい
AIに依存しすぎると、開発物との距離感が拡大

ベンダーロックインとコスト問題

Claude などのAI障害時、開発チーム全体が停止する事例
AIモデル提供者への依存 が急速に進行
トークンコスト の予測困難・増大リスク
Primeagen の指摘：「完全なエージェント型ワークフローではモデルプロバイダーに支配される」
産業全体の クリティカルシンキング能力の外部委託化 が進む懸念

AI活用の落とし穴と今後の展望

Anthropicの調査 ではデバッグスキルが47%も低下
AIの責任ある活用で 学習やスキル向上 に役立てる道も存在
自己学習や実験の効率化 にはAIが有効
バランスをとった AI活用と人間のスキル維持 が今後の鍵
産業全体で スキルの持続的育成とAI依存のリスク管理 が必要

Hackerたちの意見

AIツールを使ってアイデアを出したり、コードを生成したりしてるけど、実際には自分でタイピングしてるんだ。そうすれば、時間が経ってもメカニクスやプログラミング言語を忘れにくいからね。

└

まさに私がやってることだ。私だけじゃないって知って嬉しいよ。

└

同じく。俺もシステムプロンプトを設定して、完全な解決策やコードを書かないようにしてる。だから質問すると、短い10行の例や擬似コードを出してくれる。これだと考えやすいんだよね。それでもAIの提案の50%以上は却下してる。理由もなくコードを移動させたり、単に間違ってたりするから。

└

一つのアプローチとして、コードを書かせないように頼むってのがある。そうすると説明を強いられるし、自分でコーディングしてアイデアを試すことで、より理解が深まる。俺はメンテナンスが必要なコードにこのアプローチを使ってる。時々、モデルが間違った情報を混ぜることがあって（過去には正しかったけど今は間違ってることが多い）、それが痛い目に遭わせることもある。捨てられるような簡単に検証できるスクリプトは生成してもらうけど、オーバーエンジニアリングやすべてのコーナーケースを考慮しないように頼んでる。スクリプトでは、エラーが出てもそれが失敗のステップとして理解される方がいいからね。読みづらい言語（パワーシェルとか）は避けて、モニターに収まる短いものを生成してもらうのが好き。だから、全部読んで理解できる（Python、Bash、Batchが俺の定番スクリプト言語）。

└

そもそも、AIが忘れたことを思い出させてくれるなら、忘れることに意味があるのかな？

└

同じく。俺がやることのほとんどは、実装プランを求めることで、最小限のコードか、コードなし、または擬似コードをもらって、実際のコードは自分で書くって感じ。これはオープンソースの作業で、楽しみの全ては自分でコードを書くことだからね。もし全てがLLMにコードを書かせて、それをレビューするだけだったら、オープンソースのメンテイナーになる意味はないと思う。それは全然満足感がない。もしこれが実際の有料の仕事だったら、LLMの使い方がどう変わるか気になるな。俺がソフトウェア開発者でいる理由は、クラフトが好きだから。アイデアをコードに変えるために頭を使って作る行為…それが楽しいんだ。もしただLLMにプロンプトを送るだけだったら、その仕事を続けるだろうか？わからないな。少なくともキャリアを変えることを考え始めるかもしれない。

結局、コードの質は最終的に自分次第ってことだよ。エージェントと何度もやり取りして、自分が書くのと同じ質のコードになるまでやればいいんだから。

└

そうだけど、結局時間を節約できてるわけじゃないよね。

└

「...エージェントとやり取りして、自分が書くのと同じ質のコードになるまで」って言ってるけど、私は自分のコードの質じゃなくて、AGIのコードの質が欲しいんだよ。それが約束されたことだし、ジェットパックや空飛ぶ車もね！

└

自分でコードを書く方が速いし、イライラしない。目標が自分の品質基準に合ったコードを得ることならね。

└

あなたを止めるものは何もないけど…それよりも自分で書いた方が早いよ。AIによる生産性向上なんて神話だね。

この記事はちょっと的外れな気がする。AIを多用するとスキルが失われるのは確かだけど、ここで言いたいのは、AIが人を早くさせすぎてるってこと。早い出力が悪いとは言わないけど、コードを生み出すことに対する深い理解や経験が伴ってないんだ。ビジネスバリューについて語る人が評価されて、ちゃんとした知識を持って安全な決定を下す人が評価されないのはおかしい。AIは確かに良い解決策を生み出すけど、結局何をしてるのか分かってないし、最良のケースでも強力なオーケストレーターが必要なんだ。今はビジネス主導の開発の泥沼にいて、悪い決定に対する厳しい罰が与えられてない。

Hacker Newsで議論の続きを見る

ハクソク