エージェント型コーディングにおける開発者の力量の役割

• エージェント型コーディングアシスタントの能力向上に伴い、反応は非常にさまざまで、一部では「1年以内に開発者は不要になる」と主張している
• 一方で、AIが生成したコードの品質や、ジュニア開発者をこの変化する環境にどう備えさせるかについて懸念を示す人たちもいる
• この数か月、Cursor、Windsurf、Cline のようなエージェント型コーディング支援ツールを使ってきたが、既存コードベースの変更には非常に効果的だった
• IDE 統合には非常に感銘を受けた。テスト実行と自動エラー修正、lint / コンパイルエラーの検出と修正、Web 検索、ブラウザープレビュー機能まで統合されている
• 開発者と AI の協業体験は非常に印象的で、迅速な問題解決や機能実装に貢献した

• しかし、それでも開発者による継続的な介入、修正、方向付けは必要だった
• 実際のコミットに至らなかったケースも多く、AI が自律的に小さくない作業向けのコードを書くにはまだ不十分だった
• したがって、開発者の技術と経験は依然として重要であり、今後も継続的に鍛えられるべきである

開発者が直接介入しなければならなかった瞬間

• AI ツールは特定の領域で常に弱い性能を示しており、それは繰り返し確認された
• 一部は追加プロンプトやカスタムルールで部分的には緩和可能だが、完全な制御は不可能
  • LLM はプロンプトの指示に正確に従わないことが多い
  • コーディングセッションが長くなるほど、結果の一貫性が落ちる
• したがって、以下で紹介する事例はプロンプトや設定に関係なく十分に起こりうる問題である
• AI のミスを影響範囲に応じて 3 つのカテゴリに分類する
  • a. 開発速度およびコミットまでの時間の低下
    • AI がむしろ速度を遅くする
    • 支援なしのコーディングより非効率な場合がある
  • b. チームの作業フローに摩擦を生む
    • 1 回の iteration 内で衝突や協業上の問題が起きる
  • c. 長期的なコード保守性の低下
    • 初期には問題なさそうに見えても、将来の変更や拡張で問題が生じる
• 影響範囲が大きいほど、チームがその問題を認識して修正するまでのフィードバックループは長くなる

影響範囲: コミットまでの時間の遅延

• このカテゴリは、AI が役に立つどころか妨げになった事例で構成される
• 最も明確な失敗の形であるため、それほど大きな問題にはなりにくい
  • ほとんどはコミット前の段階で開発者が問題を認識して防げる

• 動かないコード

  • AI が生成したコードがそもそも動かない
  • 開発者が直接修正するか、AI セッションを終了して手作業で問題を解決する必要がある
  • 経験ある開発者なら、どこが間違っているかを素早く判断して対処できる

• 問題の誤診

  • AI が問題の原因を誤って判断し、見当違いの方向で解決策を試す
  • 過去の経験をもとに、開発者は誤ったルートからAI を引き戻すことができた

    例: Docker ビルドエラーをアーキテクチャ設定の問題と誤解し、設定を修正した
    実際の原因は、誤ったアーキテクチャでビルドされた node_modules をコピーしていたことだった
    以前によく遭遇した問題だったため、すぐに気づいて修正できた

影響範囲: iteration 内のチーム作業フロー

• このカテゴリは、レビューや開発者の介入不足によってiteration の期間中にチーム内で摩擦が起きるケースである
• 筆者は過去のさまざまなチーム経験のおかげで、こうした問題をコミット前に事前に認識して調整できた
• 新人開発者も AI とともに試行錯誤しながら、こうした教訓を学んでいける
• しかし、AI によってコーディング速度が上がると、チームがこれらの問題をさばききれなくなる可能性がある

• 初期作業のやりすぎ

  • AI は段階的な実装より、機能全体を一度に広く処理しようとする傾向がある
  • その結果、技術選定が不適切だったり、機能要件を誤解していた場合、多くの作業が無駄になる可能性がある

    例: フロントエンドスタックの移行時に、UI コンポーネント全体を一気に変換しようとした
    バックエンドと統合される1 つのコンポーネントから段階的に適用すべきだった

