自律エージェントが10のサブシステムを出荷した週末

初日からエージェントによって構築されたエンジンは、AIを後付けしたエンジンとは違う形で出来上がる。その形こそが、AIが後付けの機能ではなくプリミティブであるときにランタイムが必要とする形そのものだ。

土曜の朝、ラップトップを開いた。ランタイムのリポジトリは一晩で139コミットを取り込んでいた。そのほとんどは、先週末に私がファイルしたイシューのキューに対して動いていた自律コーディングエージェントによって着地していた。10件のサブシステム規模のプルリクエスト、すべてレビュー待ちだった。

私がAIエージェントをチームに入れて3Dランタイムを構築するのが実際どんな感じか人に聞かれると、たいてい2つのうちどちらかを想定される。エージェントはチャットパネルで着飾った自動補完だ、というものか、あるいは、「本物の」エンジンが人間によって構築された後に追加する機能だ、というものだ。

このどちらも、私がこの週末座っているバージョンではない。

土曜と日曜にわたって、ランタイムのリポジトリは139コミットを取り込んだ。そのうち110は自律エージェントによって作成された。20は創業期のBladeWirelessアカウントによるものだった。10は私自身のものだった。それら139コミットにわたって、10件のサブシステムのプルリクエストが着地した。

• スケルタルアニメーションシステム
• ランタイムシーン編集API
• シーンのシリアライズ
• オクルージョンカリング
• レベルストリーミング
• プレハブシステム
• GPUパーティクルシステム
• 高度なレンダリング
• 地形と環境システム
• ポストプロセッシングパイプライン

これらのサブシステムはどれもAIではない。3Dランタイムが3Dランタイムであるために必要な、地味で荷重を支える部分だ。そしてそれらは1週末のうちに、並行するブランチで、ほとんどが自律的に走るエージェントによって作成され、私はそれを組み立て、レビューし、マージした。

これは、基盤がエージェントのために構築されるのではなく、エージェントによって構築されるということが何を意味するかについての投稿だ。

その違いはあらゆるアーキテクチャ上の決定に表れる

「普通の」エンジンをこれまでずっとエンジンが作られてきたやり方で作り、それからその上にAIを追加する、というバージョンのこの物語がある。AIは機能として着地する。後付けされる。エンジンの外側に住む。なぜならそのエンジンはAIをホストするようには設計されていなかったからだ。それが今業界における支配的なパターンであり、それは間違ったパターンではない。それは単に、AIが開発チームに加わる前にエンジンがどう見えるべきかを決めたときに得られるパターンだというだけだ。

AIエージェントが初日からチームにいるとき、エンジンの形は違うものになる。3つのことが変わる。

1つ目。すべてのサブシステムがコードレビューを通じて出荷される。 エージェントがレビューループに参加しなければならないため、そのループはエージェント作成の差分を受け入れなければならない。すべてのPR。すべての差分。すべてのマージ。その規律はエージェントを可能にするだけではない。それはまた、AIがいつかエディタの機能ではなくランタイムのプリミティブになるとしたら、まさに望むことになる規律でもあることが分かる。カリングのヘッダー内のエージェントの誤字を捕まえるのと同じレビューパイプラインが、ビヘイビアツリー内のエージェントの誤字も捕まえる。パイプラインは、それがスタックのどの層に住んでいるかを気にしない。

2つ目。すべてのサブシステムがきれいな公開インターフェースを持つ。 複数のエージェントが複数のサブシステムに並行して取り組めば、境界があいまいなたびにマージ不能なコンフリクトが生じる。対処法は、誰かがコードを書く前に境界を固く描くことだ。境界が固くなれば、サブシステムはどこからでもアドレス可能になる。それはまさに、エンジンに、密結合なしにランタイムの残りの部分を呼び出せるAIの挙動をホストしてほしいなら必要なものだ。

3つ目。すべてのサブシステムが独立してテスト可能だ。 139コミットの土曜日を手作業でQAすることはできない。テストは差分と一緒に出荷されなければならず、そうでなければその差分は着地しない。それが、ループの中の人間がその差分を少しでも信頼する方法だ。副次的な効果として、呼び出し元を書き直すことなく実装を差し替えられるテスト表面が得られる。それは、エンジンが少しでも進化するために必要な規律だ。

