- AIコーディングエージェントはコード作成速度を劇的に高めているが、実際の開発プロセスで最も重要な部分は依然として理解と問題解決である
- LLMを活用して素早くコードを作れる一方、全体の文脈把握が不十分なため、後処理作業と理解により多くの時間がかかる
- その結果、生産性への期待と実際の効率性のあいだにギャップが生じ、開発者が望む創造的な作業ではなく、テスト・リファクタリング・ドキュメント作成のような反復的で負担の大きい作業に時間を費やす問題を引き起こす
- 過去の**「テックリードのジレンマ」**のように、短期的成果のために複雑な作業をAIまたはシニアへ集中させると、長期的にはチーム能力の低下と危機を招く
- LLMを強力なジュニアエンジニアとして認識し、検証済みの開発プロセスをAIとの協業に適用することで、持続可能なソフトウェアデリバリーの構造を作るべきである
問題認識: コーディングそのものより重要なこと
- ソフトウェア開発は問題解決を中心とした作業である
- 実際のコーディングは、開発者のあらゆる思考と検討の最後の一部に当たる
- 開発者はコード以外にも、ドメインの把握、要件の細分化、抽象化、副作用の考慮、段階的テスト、バグ修正など多様な作業を行う
- 従来の開発フロー: 十分に考えてからコードを書く
- AIコーディング時代: コード優先、理解は後回しというパターンへ転換している
AIコーディングの転換: コードが先に生成されるパラダイム
- Claude CodeなどのAIコーディングエージェントはコードを素早く生成するが、システム全体の文脈を完全には把握できない
- 人間によるレビュー・テスト・統合の工程が不可欠であり、AIが書いたコードを事後的に理解するのに多くの時間がかかる
- マーケティングではコーディング速度向上が強調されるが、実際の動くソフトウェアを届ける生産性の向上はわずかである
- 開発者はAIが作った成果物のテスト、重複排除、ドキュメント作成、インフラ管理など、反復的で難しい作業により多くの時間を投入する
- 実際のコーディングの楽しさは減り、反復作業が増えるという体験が生じる
技術リーダーの古くからのジレンマ
- エンジニアがテックリードの役割を担うと、チームの技術的デリバリー責任を負う
- チーム内の経験値が一人に集中すると、生産性の不均衡が生じる
- 公平な分配（チームメンバーの成長を重視）と集中投入（迅速な開発を重視）の二つの戦略のあいだで葛藤する
- 集中投入は短期的な利益が大きいが、経験の偏在によってチームの長期的リスク（支え手の不在、バーンアウト、採用困難）を招く
- 健全なチーム文化のためには、成長と効率のバランスを取る方法が必要である
良いリーダーシップの核心: プロセスと成長のバランス
- 経験豊富なエンジニアのノウハウをチーム全体が身につけられるよう、さまざまな開発原則とフレームワークを適用する必要がある
- 例: エクストリームプログラミング、コードレビュー、段階的デプロイ、モジュール設計、テスト駆動開発、ペアプログラミング、ドキュメント作成、継続的インテグレーションなど
- 最終的な目標: 手戻りの最小化、協業の最大化、個人の成長促進
AIエージェントとの協業: 新しいチームリーダーの役割
- 最新のLLMベースのコーディングエージェントは、非常に高速なジュニア開発者に近い
- 既存のジュニアと異なり、LLMには学習能力の欠如、速度制限がないという明確な違いがある
- AIは品質向上よりも継続して速度向上に集中し、人間の文脈理解やドメイン理解は不足している
- 二つの協業パターン:
- AIベースのエンジニアリング: 遅くても効率的で持続可能なチームワークを志向
- バイブコーディング: 素早い結果に集中するが、次第に回復不能な混乱が蓄積する
- シリコンバレーにおけるコード成長の伝統的な盲点とよく似ており、短期的利益のあとに成長限界の壁へ到達する
AIコーディングの罠を生き延びるための実践的方法
- LLMは自分固有の状況を知らず、無差別にコードを量産する
- エンジニアはAIに明確な構造と標準、プロセスを与え、生の出力を実際のサービスへ変換しなければならない
- 従来の開発サイクルにおけるベストプラクティスをAI協業環境に密着して適用する新しいプレイブックが必要である
- 主な段階別のAI活用方法:
- 仕様定義: エッジケース分析、目標範囲への集中
- ドキュメント作成: 繰り返し使えるガイドと証拠の確保
- モジュール設計: 文脈を限定して理解度を向上
- テスト駆動開発: 実装前にテストケースを生成し、リグレッションを防止
- コーディング標準: スタイルと品質を維持
- モニタリング: ログの自動分析とインサイト抽出
結論
- ソフトウェアデリバリーはコード作成だけで成り立つものではなく、AIと人間の効率的な協業構造の確立が不可欠である
- LLMを超高速のジュニア開発者と見なし、検証済みの開発プロセスを適用してこそ、拡張性のある高品質なソフトウェアを提供できる
2件のコメント
Hacker Newsの意見
単に「技術が人を怠惰にする」という主張に基づかない anti-AI 論を見てみたい。真面目に LLM でコードを作ってみた人なら、計画・構成・テスト・振り返りのループが依然として非常に重要だと感じるはず。注意せずにそのまま回すと、すぐ壊れやすい。このループをうまく適用すれば、自分が好きなアーキテクチャ設計や、結果として得られる体験のテストに多くの時間を使える。LLM が簡単な部分を素早く処理してくれるので、結局こちらに残るのは、あまり面白くなく感謝もされにくい仕事になる。AI が専門性を発揮する分野では、仕事そのものを楽しむ人と、考える体験を楽しむ人の間で見方の差がはっきり出る。考えることが好きな人は、AI のおかげでほぼ完全にその領域へ集中できる。一方で、実際にタイピングしたり操作したりするのが好きな人にとっては、AI はむしろ自分の好きな部分を奪っていく
AI のコード生成に関しては、技術が人を怠惰にするというより、AI が生成したコードに対する深い理解を奪う点のほうが重要な批判だと思う。ソフトウェアエンジニアの核心はコードを生成することではなく、システム全体を設計することにある。ここで重要なのは、コードがどう動くかについてのメンタルモデルとドメイン専門性であり、コードはそのメンタルモデルから派生した成果物にすぎない。ある程度以上の規模のプロジェクトでは、実際にそのコードを書いた本人でない限り、完全に把握するのは難しい。こうしたメンタルモデルを積み上げなければ、別の問題もついてくる。LLM ベースのコーディングエージェントは文法レベルの推論に限界があり、スケーラビリティに弱みがある
自分の考えを言えば、Cline のような AI ツールはたまに使うが、だんだん自分でタイピングしてコーディングする比率が高くなっている。理由は、たいていの場合コーディングをプロンプト作成に置き換えているだけだからだ。プロンプト作成と推論にかかる時間が、自分の手で直接コーディングする時間より短ければ AI を使うが、普通はそうなるのはリファクタリング程度の速度制約があるときだけだ。ほとんどの作業では、自分でやれば 10 分、AI だとプロンプトを書いて実行して 8 分かかる。ミスなくうまくいけば 2 分節約だが、修正や再プロンプトが発生すると逆に 10〜12 分かかり、AI クレジットまで消費するので最悪だ。こうして計算すると、コード品質でも所要時間でも手作業のほうが安全だという結論になる
技術が人を不注意にするという主張について言えば、一般に技術が人をより慎重にする場合も多い。問題は、この AI 技術がユーザーに不注意を誘発しやすいことだ。自分の関心はコーディングの楽しい部分ではなく、設計、つまりアーキテクチャそのもののほうにある。もし意図をそのままコードに反映できるなら、その方法を使うだろう。だがチャットボットのインターフェースでは、意図が間接的かつ不完全に伝わるため、高水準のコード構築に使うと自分の頭の中のモデルと実際のコード理解が急速に乖離し、不安定な土台を残してしまう。行単位で細かくレビューすることもできるが、それでは道具の趣旨に反する。AI コーディングは「10 倍速い」という感覚のせいで、細部の実装と巨視的な理解の乖離を助長する。実際、構造的な部分をあまり考えなくてよいことが AI コーディングを売り込む主要な利点だが、その理解のギャップが後で問題を起こす。良い自動化は信頼性が高く予測可能で、上位の不変条件だけ理解すればよいが、チャットボットのコードはそうした保証を与えず、結局すべてを手動で検証しなければならない構造になる。ここでは安全性と信頼性がむしろいっそう難しく感じられる
「考える部分に集中しろ」という論理をあまりに頻繁に見かけるので、もう食傷気味だ。問題は、何年もの実務を自分で経験していない人が、思考だけで深い活動ができるのか疑問だということだ。結局、実際に手を動かす経験がなければ、思考そのものまで次第に浅くなる危険がある
自分の見方では、デバッグは書くことより大変なので、自分が書いていないコードをデバッグするくらいなら最初から自分で書いたほうがいい
こういう議論を読むたびに毎回思うのは、著者が本当に自分と同じ道具を使っているのか気になるということだ。自分は Claude Code で、単純なボイラープレートから複雑なアルゴリズムまで、非常に入り組んだ大規模コードベースの中でもほぼ何でも作らせられる。もちろん 100% 正しいわけではないが、かなり近い。しかも自分では思いつかなかったアルゴリズムを提案してくれることもよくある。こうしたツールは自分の時間を少なくとも 10 倍は節約してくれる
この記事は悪くないが、二つほど見当違いがある。第一に、熟練した開発者が LLM を使うときでも、十分な探索や事前の検討、設計は依然として不可欠だ。むしろ LLM をきちんと活用するには、普段よりもっと考え、さまざまな設計案を比較し、全体構造を描く必要がある。以前はこうした過程を文書化していなかったが、今は設計文書として残している。第二に、LLM は成長しないジュニア開発者のようなものだという主張だが、両者はまったく違う。人間の新人開発者は人であり、LLM は道具だ。新人と一緒に働けば蓄積的な価値が生まれる一方、LLM にはそれがないと言われるが、これも正しくない。LLM 自体が学習しなくても、自分のほうがはるかに効率よく手懐け、よりうまく使えるようになる。製品に LLM をうまく適用する初期段階にあるのだから、複合的な成長価値が見えるのは当然だ
「LLM が学習しなくても、自分は学習する」には共感するが、それでも LLM にはユーザーとのやり取りから本当に学んでほしい。自分が望むのは、セッションの内容をファイルとして保存・読み込みして、LLM が以前に学んだコンテキスト全体を漏れなく理解できることだ。一部のフロントエンド UI ではセッションの保存・復元ができるが、重要なのは a) こうした「再学習」が LLM の現在の context window に影響しないでほしいこと（そもそもこの概念自体がなくなってほしいが）、b) 絶対に欠落のない方式であることだ。要約して続ける方法や RAG のような手法はすでにあるが、どれも情報損失があったり、現在のやり取りがトリガーされないと復元できなかったりといった根本的な限界がある。たとえば、昨日 LLM にある関数について説明してからセッションを保存し、今日それを復元した後にまったく接点のない質問をしても、LLM が以前の文脈まで含めて答えてくれるようであってほしい。必要なときには明示的に clean slate で始められる仕組みも必要だと思う
その通りだ。ソフトウェア全体の生産性では、考える時間が実際にコードを書く時間よりはるかに大きな比重を占めるので、LLM がコーディング部分を速くしても、全体の生産性や人材需要に劇的な変化は起きない
DO NOT WRITE ANY CODE YETプロンプトから始めるのが自分の基本でもある。LLM が何をしようとしているのかを先に把握し、自分のコントロールを確保する方法だ。自分はコードを書くことより、ロジック、問題解決、システム統合といった設計そのもののほうがずっと面白いCopilot の Ask モードや GPT-5 Codex の Plan/Chat モードのように、コードファイルを変更せず計画だけできる機能がある。Codex を数日使ってみたが、十分な指示を与えれば非常に優秀だ
自分もたいてい「まず計画を教えて」といった形で、LLM に具体的な実行前の計画から尋ねるほうを好む
今回の記事は Microsoft のマーケティング資料だけを引用して 10% の生産性向上を主張しているが、Harvard の研究では実際にはむしろ 10% の生産性低下が記録されている。特定企業の宣伝ではなく、独立した研究結果を先に引用する記事のほうが望ましい
この記事が十分に伝えきれていない核心の一つとして、Casey Muratori が言う「学習中心のマインドセットでプログラミングするなら AI はむしろ無意味だ」という点に共感する。個人的には、AI コード生成器は一回限りで捨てる予定のコードにだけ有効だ。本気で学びたい領域では、AI にコード生成を任せないほうが学習効果を最大化できると感じた。「AI 主導エンジニアリング」が有意義な人たちも確かにいるのだろうが、少なくとも自分にとっては、実際に自分の手でコードブロックを書いたほうが楽しく、最終的な成果物もより良く仕上がる感覚がある。関連動画、5分
Claude Code を使うようになってから、考えることにずっと多くの時間を使うようになった。実装したい機能を 400〜600 語で描写するようなことは以前はなかったが、今ではより多くの情報を真剣に整理している。そうした熟考のおかげで結果は速くなり、良くもなるが、同時にコードへの自分の理解度は以前よりやや下がっている。ただ、Claude Code を使うと経験豊富な開発者があまり考えなくなるという主張には同意できない。多くの人がほとんどプロンプトだけで済ませるなど、エージェントを非効率に使っているのだろうとは思うが、それはエージェントのせいではない
こうした議論を見ていると、今はまだ曖昧な過渡期なのだと思わされる。来年ごろには、今日のような議論は「考えすぎ」と受け取られるようになる気がする。インターネット普及の前後に「一時的な流行だ」「誤った投資だ」といった疑問が数多くあった時期に似ている
こういう記事がよく見落とす点は次の通りだ
AI コード支援の長所・短所とトレードオフだけを体系的に整理した記事があればいいのにと思う。道徳的な価値判断（良い／悪い）は抜きで議論する必要がある。「コーディング能力」が自分のアイデンティティであるときほど、特に冷静に向き合いにくいことは認める
毎日「あと 30 年だけ耐えたら引退だ」と自分を励ましている。機械学習分野で 10 年目、コンピュータの前に座るのにも仕事にも疲れた。もう草の上でごろごろしていたい
「思考＆コーディング vs 思考＆修正」のグラフが興味深い。最近 Codex を使っていて、AI が自分のコードをかなり修正してくれるだろうと確かに期待していた。実際には、問題の原因がコードとまったく関係ないときに時間が大量に消える。最近も認証の問題で長いことコードばかり調べていたが、原因は VM の ipv6 設定の不具合だった
共感します。AIコーディングをしたとき、後処理作業が多すぎて、実際のビジネスに組み込み、保守するのがとても大変です。
一緒に開発するという立場で、できるだけ多くピンポンしながら進めても、一部のコードは自分で直接書いたものではないため、頭から抜け落ちてしまうことがよくあります。
境界線は絶対に必要だと思います。