自己駆動型コードベースに向けて

エージェントは、実際に楽しいワンショットゲームをプレイできます。適切なガードレールがあれば、エージェントは複雑なコードベースで信じられないほど印象的な移行、さらには新しい言語での書き換えを実行できます。しかし、基本的に「実際の」ソフトウェア作業のほとんどは、人間エンジニアがプロセスを主導しています。私たちが注意を払う必要なしに、より大きな部分の作業が私たちのために処理される場所へ、どのように到達できるでしょうか？ エージェントは、ソフトウェアシステム全体を自分で構築できるようになるはずです。なぜこれが実際にはうまくいかないのでしょうか？それを機能させるために、どのような新しいプリミティブが必要になるでしょうか？これはどこまで進むことができるでしょうか？ トークンマクシングの次に来るものは？ 多くのエンジニアリング組織は、今年の前半を、できるだけ多くの作業をエージェントと敵対的ループの軍団にオフロードすることに費やしました。結果はかなり残念でした。疑わしいコードの山はできましたが、素晴らしいソフトウェアの津波は起こりませんでした。それらのトークンに対するROIは、せいぜい疑わしいものでした。 ハイプサイクルの観点から見ると、私たちは幻滅の谷にいます。数ヶ月前に持っていたユートピア的なビジョンを、実際にはまだ機能していないものを、どのように実現するかを模索しています。 次に何が起こるでしょうか？他のすべての採用サイクルで、答えは次のようになります。ベストプラクティスを見つけ、私たちの輝かしい新しいハンマーが釘に適している場所と、ネジを叩くために使用している場所を見分け、そして、その輝かしい新しいおもちゃを手に入れるまで必要だと気づかなかった構築ブロックを作成することです。 そのために役立つ診断の1つは、ソフトウェアがほとんど自分で駆動する場合、エンジニアは何をするのか？と尋ねることです。 一般的な答えは、ループの設定です！私たちはコードを書き、次にプロンプトを書き、今ではエージェントのループを設定し、/goal を頻繁に書きます。 私はこれが誤りだと思います。現在、純利益を生むソフトウェア変更を生成し、お金を燃焼させない実行可能なソフトウェアループを設定するのは大変な作業ですが、それは主にツールチェーンが準備できていないためです。適切な動く部品があれば、これらのループは設定が簡単で、信頼でき、費用対効果が高くなります。私たちの時間はこれには費やされません。 むしろ、最も価値のあるエンジニアリング作業は、良いアイデアを持つことになります。重要なアイデアは、依然としてソフトウェア工場以外の場所から来ています。実際、この機械全体の目的は、高収益ではない、私たちが考えなければならないことの量を最小限に抑えることです。 キラー機能は依然として会社を築きます。Cursor Tab、Descriptのトランスクリプト編集、OpenRouterが共通の請求インターフェイスで推論ベンダーを抽象化すること、これらはすべて会社を築くアイデアです。創造性に加えて、良いアイデアには問題への深い理解とドメイン知識が必要であり、エンジニアはプロセスに貢献する必要があります。[1] キラーアーキテクチャは依然として高レバレッジです。適切な単純化は、後で膨大な複雑さを節約し、バグの減少と製品イテレーションの容易さとして現れます。少しの先見の明は、高価値の機能を後で簡単に実現できるようにします。より正しいデータモデルを考え出すこと、適切な場所にキューを追加すること、製品をより良くテストするための足場を構築することには、依然として多くの価値があります。 どの部分が自己駆動されるべきか？ 「良いアイデアを持つ」という領域の外では、コードベースの作業をGPUに移行しようとすべきです。例えば、エージェントはこれらの全体的な懸念に対処できるでしょうか？ ほとんどのバグの検出と修正。新しい機能は、ユーザーがSSO経由でログインしている場合、正しく機能しません。一括削除は、個別の削除とは異なり、ページ上部の行カウンターを更新しません。エージェントはこれらを私たちに検出し、修正するはずです。ほとんどのバグには明白な意図された意味論があります。ソフトウェアがどのように機能すべきかを人間エンジニアが裁定する必要はなく、ドキュメントや仕様さえ必要ないかもしれません。 本番エラーのデバッグ。エラーが発生した場合、エージェントはそれを最近のコミット、トラフィック変更、インフラストラクチャの違い、または予期しない条件に関連付け、通常はそれを私たちにパッチします。バックエンドは基本的に500エラーをもう発生させるべきではありません。ブラウザコンソールログには、基本的にエラーがないはずです。 エージェントの最適化。エージェントのプロンプトをどれだけ書くべきでしょうか？Braintrust、Raindrop、Arize、Langfuseは、一般的なエージェントの病理を分離し、更新を提案し、それらをバックテストして出荷できるでしょうか？ フロントエンドの一貫性。あらゆるアプリのビジュアル言語は、内部的に一貫している必要があります。アプリは、一貫したフォント、色、アイコン、スペーシングを使用する必要があります。デザインシステムは自己ブートストラップし、自己強制する必要があります。人間は確認的な決定を下します。 アプリケーションの洗練。アプリはユーザーが期待する方法で動作するはずです。Ctrl-クリックでリンクを新しいタブで開くはずです。無効なボタンには、その理由の説明があるはずです。フォームフィールドはリフレッシュ時に保持されるはずです。UIはモバイルで合理的な方法でレンダリングされるはずです。UIはスクリーンリーダーでナビゲート可能であるはずです。これらのような数十の基本的な品質・生活期待があります。 成長最適化。フォームコンバージョン、オンボーディングの最適化、マーケティングページの作成の繰り返し。うまくいく実験のプレイブックがあり、エージェントはそれらのプレイブックを実行するはずです。[2] これは成長が死んだことを意味するものではありません。かつてないほど生きています！しかし、その作業は今や、CTAの最適化ではなく、計画や強奪のように見えるでしょう。成長チームは目標を設定し、エージェントはコードだけでなく現実に対しても反復し、変更をユーザーの前に置き、学習することで、私たちは皆、より高レベルのアイデアに集中できます。 リストは続きます。GitHub Copilotはコード行のオートコンプリートを提供し、エージェントは製品全体のオートコンプリートを提供します。 欠けているプリミティブ これが機能するためには、開発スタックにはいくつかの新しいプリミティブが必要になります。これらはすべて必須となるでしょう： エージェント可読の開発環境。バグは、圧倒的に、エージェントが見ることができない領域から発生します。あなたのアプリに、エージェントがエンドツーエンドで実行できないサードパーティ統合がある場合、それらの統合にはバグが発生します。あなたのリポジトリに良いエージェントブラウザ設定がない場合、フロントエンド全体はエージェントが盲目的に飛行しているグレーゾーンになります。そして、その他も同様です。 グローバルメモリ。エージェントが多くの愚かな間違いを犯すことは実際には問題ありません。同じ間違いを繰り返し犯すことは問題ありません。エージェントに、監査ログテーブルは追記専用であり、インプレースで更新されるべきではないと伝えるのは問題ありませんが、その後、その領域に触れるすべてのエージェントにそれを伝える必要がある場合、あなたは低レベルの作業のためにループに戻っています。私たちが作成するどのようなメモリシステムも、ツールチェーン全体で機能する必要があります。コードレビューボットは、2週間前にこの領域のコードを書いたエージェントに発行した修正を認識している必要があります。安全でない本番操作を行ったSREボットを叱るとき、エージェントはその理由を理解し、その後、将来のすべてのエージェントはその修正を認識している必要があります。グローバルメモリは、主にツールが改善されるのを待つ問題です。オープン標準を作成するか、日常的なドライバーエージェントとレビュー担当者、および必要なすべてをすべて1つのスイートで提供する統合スイートを使用するか、あるいはその両方になります。 コードベースの腐敗防止。エージェントはデッドコードを残していますか？1つの方法があるべきところに5つの方法がありますか？型システムは直感的ですか？データモデルは、私たちが提供しようとしている製品と一致していますか？何かがこれらすべてを処理する必要があります。そうでなければ、コードベースはスパイラルし始めるでしょう。 前の時代のプリミティブのほとんどもまだ必要です。例えば、APM（ただし、ウィジェットリッチUIではなく、主にエージェントがログを読み取ることでクエリされるでしょう）とCI（ただし、より良いマージキュー付き）とA/Bテスト（ただし、エージェントが操作可能）です。 エージェント可読の開発スタックをどのように構築するか？ エンジニアリングチームが現在多くの作業を行う必要があるのは、エージェントがバグがあるかどうかを知る前に、コードを必要なすべての方法で実行することを容易にする、非常に優れたクラウド開発環境を作成することです。この時点では、開発エージェントの制限要因は、モデルとハーネス自体ではなく、それらが動作する環境です。 別の言い方をすれば、エージェントは、十分な良い環境で動作していれば、もっと多くの作業を行うのに十分なほど優れています。