これらはどれもAIの機能ではない。エージェントをチームに入れたことの開発プロセス上の帰結だ。開発プロセスがアーキテクチャを形作る。

ワークフローは実際どう見えるか

この週末を生み出したパターン。

• 私は、エンジンが次に何を必要とするかを組み立てた。
• 自律エージェントは、それぞれ1つのサブシステムを実装する10本のブランチにわたって並行して走った。
• すべてのブランチが実装、テスト、ドキュメントを備えたPRを生み出した。
• 私がレビューし、マージした。エージェントが何かを間違えたところは、PRを閉じるか、変更を求めた。

この週末の終わりにここに座っていて印象的なのは、すでにどれだけ多くのことが機能しているかだ。開発ループは開発ループだ。エージェントは、5年前なら10人を雇ってやってもらっていたであろう作業をしている。私はアーキテクチャ上の判断とマージの決定をしている。それは、私がかつて過ごしていた長い週末とは違う種類の長い週末だ。

この特定の週末における自律エージェントは、4体のアシスタントからなる複数ベンダーのスタックではない。単一のエージェント(CopilotのSWEエージェント)が、多くの並行タスクにわたって走っている。私は、複数アシスタントのパターンがやって来ると予想しており、それも速くやって来ると予想している。そのパターンはすでに単一エージェントの形でここにある。

難しいこと

正直に言おう。本当に難しいからだ。

エージェントはタダではない。 139コミットの週末には139コミット分のレビューコストがある。すべてのPRが本物の注意を必要とする。サブシステムが馴染みのないものであり、私はそれを流し読みできないからだ。私は疲れている。その疲労は本物であり、予算として見込んでおく価値がある。

新奇な作業において自律エージェントを信頼することはスキルだ。 この週末のサブシステムのほとんどを出荷したCopilot SWEエージェントは優秀だ。だが無謬ではない。スキルとは、いつ速くマージすべきか、いつ減速すべきか、いつ下書きを捨てるべきかを知ることだ。私はすでに、やり直すべきだったものをマージしてしまった。私はそのコストを払いながら学んでいる。

アーキテクチャは、エージェントが走る前にスケッチされていなければならない。 エージェントに「レンダラーを作ってくれ」というプロンプトを渡せば、あなたのエンジンの残りの部分に合わないレンダラーが手に入るだろう。「このC APIをエクスポートし、これらのハンドルを通じてシーングラフと統合するオクルージョンカリングサブシステムを実装せよ」というプロンプトを渡せば、きれいに着地するものが手に入る。組み立て作業こそが仕事だ。エージェントはタイピングをする。

テストは交渉の余地がない。 私は今週末のPRの一つを、薄いテストカバレッジのまま着地させそうになった。それは私が静かに戦うことを約束している未来の退行だ。対処法は、テスト要件をエージェントへのプロンプトの最初の行から組み込むことだ。

この週末から持ち帰ること

2つの観察がある。

エージェントは明らかにこれからも良くなり続けるだろう。より速く、より正確に、より多くのエンジンを1つの頭の中に保持できるように。それは容易な予測だ。

それほど容易ではない予測は、このワークフローの中で人間の役割に何が起きるかだ。それはすでに、私がシニアエンジニアとして訓練を受けた役割ではない。タイピングは減り、組み立ては増える。統合は減り、選択は増える。「私がこの1行のコードのボトルネックだ」ということは減り、「私は、このブランチをそもそも走らせる価値があったかどうかを決めるアーキテクチャ上の判断のボトルネックだ」ということが増える。

それは違う仕事だ。違う筋肉を使う。その筋肉はドメインをまたいで異例なほど汎用性が高いと思うし、今後2年間でそれを鍛える人々は、業界の残りの部分を、今業界がバージョン管理なしでまだ構築している人々を見るような目で見ることになると思う。

それが1週末分として十分すぎる考察だ。

日曜の夜、ラップトップを閉じる。来週の土曜日にまた戻る。