優秀な開発者がエージェンティック開発に慎重になる理由

優秀な開発者がエージェンティック開発に慎重になる理由

TL;DR
優秀な開発者がエージェンティック開発に慎重になるのは、構築されたものが本番環境で動作するものと同じではないことを知っているからです。

多くの優秀な開発者がコーディングエージェントに全面的に取り組むことに躊躇していることに、私は驚いています。彼らは通常、新しい働き方を誰よりも早く試す人々であり、多くの場合、アプリケーションをうまく構築するための新しいツールやプラクティスを発明しています。では、なぜこれほどまでに抵抗があるのでしょうか？

簡単に（あるいは怠惰に）言えば、彼らはコードを書くのが好きだから、あるいは自分の仕事を心配しているからでしょう。それは、いつ、誰かにとっては真実だと思います。そして、私が話した開発者の中にはそれが真実である人もいると知っていますが、私は常にそれ以外に、明白なものたちの陰に隠れた別の恐怖があると感じていました。半年ごとにTechnology Radarをまとめる際、オープンな議論のために時間を確保しようとしますが、9月のエージェンティック開発に関する議論は、それを限界まで推し進め、ついにその恐怖が何であるかをはっきりと私に見せてくれました。

正しく構築すること

Thoughtworkerは、「正しいものを構築し、それを正しく構築する」ことに深くこだわっています。それは、私たちの仕事や考え方のほぼデフォルトであり、私たちが発明し、推進してきた多くのプラクティスやテクノロジーの源泉です。私たちは、有用で役立ち、来年も変更可能で、本番環境でクラッシュしないソフトウェアを求めています。私たちの開発者は、継続的インテグレーション、ペアプログラミング、自動テスト、継続的デリバリー、マイクロサービスなどの初期バージョンを、ソフトウェアを正しく構築するのに役立ったため、早期に採用、推進、あるいは発明しました。

初期のコーディングエージェントは、本番環境に置きたくないコードを含め、コードを生成することを非常に容易にしました。それは、構築することと本番環境で安全に実行することの間の断絶について学んでいない人々によって書かれたものでした。ツールは大幅に改善されましたが、経験豊富な開発者は依然として疑問を持っています。これは正しい動作であると確信していますか？期待通りに動作しますか？これらは適切な境界線ですか？進化させることができますか？顧客のニーズを満たし、本番環境で稼働し続けるという自信を与えてくれる、苦労して学んだ原則やプラクティスに準拠していますか？何かが失敗した場合はどうなりますか？別のチームはそれと共存できますか？などです。

それらのすべての下には、より大きな疑問があります。誰もこの方法で構築した経験がないシステムを、どれだけ信頼できるでしょうか？別の言い方をしましょう。現在本番環境にあるほぼすべてのシステムは、古い方法、つまり手作業で、私たちが信頼できる人々（うまくいけば）によって構築されました。今、私たちが構築するすべては新しい方法であり、私たちはまだそれに慣れていません。

テクノロジー業界で25年以上の経験を持つ私は、経験を通じて人々が培う判断力を高く評価するようになりました。私は定期的に、モデルとThoughtworksのシニアテクノロジストに同様の質問をしています。難しい質問に対しては、人間からより有用な回答を得られるか、あるいは非常に具体的な経験を持つ人から、その点をよりよく理解するのに役立つ洞察を得られます。彼らは前提に疑問を投げかけ、10年前に何か間違っていたことからパターンを認識したり、技術的な問題の中に隠れている組織的な問題を見つけたりします。私は今、膨大な情報にアクセスできます。何が重要かを考えるのを助けてくれる人、知恵と洞察力を持つ人が、私はまだ必要です。その種の判断力こそ、躊躇している経験豊富な開発者が守ろうとしているものです。

そして、はっきりさせておきたいのは、彼らはコーディングアシスタントを使うことに躊躇しているのではなく、エージェントにすべての実行を任せることに躊躇しているのです。彼らは、エージェントが単独で実行するための適切なガードレールを備えていると確信していないため、ハンドルから手を離すことに躊躇しています。

ホワイトボードでの一週間