• 原因分析なしの場当たり的な解決

  • AI が問題の根本原因を分析せず、単に表面的に見えるエラーだけを解決しようとする
  • その後その問題を担当する別のチームメンバーに、文脈なしで問題を再分析しなければならない負担が発生する

    例: Docker ビルド中にメモリエラーが起きた際、原因を探さずメモリ設定だけを増やした

• 開発者ワークフローの複雑化

  • AI が生成したビルド / 実行方法が開発者体験を損なう
  • そのまま即コミットすると、他のチームメンバーのワークフローにも悪影響を及ぼす

    例: フロントエンドとバックエンドをそれぞれ実行するコマンドを分けて提供する
    例: hot reload 機能の欠落
    例: 複雑なビルド設定により、開発者も AI も混乱する
    例: Docker エラーを事前に検知できず、ビルド終盤でエラー処理をしようとする

• 誤解された、または不完全な要件

  • 機能要件を明確に与えないと、AI が誤解して見当違いの方向に機能を実装する可能性がある
  • 早い段階で介入して正すのが理想だが、自律的な AI でも、考えなしの開発者でも、後続修正のコストは増大する
  • こうした誤った実装は、後になってストーリー進行中に発見され、多くの修正作業とコミュニケーションコストを発生させる

影響範囲: 長期的な保守性の低下

• 最も見えにくく危険な影響範囲
  • 初期にはコードが問題なく動作しても、後になって変更や拡張が難しくなる
• こうした問題は数週間から数か月後になって初めて発見されることが多い
• 特にこの領域は、筆者の20 年以上の開発経験が最も大きく効いた部分だった

• 冗長で重複したテストコード

  • AI はテスト生成を得意とするが、次のような問題が頻繁に起こる:
    • 既存のテストに統合せず、新しいテスト関数を生成する
    • すでにカバーされている部分にまで過剰に多くの assertion を追加する
  • 初心者の開発者が誤解しやすい点: テストが多い ≠ 良いテスト
  • 重複が増えるほど保守が難しくなり、コード変更時に大量のテスト失敗が起こる可能性が高まる
  • カスタムコマンドで緩和を試みたが、それでも頻繁に発生した

• 再利用性の不足

  • AI が書いたコードはしばしばモジュール化が不十分で、再利用しにくい

    例: 既存の UI コンポーネントを認識できず、重複実装する
    例: CSS クラスを使わず、インラインスタイルを乱用する

• 過度に複雑または冗長なコード

  • AI が必要以上に多くのコードを生成し、不要部分を手作業で削除しなければならないことが多い
  • これは保守コストを増やし、変更時のエラー可能性を高める

    例: CSS を変更する際、多くの重複スタイルを一つひとつ削除しなければならない
    例: JSON データを表示するために、不必要に複雑な Web コンポーネントを生成する
    例: リファクタリングの過程で既存の依存性注入チェーンを認識できず、
    すでに注入されている値を別の引数として再度渡して設計を複雑にする

    • value = service_a.get_value(); ServiceB(service_a, value=value) という形

結論: AI はすべてのコードを代わりに書けるのか?

• これまでの経験に照らすと、1 年以内に AI がコード全体の 90% を自律的に書くのは現実的に不可能である
• ただし、コード作成の補助役としては、一部のチームやコードベースで90% の補助が可能な場合はある
• 実際に筆者は、15K LOC 規模の中程度の複雑さのプロジェクトで約 80% ほど AI の助けを得ている

AI のミスを防ぐ方法

• 個人開発者レベルでできること

  • AI が生成したコードは常に慎重にレビューすること
    • 修正不要なケースはほとんどない
  • AI セッションが混乱してきたら即座に中断する
    • プロンプトを修正するか、いっそ手作業に切り替える（「手作りコーディング」とも呼ばれる）
  • 短時間で奇跡のように完成した「もっともらしい」解決策を警戒する
    • 長期的な保守コストが隠れているかもしれない
  • ペアプログラミング を実践する
    • 4 つの目と 2 つの脳が、よりよい判断をもたらす

