AIコードを修正するのをやめよう。エージェントが必要とするシステムを構築せよ

ソフトウェアエンジニアがもはやコードを書かなくなったら、彼らは何をするのでしょうか？それは何百万人もの心の疑問です。AIツールは現在開発者に広く使われていますが、解雇への恐怖は依然として懸念されています。一方、コーディングはソフトウェアエンジニアリングの一部に過ぎません。これにより、エンジニアはビジネスや、組織や業界における自分の役割の目的のコンテキストに近づく機会が生まれます。Tesslの技術スタッフであり、DevOpsという用語の創始者、DevOpsDaysグローバルイベントシリーズの創設者であるPatrick Deboisは、「私は平行して考えるのが好きです。2009年、私は思いました。もし運用が開発にもっと似ていたら？」と述べています。彼のコメントは、今夏初めのPlatformCon Londonで行われました。そこで彼は聴衆に、コンテキスト（AIがタスクに使用する特定の知識）が人間のコードを置き換えるにつれて、「ソフトウェア開発ライフサイクルはコンテキスト開発ライフサイクルになる」と語りました。このライフサイクルは、単一のCI/CDフィードバックループから、生成、テスト駆動開発による評価、コンテキストのパッケージとしての配布、観察を中心とした一連の同心円状のループへと成長しました。この成長は、個々の開発者、チーム、組織全体の考え方の変化によって促進されています。そして、それはプラットフォームエンジニアリングチームにまったく新しい機会を開きます。DeboisはThe New Stackに次のように語っています。「私が提唱する開発者の考え方の変化は、エージェントが期待通りに動かなかった場合、コードを修正するのをやめることです。プロンプトではなく、システムを改善してください。そのシフトは、『エージェントと一緒にやる』から『エージェントがより良くできるように支援する』への移行です。」Deboisはこれを、決定論的なシステムから非決定論的で確率的なシステムとワークフローへの必要なシフトと見なしています。そしてそれは、テクノロジーそのものと同じくらい仕事の仕方にも多くの変化をもたらすものです。しかし、それは個々のエンジニアやチームレベルだけでは実現できません。DevOpsと同様に、スケールでしか実現できない変化です。

コンテキスト駆動型組織になるには？まるでスイッチを切り替えたかのように、すべての企業が「AIファースト」になったように感じられるかもしれません。実際には、その前のDevOps、マイクロサービス、クラウド変革と同様に、AIは予見可能な未来へ継続的に移行しています。では、あなたのエンジニアリング組織はどのようにして正しいコンテキスト駆動の道に進むのでしょうか？チームレベルでは、Deboisは、エージェントが機能するために必要なタッチ数はどのくらいかと問うことが良い質問だと述べています。異なるチームの異なるエンジニアは、コードベース、仕様、事後分析、ドキュメント、Slackメッセージ、アーキテクチャ決定記録、コードサンプル、ユースケース、コンプライアンスガイドラインなど、さまざまなコンテキストのポイントを入力します。コンテキスト、ひいてはエージェントをスケールさせるには、個人やチームがどのようなエージェントを生産し、その出力を知る必要があります。Deboisは次のように説明します。「あなたがAのために最適化していて、私たちがBのために最適化している場合、私たちが与えるコンテキスト全体がチーム全体に最適化されていることを確認しましょう。」さらに、「あなたがラップトップのためにシステムを最適化しているなら、チームのワークフローに最適化できますか？そしてそれをスケールアップして、プラットフォームレベルでこれができますか？複数のチームにまたがってできますか？」と問いかけます。DeboisはThe New Stackに語ります。「それはあなたが探し求めるものではありません。おそらく彼らはそれを加速できるかもしれませんが、『ああ、私にはコンテキストがあり、あなたにもコンテキストがある。確かにSlack上にある。これをリポジトリに入れて再利用できたら？』という兆候が見られるでしょう。」これは、テクノロジーにおいて、どんなトレンドも一人の熱心な支持者から熱心なチーム、数チームへと広がり、最終的にプラットフォームに組み込まれるパターンに従います。すべてのツール主導の変化と同様に、AIはテクノロジーと同じくらい人とプロセスに関係しています。しかし、ツールは行動の変化の可能性を開くと彼は主張します。「根本的な変化はシステムであり、プロンプトではありません」と彼は続けます。「そして、個人から共有へ、そして今ではチームとして一緒に[コンテキスト構築]に取り組むというコラボレーションの方向性を探ってください。」

コンテキストエンジニアリングはハーネスエンジニアリングへと進化します。組織は、コンテキストがエージェントシステムに一度だけ、またはルールが変更される年に数回だけフィードされると考えるかもしれませんが、Deboisはそれがウォーターフォールであってはならないと警告します。それは反復的です。コンテキストが反復的でなければ、エンジニアはプロンプトを言い換えたり、コードそのものを修正したりする悪い習慣に逆戻りします。従来のフィードバックループだけに依存すると、AIエージェント群は投資に見合ったリターンをもたらさないでしょう。DeboisはPlatformConの聴衆に次のように語ります。「業界では、AIに問題があればもっとAIを使えばいいというナラティブがあります。」彼は、ある大規模言語モデル（LLM）やAIエージェントがコードを生成する例を挙げました。「私たちはLLMにこれを評価するよう依頼し、それはあたかも単体テストのように呼び出されます。コードを実行したのではなく、コードを見ただけです。」それにはある程度の価値があり、おそらくAPIエンドポイントや他の二値品質ゲートを強制するのに役立ちますが、それだけでは不十分だと彼は言います。代わりに、コンテキスト内で必要なものを指定すれば、それがエージェントのコード実行と評価方法を駆動します。しかし、そこで止まってはいけません。エージェントAI成熟度の次の段階は、ハーネスとループに基づいていると彼は主張します。ハーネスエンジニアリングは、LLMをラップするインフラストラクチャ、ガードレール、ツールを構築して、信頼性の高い自律エージェントの開発をサポートすることに焦点を当てています。Deboisは、エージェントの内部ハーネスを、クエリAPIの背後にあるログ、メトリクス、トレースと定義し、「これによりコーディングエージェントが結果を見て改善する」と述べています。これらすべてが、生成、評価、配布、観察の生きたループにフィードバックされます。このパターンにより、エージェントは「常にあなたが教えなくても、何かが間違っていることを自律的に認識します」と彼は言います。なぜなら、「失敗したこと、改善したことを知るセンサーを持っており、エンジニアが何かをハードコーディングしているときでも、それらの壁を改善するために戻ることができるからです。」繰り返しますが、ハーネスは単一の開発者やチームにサービスを提供するために孤立して構築されるべきではありません。「彼らは全世界のためのハーネスを構築しています。ですから、これがテストのやり方、検証のやり方、そして現在これらすべての異なるチームにある知識の合意を想像してみてください」とDeboisは言います。「人々は同じパイプライン上に構築し始めます。」現実には、ほとんどの組織は複数のパイプラインを持つことになりますが、これらのループは各組織のフィードバックループの次の進化形となります。そして、AI調整のために構築することは、より良い組織コラボレーションにつながります。