最近、私たちの欧州地域CTOであるGiles Alexanderは、シニアエンジニア、インフラコンサルタント、プロダクト担当者を集め、まさにこの方法で一週間作業しました。誰かがコードを書くことはありませんでした。すべてエージェントによって構築されました。その目的は、航空会社のアプリケーションが一週間で構築できることを証明することではありませんでした。（面白いことに、彼らは80%を完了し、その意味は私たち全員が知っています…作り話はできません！）この実験の目的は、エージェントがすべてのコーディングを行う場合にチームの作業に何が起こるかを学ぶことでした。彼らが学んだことの一部はこちらで読むことができます。

私たちの会話で私を驚かせたのは、彼らがホワイトボードで過ごした時間の長さでした。ドメインを理解する。境界線を引く。次に何が起こるべきかを決定し、エージェントが実行できる計画を立てる。その間、エージェントはチームの勤務時間外もコードを生成し続けました。

人間はまた、その作業に関するフィードバックを設計していました。テスト、コントラクト、アーキテクチャチェック、デリバリーパイプラインです。彼らは、エージェントに進歩するための十分な自由を与えつつ、結果に対する信頼を維持する方法を模索していました。キーボードでの作業のほとんどは、この学習をハーネスに入れるようにエージェントを指示することであり、構築およびテストエージェントが次の実行で正しく動作するようにし、構築したものに対する信頼を高めることができるようにすることでした。興味深いことに、最終的にはプロダクト担当者がチームの他の誰よりも多くのフィーチャーコードをコミットしました。

彼らに見積もりを依頼したところ、時間の約3分の2をホワイトボードで、3分の1をハーネスで過ごしたと述べました。これは、開発者が将来どのように働くかについての手がかりを与えるかもしれませんが、チームの再設計を急ぐ前に、それは話の終わりではありません…

アプリケーションは実行された。ビルドは赤だった。

アプリケーションは実行されましたが、ビルドは頻繁に赤でした。彼らのマシンでは動作しました - これもまた、試しても作り話はできません！常にビルドが赤であることは、私に不快感を与えます。ビルドが赤であることは、何かを意味するはずです。停止し、調査し、修正します。あまりにも頻繁に赤であるため、人々が注意を払わなくなったら、次の本当の障害をどのように見つけるのでしょうか？そして、チェックを信頼できなくなると、緑のビルドも安心できなくなります。これはまさに、継続的インテグレーションが取り除くはずだった不確実性であり、私たちは25年以上それを提唱してきました。

私たちはまだ、それをどのように対処するかを検討中です。これはエージェンティック開発の最先端をプッシュするための実験だったことを覚えておいてください。並行して動作するエージェントが多すぎて、互いの変更を上書きしていたのでしょうか？エージェントが別々の部分で作業するには、システムはまだ十分にモジュール化されていなかったのでしょうか？あるいは、変更がチェックが完了するよりも速く到着しただけでしょうか？それとも、これらすべてとそれ以上の組み合わせだったのでしょうか？いずれにせよ、私たちは最後のマイルの課題をどのように解決するかを再考する必要があります。開発ライフサイクルの残りの部分がひっくり返されているのと同じように、継続的デリバリー/DevOpsというムーブメントがエージェンティック時代に復活し、再考される必要があることがわかります。そして、それは私たちの実験だけではありません。DORAの2025の研究では、AIの採用は高いデリバリーのスループットと関連していますが、デリバリーの安定性は低下していることがわかりました。まさに、継続的デリバリーとDevOpsが解決しようとしていたことです！

これらの課題すべてが、内部でいくつかの良い議論を引き起こしました。テスト駆動開発は、すべての行を読んでいるわけではなく、エージェントがコードと一緒にテストを作成した場合、どのような役割を果たすのでしょうか？受け入れテスト、コントラクトテスト、システム境界でのチェックは、脆すぎることなく、より多くの自信をどのように与えてくれるのでしょうか？エージェントを自由にさせる前に、どれだけの設計を行うべきでしょうか？アプローチをどれだけ速く修正できるかを考えると？どこまで進んだかを知る適切な点はありますか？これらすべてにおける最大のパズルの一つは、バッチのサイズです。多くのチームがストーリーからエピックに移行していると聞いています。開発速度には良いですが、CIパイプラインはそのサイズの作業単位を高速かつ並行して処理できますか？