• チームおよび組織レベルでの対応戦略

  • 既存のコード品質監視ツールを積極的に活用する
    • 例: Sonarqube, Codescene
    • AI ツールを使う際は、コード重複、コードスメルなどをより綿密に監視する必要がある
  • Pre-commit hook と IDE 統合コードレビューを設定する
    • 開発初期に問題を捉えるための shift-left 戦略を強化する
  • 良いコード品質習慣を再構築する
    • チーム内で AI コードにより発生した問題事例（「Go-wrong ログ」）を週次レトロスペクティブで共有する
  • カスタムルールを積極的に活用する
    • ほとんどの AI ツールは、プロンプトと一緒に渡されるルールセットを設定可能
    • チームが一緒にルールセットを改善しながら、AI のミスを減らせる
    • ただし、セッションが長くなるほどルールを無視する可能性が高まる
  • 信頼とコミュニケーションを基盤としたチーム文化をつくる
    • AI 導入は新しい変化であり、誰もが初心者であるという事実を認識すべきだ
    • 「AI があるのだからもっと早くやれ」という類いの圧力は、品質リスクを高める
    • 心理的安全性のあるチームでは、問題共有と学習がより活発に起こる

[bus710]

あのツールを使う人たちは、能力はさておきみんな開発者でしょうし……。今後は開発者が不要になるかのように宣伝するのは、少しおかしなところがある気がします。

[prunusnira]

今後どうなるかは分かりませんが、まだ主流として使うにはいまひとつな気がします……。最近 Cursor を使ってみたのですが、基本的なファイルの import path すらまともに捉えられていませんでした。それでも、私が作りたいものをある程度先回りして予測してくれるのは少し驚きました。

[daddy]

Dockerのビルド中にメモリエラーが発生したとき、そもそもなぜそれほど多くのメモリが使われたのかを問い直すのではなく、メモリ設定を増やしていた
-> これは……すでに無数の事例でそうしてきたから。
-> 今のAIは、過去の私たちだ

[GN⁺]

Hacker Newsのコメント

• 最近は開発のほとんどでCursorを使っている。この記事は自分の経験ととてもよく似ている

  • AIエージェントは2021年ごろで止まっているように感じる。新しいパッケージをインストールすると、Claudeは4年前に人気だった古いパッケージや実装に戻ってしまう。これを修正するのは非常にフラストレーションがたまる。明確な指示を与えれば問題は和らぐが、解決はしない
  • こうしたミスの予測不能さが特に難しい。数か月前、Claudeを使って便利なWebアプリを「ワンショット」で作った。機能は完全で、驚くほど洗練されていた。自分ひとりで作っていたら、数週間あるいは週末をいくつも費やしていただろう。ただ、用意したファイルを使ってファビコンを更新してくれと頼んだときは、1時間も無駄に空回りしていた（結局は自分で数分で解決した）。数日前には、同じくらいの規模のWebアプリをもう一度作ろうとした。4時間ほどエージェントを相手にした末、コードを丸ごと捨てる寸前までいった
  • このやり方のおかげで、これまで時間も専門性も動機も足りず試せなかったプロジェクトに挑戦する勇気が持てるようになった。摩擦が減るのは面白いが、意味のあるものを作るのは依然として難しい。洗練されたMVPを作るには、やはりかなりの努力が必要だ
  • ずっとウサギとカメの話を思い出している。AIエージェントを信頼するのは、最初は進みがずっと速く感じられるので魅力的だ。しかし結局は、もっとゆっくり丁寧に注意を払っていたほうが、より堅実な前進ができたのではないかという感覚が残る。手作業で作るときは、後戻りしたりアプローチ全体を捨てたりすることはめったにない。AI主導のやり方だと10倍速く進めるかもしれないが、その過程で作業の約70%を捨てることにもなりうる
  • こうした経験から、自分の想像では1年以内にAIがコードの90%を自律的に書くようになるとは思えない。90%のコードを書くのを助けることはできるだろう
  • 今の状況は自動運転車の誇大宣伝サイクルに似ている。大胆な約束も本当の進歩もたくさんあったが、今後5年以内にAIが自分で役に立つソフトウェアを書く世界は見えない

