10月29日、Rachel Laycock（Thoughtworks）が「Why are good developers so wary of agentic development?」と題した記事を公開した。この記事では、優秀な開発者ほどエージェント開発に慎重になる理由と、その慎重さが実は正当な懸念に基づいていることについて詳しく紹介されている。
「ビルドが通ること」と「本番で動くこと」は別物だ
AIコーディングエージェントの普及が加速する中で、ある奇妙な現象が起きている。新しいツールや手法を誰よりも早く試してきたはずのベテラン開発者たちが、エージェント開発に対して異様なほど慎重な態度を示しているのだ。
著者のRachel Laycockは、ThoughtworksでTechnology Radarの策定にも関わるエンジニアリングリーダーだ。彼女はこの現象を「コードを書くことへの愛着」や「雇用への不安」で片付けることに長らく違和感を覚えていた。そして2024年9月のオープンスペースでの議論を経て、その本質が見えてきたと述べる。
核心にある問いはシンプルだ。
「誰もこの方法でシステムを構築した経験を持たないとき、そのシステムをどこまで信頼できるのか？」
現在本番稼働しているシステムのほぼすべては、人間が手で書いたコードで動いている。エージェントが生成したコードで構築されたシステムが、本番環境で長期間・複数回の変更サイクルを経て生き残った実績は、まだほとんど存在しない。「ビルドが通ること」と「本番で動くこと」は別物だ——これが経験豊富な開発者の持つ直感の正体だ。
Charity Majorsの言葉も引用されている。
「ステージング環境は、ちょっと豪華なラップトップに過ぎない。プロダクションだけが本物のプロダクションだ。」 — @mipsytipsy
ビルドは「赤」のまま、アプリは動いていた
Thoughtworksの欧州担当リージョナルCTO、Giles Alexanderが行った実験が、この問題を具体的に照らし出している。シニアエンジニア・インフラコンサルタント・プロダクト担当者を集め、1週間、人間は一行もコードを書かずに航空会社アプリをエージェントだけで構築するという試みだ（実験は異なるチーム構成で2回実施された）。詳細はこちらにまとめられている。
結果は示唆に富んでいた。
- チームメンバーは時間の約⅔をホワイトボード前で過ごした。ドメインの整理、境界の設計、エージェントへの指示計画の策定だ。
- 残りの⅓はハーネス構築——テスト、コントラクト、アーキテクチャチェック、デリバリーパイプラインの設計に充てた。
- エージェントは就業時間外もコードを生成し続け、1週間でアプリの約80%が完成した。
そして、最も重要な発見がこれだ。アプリケーションは動いていたが、CIビルドは頻繁にレッド（失敗）だった。「自分のマシンでは動く」——ソフトウェア開発の古典的な冗談が、エージェント開発の現場でシャレにならない形で再現された。
継続的インテグレーション（CI）は25年以上前から、まさにこの「ビルドが信頼できるか分からない」という不確実性を取り除くために普及してきた手法だ。エージェント開発はその前提を崩しかねない。
原因として考えられるのは複数ある。並列動作するエージェント同士が変更を踏み合っているのか。システムのモジュール化が不十分なのか。変更の到着速度がCIの検証速度を上回っているのか。あるいはその組み合わせか。
さらに、元記事が参照するDORAレポートもこの問題を裏付けている。AIの導入はデリバリースループットの向上と結びついている一方で、デリバリーの安定性の低下とも結びついているというのだ——継続的デリバリーやDevOpsがまさに解決しようとしてきた問題だ。
慎重さは「遅れ」ではない
Laycockはスキーの比喩を使ってこの状況を説明する。子供はゲレンデを恐れずに真っ直ぐ滑り降りる。大人は骨折の痛みを知っているから慎重になる。だが、エージェント開発の現状はゲレンデのスキーではなく、未踏のバックカントリートレッキングに近い。インストラクターもいなければ、無事に帰還した先人の実績もほとんどない。
それでも一部のリーダーは、ベテラン開発者の慎重さを「変化への抵抗」や「コードへの執着」として片付けようとする。Laycockはこれを明確に否定する。彼らは初心者向けの整備されたゲレンデで臆病になっているのではない。未踏の地形を前に、ルートについて真っ当な問いを立てているのだ。
リーダーと開発者、双方への問い
記事の末尾でLaycockは両者に課題を投げかける。
リーダー側には、有用な懸念と単なる変化への抵抗を聞き分ける力が必要だ。実験のための時間、失敗の許容、そして「エージェントがどれだけコードを生成したか」で成功を測らないことが求められる。
開発者側には、その経験をこそ実験の場に持ち込むことが求められる。同時に、整備されたゲレンデで通用した一部のプラクティスは、未踏の地では通用しない可能性があることも受け入れる必要がある。
エージェント開発が問い直しているのは、TDD・ストーリーのサイズ・受け入れテストの形・設計をどこまで先行させるか——といった、長年積み上げてきたプラクティスのすべてだ。
誰も地図を先に渡してはくれない。
詳細はWhy are good developers so wary of agentic development?を参照していただきたい。