実験チームは、これらすべてを一週間、あるいは二週間（異なるチームで二度実施しました）で解決しませんでした。解決したと主張する人を私は信用しません。しかし、これはまさに、経験豊富な開発者が関与してほしい種類の作業です。実験し、疑問を投げかけ、どのプラクティスが通用し、どこで新しいプラクティスが必要になるかを発見するのを助けることです。

整えられた斜面から離れて

関与したシニア開発者とのこの会話から離れた後、私はスキーの練習について考え続けました。子供たちはしばしば、新しい開発者がソフトウェアを本番環境に入れたことがなく、午前3時にオンコール対応を修正したことがない（私が決して忘れない、私が個人的に引き起こしたすべての本番環境の問題と、それらから得た学習と同じくらい、私の脳に永遠に焼き付いていること）のようには、恐れずにまっすぐ坂を下っていきます。私が大人になって初めてスキーをしようとしたとき、私は何を壊す可能性があるか考えていました。スキーをしたかったし、それはとても楽しくて自由に見えましたが、私は結果を見るには年を取りすぎており、骨折した手足でロンドンをよろよろ歩き回ることは望んでいませんでした。私の最大の課題は、まだ効果的に曲がったり止まったりする方法を学んでいなかったことで、それがなければ私はスキー場の暴走列車でした。

この投稿のドラフトを、遅れてスキーを学んだMartinと共有したとき、彼は比較がどこで崩れるかを指摘しました（すべての比喩のように、私はそれらを端まで押し込むのが好きです、言葉遊びです）。スキー場では、何千人もの人が骨折せずに底に到達するのを何度も見てきました。インストラクターは、あなたより前に同じ斜面で何千人もの人々を教えてきました。彼らはどのスキルが重要で、それをどのように教えるかを知っています。エージェンティック開発は現在、未知の領域を横断するバックカントリー旅行に似ています。どのスキルが最も重要になるか、まだわかりません。安全に旅行を終えた人はほとんど、あるいは全くおらず、ナビゲート方法に関するフィードバックは遅いか、存在しません。Martinが言ったように、ヘビーエージェント構築システムが機能するかどうかは、しばらく本番環境で実行され、数回の変更ラウンドを生き残り、私たちの飛行機をすべてアバリストウィスに送らなかった場合にのみわかります。構築されたものが本番環境で動作するものと同じではありません。あるいは、Charity Majorsが言うように、「ステージングは単なる飾り立てられたラップトップにすぎません。本番だけが本番です」。だからこそ、「私のマシンでは動作する」と言うとき、それは通常ジョークとして意図されています。少なくとも私はいつも笑います。

それは、リーダー、技術的か非技術的かを問わず、開発者が好奇心がない、あるいは採用に遅れていると主張することに対する私の長年の不快感を固めました。そしてそれを、コードを書く機会を失う（私もそうです）や、仕事を失う恐れ（今は誰がそうでないでしょうか？）のような、指摘しやすい恐怖のせいにしました。私たちの最高の開発者は、他の誰もがすでに習得した保育園の斜面の初心者ではありません。彼らは未整備の地形を見て、ルートについて賢明な質問をしています。彼らに慎重さを減らすように言うのは、ポイントを外しています。彼らはそれをマッピングするチームにいる必要があります。

もちろん、経験は私たちを慣れ親しんだプラクティスに固執させすぎることもあります。整えられた斜面で学んだことの一部は、そこでは通用しないでしょう。そして、私たちは自分たちの仮定をテストする意欲を持つ必要があります。

両者への挑戦

したがって、リーダーと開発者の両方に課題があります。リーダーは、変化への抵抗から有用な懸念を区別するために十分に注意深く耳を傾け、実験のための真の余地を作り出す必要があります。それは、時間、間違いを犯す許可、そしてエージェントがどれだけのコードを生成したかで成功を判断しないことを意味します。開発者は、それらの実験に自分の経験を持ち込み、一部の仮定がもはや通用しないことを発見する準備をする必要があります。

いくつかの慣れ親しんだプラクティスがより重要になるでしょう。他のものは異なる形を必要とするでしょう。誰も最初に地図を渡してくれるわけではありません。

あなたが正しいものを構築し、それを正しく構築することに深くこだわるなら、あなたの判断力こそがこの新しい働き方に必要なものです。慎重さを持ってきてください。そして、雪の中へ出発しましょう。

---