長年、人工知能はエディタの中であなたの隣に座り、次に何が来るかを推測してきました。あなたが一行書けば、それは次の行を提案しました。しかし、アーキテクチャ、デバッグ、そして構文の所有権は依然としてあなたにありました。その時代は終わりました。
私たちは「インテント駆動開発（Intent-Driven Development）」へと移行しています。ループや条件文をタイピングするのをやめ、代わりに必要な結果を記述します。エージェントがその目標を吸収し、ステップを計画し、コードを書き、テストを実行し、あなたが結果を見る前に自らエラーを修正します。キーボードはもはや主要なツールではありません。明晰な思考こそが、主要なツールなのです。
行単位のコーディングの終焉
従来のワークフローでは、あらゆる意図をコンパイラが理解できる特定の言語へと翻訳することを強いられてきました。ビジネス要件を頭の中に保持し、それを手動で関数、インポート、エラーハンドリング、テストケースへと分解していました。インテント駆動開発は、この翻訳レイヤーを崩壊させます。
例えば、決済のWebhookを統合する必要があるとしましょう。以前なら、ルートハンドラーを書き、ペイロードを解析し、署名を検証し、トランザクション内でデータベースを更新し、領収書メールをキューに入れるといった作業を行っていました。今では、要件を記述するだけです。「StripeのWebhookを検証し、イベントを冪等に記録し、領収書フローをトリガーせよ。データベースの書き込みに失敗した場合はロールバックせよ」。エージェントはハンドラーを書き、解析戦略を選択し、リトライロジックを構成し、テストを生成します。あなたの役割は「著者」から「ディレクター」へとシフトします。
これが機能するのは、エージェントが生成だけで終わらないからです。エージェントはループに入ります。
エージェント・ループの内部
核心となる作業は、もはや人間によるタイピングや手動のデバッグではありません。それは、生成と検証の間の緊密なサイクルです。エージェントはコードを生成し、テストスイートに対して実行し、出力を読み取り、失敗を自ら修正します。インポートの欠落、型の不一致、アサーションの失敗——エージェントはスタックトレースを確認し、ファイルを編集し、スイートを再実行します。あなたは、そのループの中にはいません。サイクルはマシンのペースで進みます。
あなたが介入するのは、ループ自体が壊れたときです。おそらく、エージェントが2つの依存関係間の競合を解決できなかったり、ユニットテストには合格するものの、より高レベルなビジネスルールに違反するコードを生成し続けたりする場合です。それらの境界線こそが、人間の判断が依然として重要となる場所です。
あなたの真の仕事：制約設計者とエッジケースのハンター
もしマシンが関数を書くとしたら、あなたには何が残されるのでしょうか？ 2つのことがあります。そして、それらは構文をタイピングすることよりも困難です。
第一に、エージェントを正しい方向に導くための「制約」を書くことです。エージェントは広範な知識を持っていますが、あなたの特定の環境については理解していません。あなたは次のように伝える必要があります。「内部の請求APIのみを使用し、生のカードトークンは決してログに記録せず、レスポンスのレイテンシを200ミリ秒未満に抑えること」。これらの境界線は、使い捨てのプロンプトではありません。成功か失敗かを決定する仕様なのです。
第二に、エージェントが失敗する10パーセントのケースを捕まえることです。エージェントは一般的なパスをうまく処理します。しかし、微妙なレースコンディション、曖昧なビジネスロジックのエッジケース、そして学習データに組み込まれたセキュリティ上の前提条件において、彼らはつまずきます。あなたの強みは、Webhookハンドラーと返金用のcronジョブの間の競合を見抜いたり、生成されたリトライロジックが二重課金を引き起こす可能性があることを認識したりすることから生まれます。マシンは標準的な問題を解決します。あなたは危険な例外を捕まえるのです。
コードレビューを検証ハーネスに置き換える
エージェントが一晩で50個のファイルを生成できるようになったとき、差分（diff）を流し読みして「正しそうか」を確認するようなレビューは不可能です。そのボリュームにより、人間の目視は不可能になります。コードがあなたの元に届く前にエラーを捕まえる「ハーネス（検証の仕組み）」が必要です。
このハーネスは、3つの柱に基づいています。
永続的な実行（Durable execution）。 エージェントのタスクは、単一のリクエストのタイムアウトよりも長く実行されることがよくあります。一時的なネットワークの瞬断によってステップが失敗した場合、ハーネスは状態を壊すことなく、一時停止、リトライ、そして再開を行います。作業は中断に耐えうるものです。
構造化された出力（Structured outputs）。 エージェントが整った形式の構成ファイルを返してくれることを期待するのではなく、事前にコントラクト（規約）を強制します。JSON Schemaのようなツールを使用して、出力を即座に検証します。エージェントが必要なフィールドを省略したり、誤ったデータ型を使用したりした場合、ハーネスはコードがリポジトリに触れる前にそれを拒否します。
動的なガードレール（Dynamic guardrails）。 エージェントに、シークレットを読み取ったり本番データベースに書き込んだりする自由を与えてはなりません。ハーネスは権限を動的に制御し、エージェントをサンドボックス化することで、指定されたテストデータベースと内部エンドポイントのみに触れられるようにします。あなたはすべての行をレビューしているのではありません。エージェントを囲む「フェンス」を監査しているのです。
コードは動作するが、プロダクトが失敗するとき
ここにパラドックスがある。テストハーネスは不適切なコードを検知できるが、不適切な意図を検知することはできない。
もし仕様書に「すべての新規ユーザーにウェルカムメールを送信する」と書かれていれば、エージェントはそのメールを送信する、クリーンでテスト済みのコードを記述するだろう。しかし、あなたが「ユーザーがアドレスを認証し、マーケティングへの同意を行い、かつ現地のタイムゾーンの営業時間内に登録した場合にのみ、ウェルカムメールを送信する」という意味で書いたことまでは理解できない。そのコードは技術的には完璧だが、ビジネス的には危険なものとなる。
Intent-Driven Developmentにおける真のリスクは、仕様の曖昧さにある。意図が不明確であれば、教科書的なエレガンスを持ちながら、間違った問題を解決するソフトウェアが生まれてしまう。だからこそ、仕様書を真の資産として扱う必要があるのだ。バージョン管理を行い、ステークホルダーと共にレビューし、エージェントが構築を開始する前に実際のワークフローに照らして検証しなければならない。チャットボックスに書き殴ったプロンプトは仕様ではない。それは負債である。
エンジニアリングの判断は「上流」へと移行する
エンジニアリングにおける判断力が消え去るわけではない。それは、より高い高度へと移行しているのだ。
マップをどう反復処理するか、あるいはクラス階層をどう構築するかといったことに、もはや精神的なエネルギーを費やす必要はない。代わりに、障害発生時にシステムがどう振る舞うべきか、どのデータを決して公開してはならないか、そして分散サービス間でどの不変条件（invariants）を維持すべきか、といったことにエネルギーを注ぐことになる。コーディングの技術は、要件定義の技術へと変貌しつつある。
つまり、仕様書には、かつてコードに適用していたものと同じ厳密さが求められるということだ。制約を正確に記述し、失敗モードを明示的に定義せよ。かつて型を宣言したときと同じくらい明確に、ビジネスルールを記述するのだ。実装はエージェントが担う。あなたは、その実装が構築するに値するものであることを保証しなければならない。
品質基準をプルリクエストからプロンプトへと移そう。まずハーネスを構築し、次に仕様を書く。そして、問題が正しく定義されているか、境界線が安全に引かれているかに集中している間、構文処理はマシンに任せるのだ。
この変化の背後にある考えをより深く探求したい場合は、Intent-Driven Developmentに関する元の議論をこちらから読むことができます。AIネイティブなエンジニアリングに関する継続的な議論については、GyaanSetu communityに参加することもできます。