AIエージェントがコードを書く時代、エンジニアの仕事は「境界の設計」へ

コード生成はもはやボトルネックではない

ここ2年のデータプラットフォームのコミット履歴を見ると、構文を書くことの摩擦は大きく減っています。CursorやClaude Codeがエージェント型ワークフローとしてDockerコンテナやIDEの中に組み込まれ、分散ストリーミングパイプラインや複雑なAPI統合の初期実装を生成することは、もはや中心的なボトルネックではなくなりました。

エージェントはリポジトリを探索してテストを書き、スタックトレースを調べ、リファクタリングを提案できます。KafkaからIcebergへのデータ転送のマッピングを平易な英語で説明すれば、エンジニアが関連ファイルをすべて開く前に、もっともらしい出発点を作り出します。

エージェントは熱機関である

記事はAIの擬人化を排し、エージェントを熱機関になぞらえます。データセンターにあるLLMは、プロンプトや要件、システム命令、失敗するテストなどの形で指示を受けて初めて、行動を生み出します。ただし、あらゆるエンジンに損失があるように、エージェントのループにも損失があります。

難しいリポジトリに対してエージェントを実行し続けると、古い仮定をたどり、原因ではなく症状を修正し、過去のマイグレーションを現行の挙動として扱うようになります。記事はこの状態を「運用エントロピー」と呼んでいます。ループの中に古い仮定や分岐する文脈、未解決の依存関係が蓄積されると、次のステップは最初のステップよりも不確かになります。

無限猿定理と探索空間

無限猿定理は、ランダムにキーを打つ猿が無限の時間をかければ、いつかシェイクスピアの作品を打ち出すという確率論の比喩です。現代のエージェントはランダムではなく、コンパイラやツール、リポジトリ、テストスイートからのフィードバックで次の試行を修正します。提案し、実行し、観察し、修正して再試行するというループは、制約のあるタスクでは非常に効果的です。

入力と出力のスキーマが既知で、コードベースが小さく、関連する失敗を検出するテストがあれば、エージェントは完了の定義が明確なまま収束できます。一方、エンタープライズ系のシステムは、可変の運用状態や外部API、遅延イベント、地域ごとのポリシー、コードと人の頭の中に分散した業務ルールに依存しています。そのため探索空間が広く、ループが収束しにくいという課題があります。

エンジニアの新しい役割

エージェントがシステムロジックの主たる執筆者になりつつあるとき、エンジニアには何が残るのでしょうか。記事は、もっともらしいプルリクエストに承認印を押すだけの存在ではなく、論理の構築から離れた抽象度の高い仕事が残ると論じます。その中心となるのが、エージェントが壊せない境界を設計することです。

境界を形作るのは、失敗するテスト、正確なデータ契約、決定的なツール、評価指標、そして人間の割り込みです。外部から新しい情報が入らなければ、エージェントはもっともらしい出力を出し続けながら、正しい結果から遠ざかっていきます。本記事は概念的な枠組みを示すものであり、具体的な実装手順や数値は提示していません。