• 自分はAIをこう使っている。IDE内のライティング補助ツールとして使い、とても気の利いた洗練されたラバーダックのように答えてもらう

  • 特定のコード片についての議論をよく何度も繰り返す。たいていはほとんど文脈のない状態で渡し、機能が正しく動くまで磨き、その後でより広い文脈に合わせて提示する（あるいはその部分は自分で処理する）
  • こうは使わない。自分で広い目標を達成すべきエージェントとしては使わない
  • 理由は、エージェントシステムの出力が実際に達成したいことと一致していると保証するために投じる時間と労力が大きすぎるからだ。この優れた記事で説明されているあらゆる理由による
  • 皮肉なことに、AIを非常に有能なライティング補助として使うと、ワークフローはかなり速くなる。だからある意味では、よりエージェント性の低いAIのほうが自分をより批判的にし、エージェント型AIの特異性に合わせるため追加で投資しなければならない時間についても、より批判的にさせる

• まったく理解できない

  • 経験豊富な開発者たちが、あれほど明らかに質が低く満足できない体験に自分を縛りつけることに、なぜそんなに熱狂するのか理解できない
  • 自分はコードを書くことと問題を解くことが好きだ。だからソフトウェア開発を職業に選んだ

• 例: Dockerのビルド中にメモリエラーが発生したとき、そもそもなぜそんなに多くのメモリが使われていたのかを問う代わりに、メモリ設定を増やしていた

  • AIは本当に私たちそっくりだ

• 開発者の技術は今も不可欠だ — 運転できなければ操縦もできない。でも開発者のエネルギーはどうだろう？ AI以前は1日に約2時間しかコーディングできなかった（実際にコードを書く時間として）。しかしClaude Codeを使うと、休まず5時間は楽にコーディングできる。自転車の代わりに電動自転車に乗る感じだ。AIはスティーブ・ジョブズの「心のための自転車」という比喩のように感じる。私を置き換えるのではなく、今はずっと遠くへ、速く行けるようにしてくれる

• この図には本当に共感する — うちのチームはここにある項目を全部チェックしている。まだAIを使っていないのに！ いざ使うようになったときを想像してみてほしい…

  • 「誤解された要件」と「過度に複雑な実装」は、実質的にうちのマスコットだ。より良い初期の対話と反復的なレビューを通じて、この混乱を少しずつほどいている。でも習慣は簡単には消えない。AIの助けなしでこうした落とし穴を乗り越えている人はいるのだろうか？

• 自分には明白なことが見えていないようだ。周りではAIを使っている

  • 開発ツール、インストロスペクション、ロギング、変換など、ツールを構築して保守しなければならないことが多い。エージェントを使ってそれらを作ったり修正したりするのに、かなりうまくいっている。たとえば、カスタム計画システムでデータを収集したりログを集めたりするツールだ
  • こうしたツールの構築には、クリティカルパス外で生成されるボイラープレートが多い。ほとんどの日は、そんなことをやりたくない

• AIをかなり細かく操縦しなければならないが、より良いプロンプトがより良いエージェントにつながるという楽観は持っている

  • 記事の例を使おう: コード再利用。コードを書くとき、自分の頭の中にはすでに存在するコードのメンタルインベントリが無意識にある。無意識のうちに「この新しい作業は、すでに動作してテスト済みのコードにとても似ているか？」と自分に問いかけている。コーディングエージェントが受け取る初期プロンプトの詳細は見ていないが、自分の直感では、コードベースに何があるかのインベントリを維持するようエージェントに指示するプロンプトを追加し、新しいコードの配置を計画するときには、新しい作業の要件を既存のものと照らし合わせるのがよいと思う
  • たしかに、それは計画プロセスに多くの計算サイクルを追加する。しかし、正直に「それがエージェントにコードを書かせるコストだ」と言うべきだ。より良い計画 > 問題解決能力

• AIツールが自分の挙げたものについて常に悪い、と前置きしたい

  • そこには not が抜けている気がする。なぜ「彼らは常に悪い」と前置きするのだろう？ 逆の意味のほうが筋が通る
  • それに effected ではなく affected という文法ミスもある

• Martin Fowlerは今や自分のWebサイトで場所を貸しているのか？