エージェントが自走するコードベースへ、鍵は「開発環境」

おそらくただの飾り文句に過ぎないものにこだわってすみませんが、最初の文…「エージェントは実際に楽しいゲームをワンショットできる」って、ええと、例えば？

ここで間違っていると証明されたい。3つのモデル発表で同じ基本的な1レベルのカートレーサーを見ただけのような気がする。ワンショットだったのかさえ確信がないし、もちろん「楽しい」とは言えない。

結局のところ、人間にとって機能するプロセスはすでにあり、コードベースを健全に成長させるテスト、検証、レビューの種類もわかっている。あとはこれらの設計をAIにできる限り適応させるだけだ。

AIには速度、制御性、優れたデフォルト（例：Claudeは促されなくても役立つコメントを書く。これはほとんどのエンジニアより良い）、そして包括的なテストのようなベストプラクティスを人間のチームよりはるかに低コストで実装できる能力など、人間に対する多くの利点がある。個人プロジェクトでAIを使うと、手動よりもはるかに低いバグ率でソフトウェアを書ける。以前は自動テストスイートを作る時間がなかったからだ。しかし、AIには硬直性、限られたコンテキストウィンドウ、デフォルトでの創造性の欠如といった欠点もあり、これらはハーネス（例：別々の、よく圧縮されたコンテキストを持つ異なるエージェント）で解決するか、人間のレビュー層で回避する必要がある。

コーディング自動化の最良のコアパターンは、目の前の具体的な問題に一連のエンジニアリングプラクティスを柔軟に適用できるエンジニアリングマネージャーエージェント層を作ることだと思う。それは人間に届く前にすべてのコーディングエージェントのpingを処理し、意思決定の際に大局を確実に考慮するようにプロンプトされる。ごく稀に、真にブロッキングな問題や計画レビューを人間に直接エスカレーションするが、ほとんどの場合、下層のコーディングエージェントから得た情報を整理し、表面化する[…]

私には理にかなっている——並行して2つの別々の道を進むと思う：

一つは、サイバー防御のOODAループから人間を外すこと。Servletライブラリ（例えば）は流動的で自己修正するものになり、契約は今日とはかなり異なる動作をするだろう。これらのものに関するエンジニアリングプラクティスは変わる必要がある。

二つ目は、UXが自己修正的になること。piが自分自身を修正できるように、これはユーザー向けアプリケーションの一般的な慣行になるだろう。おそらく、ユーザーが微調整を記述してアプリケーションの機能方法の変更を要求できるテキストボックス。アプリケーションのエンジニアリングは、アプリケーションの譲れない部分をモデル化し、ユーザー主導のLLMがオンザフライでソフトウェアを修正するための正しいプリミティブを提供し、変更を追跡およびロールバックすることに焦点を当てるだろう。ユーザーが広告を排除しようとしても広告が確実に配信されるようにする方法についても、楽しい課題がある。

AIプログラミングは、自動運転車と似たような状況にあるように感じる。典型的なケースには十分で、ほとんどの人間より優れているかもしれないが、新しい状況や、システム（コード、ビジネス要件、物理世界、何でも）の本当に一貫したモデルを必要とする状況に対処するのは苦手だ。