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

セルフドライビングなコードベースに向けて

エージェントは、実際に面白いゲームを一発でクリアできます。適切なガードレールがあれば、エージェントは複雑なコードベースでの信じられないほど印象的な移行、さらには新しい言語での書き換えさえ実行できます。しかし、実際には「本物の」ソフトウェア作業のほぼすべてで、人間エンジニアがプロセスを主導しています。どうすれば、私たちの注意を必要とせずに、より多くの作業を私たちに代わって処理してもらえるようになるのでしょうか？

エージェントは、ソフトウェアシステム全体を自ら構築できるようになるはずです。なぜこれが実際にはうまくいかないのでしょうか？それを機能させるために、どのような新しいプリミティブが必要になるのでしょうか？これはどこまで進む可能性があるのでしょうか？

トークンマキシングの次に来るものは？

多くのエンジニアリング組織は、今年の前半を、可能な限り多くの作業をエージェントと敵対的ループの軍団にオフロードすることに費やしました。その結果はかなり残念なものでした。疑わしいコードの山はできましたが、驚くべきソフトウェアの津波は起こりませんでした。それらのトークンに対するROIは、せいぜい怪しいものでした。

ハイプサイクルの terms で言えば、私たちは幻滅の谷にいます。数ヶ月前に抱いていた、まだ実際には機能していないユートピア的なビジョンをどのように実現するかを模索しています。

［画像: Gartner のハイプサイクル。標準的な採用段階を示しています：テクノロジートリガー、期待インフレのピーク、幻滅の谷、啓蒙のスロープ、生産性のプラトー］

次に何が起こるのでしょうか？他のすべての採用サイクルで、答えはこうでした：ベストプラクティスを見つけ、私たちのピカピカの新しいハンマーが釘によく適している場所と、ネジを叩き潰すためにそれを使っていた場所を特定し、そしてピカピカの新しいおもちゃを手にして初めて必要だと気づいたビルディングブロックを作成することです。

そこへたどり着くのを助けるために使用できる診断の1つは、次のように尋ねることです：ソフトウェアがほとんど自律的に動くとき、エンジニアは何をするのでしょうか？

一般的な答えは、「ループのセットアップ！」です。私たちはコードを書き、次にプロンプトを書き、今ではエージェントのループをセットアップし、頻繁に /goal と入力します。

私はこれが誤りだと思います。現在、純粋なプラスのソフトウェア変更を生み出し、お金を燃やすことなく実行可能なソフトウェアループをセットアップするのは大変な作業ですが、それは主にツールチェーンが準備できていないからです。適切な動く部品があれば、これらのループはセットアップが簡単で、信頼でき、費用対効果が高くなります。私たちの時間はここに費やされることはありません。

むしろ、最も価値のあるエンジニアリング作業は、「良いアイデアを持つこと」になるでしょう。重要なアイデアは、依然としてソフトウェアファクトリーの外から来ています。実際、この機械全体の目的は、ハイアップサイドではない、私たちが考えなければならないことを最小限に抑えることです。

• キラー機能は依然として会社を築くものです。 Cursor Tab、Descript のトランスクリプト編集、OpenRouter が共通の請求インターフェースの背後で推論ベンダーを抽象化すること、これらはすべて会社を築くアイデアです。創造性に加えて、良いアイデアには問題への深い理解とドメイン知識が必要であり、エンジニアはそれに貢献する必要があります。［1］
• キラーアーキテクチャは依然として高レバレッジです。 適切な単純化は、後で膨大な複雑さを節約し、バグの減少と製品イテレーションの容易さとして現れます。少しの先見の明があれば、高価値な機能は後で簡単に実現できるようになります。より正確なデータモデルを考え出すこと、適切な場所にキューを構築すること、製品のテスト方法を改善するための足場を構築することには、依然として多くの価値があります。

どの部分をセルフドライビングにすべきか？

「良いアイデアを持つ」という領域の外では、コードベースの作業をGPUに移行しようとすべきです。例えば、エージェントはこれらの全体的な懸念事項を処理できるでしょうか？

• ほとんどのバグの検出と修正。 SSO経由でログインしているユーザーがいる場合、新機能は正しく動作しません。バルク削除は、個々の削除が行うようにページの先頭の行カウンターを更新しません。エージェントはこれらを私たちに代わって検出し、修正すべきです。ほとんどのバグには「明白な意図されたセマンティクス」があります。ソフトウェアがどのように機能すべきかを判断するために人間のエンジニアを必要とせず、ドキュメントや仕様さえ必要ないかもしれません。
• 本番環境のエラーのデバッグ。 エラーが発生した場合、エージェントはそれを最近のコミット、トラフィックの変更、インフラストラクチャの違い、または予期しない条件に関連付け、通常はそれを私たちに代わってパッチ適用すべきです。バックエンドは基本的に500エラーをもう発生させるべきではありません。ブラウザコンソールログには、基本的にエラーがないはずです。
• エージェントの最適化。 エージェントのプロンプトをどれだけ書くべきでしょうか？Braintrust、Raindrop、Arize、またはLangfuseは、一般的なエージェントの病理を分離し、更新を提案し、それらをバックテストし、出荷できるでしょうか？
• フロントエンドの一貫性。 どのアプリのビジュアル言語も内部的に一貫しているべきです。アプリは、一貫したフォント、色、アイコン、スペーシングを使用すべきです。デザインシステムは自己ブートストラップし、自己強制すべきであり、人間は確認的な決定を下します。
• アプリケーションの洗練。 アプリはユーザーが期待する方法で動作すべきです。Ctrl+クリックでリンクを新しいタブで開くべきです。無効なボタンには、その理由の説明があるべきです。リフレッシュ時にフォームフィールドが保持されるべきです。UIはモバイルで合理的な方法でレンダリングされるべきです。UIはスクリーンリーダーでナビゲート可能であるべきです。これらのような基本的な生活の質に関する期待は数十個あります。
• 成長最適化。 フォームコンバージョンのイテレーション、オンボーディングの最適化、マーケティングページの作成。うまくいく実験のプレイブックがあり、エージェントがそれらのプレイブックを実行すべきです。［2］これは成長が死んだことを示唆するものではありません。それはかつてないほど生きています！しかし、その作業は、CTAの最適化ではなく、計画や強奪のように見えるでしょう。成長チームは目標を設定し、エージェントはコードだけでなく、変更をユーザーの前に置き、学習することで現実に反してイテレーションします。私たちは皆、より高レベルのアイデアに集中できるようになります。

リストは続きます。GitHub Copilot はコード行のオートコンプリートを提供し、エージェントは製品全体のオートコンプリートを提供してくれるでしょう。

不足しているプリミティブ

これが機能するためには、開発スタックにはいくつかの新しいプリミティブが必要になります。これらはすべて必須となるでしょう：

• エージェントが読み取れる開発環境。 バグは、圧倒的に、［エージェントがそれらを見ることができない領域］から来ています。あなたのアプリに、エージェントがエンドツーエンドで実行できないサードパーティの統合がある場合、それらの統合にはバグがあります。あなたのリポジトリに良いエージェントブラウザセットアップがない場合、フロントエンド全体はエージェントが盲目的に飛行しているグレーゾーンになります。そして、その他も同様です。
• グローバルメモリ。 エージェントが多くの愚かな間違いを犯すことは実際には問題ありません。問題なのは、それらが同じ間違いを繰り返し犯すことです。監査ログテーブルは追記専用であり、インプレースで更新されるべきではないとエージェントに伝える必要がある場合、それはOKですが、その後、その領域に触れるすべて のエージェントにそれを伝える必要がある場合、あなたは低レベルの作業のためにループに戻ってしまいます。私たちが作成するどのようなメモリシステムも、ツールチェーン全体で機能する必要があります。コードレビューボットは、2週間前にこの領域のコードを書いたエージェントに発行した修正を認識している必要があります。安全でない本番操作を行ったSREボットを叱責するとき、エージェントはその理由を理解し、その後、将来のすべて のエージェントがこの修正を認識している必要があります。グローバルメモリは、主にツールの改善を待つ問題です。オープンスタンダードを作成するか、デイリードライバーエージェントとレビュー担当者、およびその他必要なすべてを1つのスイートで提供する統合スイートを使用するか、あるいはその両方になります。
• コードベースの腐敗防止。 エージェントはデッドコードを残していますか？1つの方法があるべきところに5つの方法がありますか？型システムは直感的ですか？データモデルは、私たちが提供しようとしている製品と一致していますか？何かがこれらすべてを処理する必要があります。そうでなければ、コードベースはスパイラルに陥り始めるでしょう。

最後の時代のプリミティブのほとんどもまだ必要です。例えば、APM（ただし、ウィジェットリッチなUIではなく、主にエージェントがログを読み取ることでクエリされるでしょう）やCI（ただし、より良いマージキュー付き）、A/Bテスト（ただし、エージェントが操作できるもの）などです。

エージェントが読み取れる開発スタックをどのように構築するか？

エンジニアリングチームが現在多くの作業を行う必要があるのは、エージェントがコードにバグがあるかどうかを知る前に、コードを必要なすべての方法で実行できるようにする非常に優れたクラウド開発環境を作成することです。この時点で、開発エージェントの制限要因は、モデルとハーネス自体ではなく、それらが動作する環境です。

別の言い方をすれば、エージェントは、より良い環境で動作していれば、より多くの作業を行うのに十分なほど優れています。しかし、それらは見えない場所でバグを作成します。エージェントが体系的に再現する方法を持たない競合状態、データの形状について無知であるため遅いクエリなどです。［3］

エージェントに盲点がある場所では、間違いを犯し、それが信頼を制限し、より多くの精査で作業をレビューする必要があることを意味し、それは私たちがどれだけ多くのことを委譲できるかを制限します。

したがって、エンジニアリングチームが現在行うことができる最も重要な投資は、開発環境をエージェントにとって非常にフレンドリーにすることです。しかし、現在、それは底なしのシュレップとワンオフのピットであり、どのようにやっているかを定量化する方法がありません。これらの開発環境のギャップを修正するには、良いアイデアと集中的なエンジニアリングが必要です。代表的なテストデータを持つローカル開発セットアップは、常に変化するターゲットです。良いテストを簡単に書くための適切な新しい抽象化を思いつくのは難しいです。そして、その他も同様です。この作業は困難です！

この作業はコードベース固有でもあり、まだごく少数の人々しかうまくできない芸術です。それが、多くのソフトウェアファクトリーが非常に残念な理由の1つです。私たちは、この種の投資を行うための、はるかに良い方法を必要としています。

それは、チームが開発ツールチェーンをエージェント対応にするのを助けることに多くのレバレッジがあることを意味します。エンジニアリングチームは、ローハンギングフルーツが何であるかを知るにはどうすればよいでしょうか？工場での作業をより良くするために、どのように作業を優先すべきでしょうか？彼らは、自分がうまくやっていることをどのように知ることができるでしょうか？もし私たちがこれを芸術ではなく科学に変え、エンジニアリングチームが体系的な進歩を遂げるのを助けることができれば、ファクトリーは稼働し始めるでしょう。

これが私たちの最善の推測です：

1. コードベースからバグをマイニングする。重要なバグを選ぶのが非常に上手になる。
2. バグを修正する。修正が正しいことを検証したり、そもそもバグが現実であることを検証したりするのを難しくするギャップを追跡する。
3. これらのバグ修正から得られたトレースを使用して、コードベースをエージェントにより適したものにするために必要な作業を優先する。

別の言い方をすれば、Detail の秘密の計画は、それ自身の作業をブートストラップする製品を作成し、その作業を使用してエンジニアリングチームがどのような投資を行うべきか、そしてそれらがどれほどうまくいっているかを知るのを助けることです。

もし私たちが任意のコードベースに対して有用な作業のコーパス（この場合は、エンジニアリングチームが修正したいバグ）をブートストラップできれば、それを使用して任意のコードベースをエージェントにとってより良くするための高ROIの方法を決定できます。リポジトリがどれだけエージェント対応であるかをベンチマークできます。エンジニアは、ほとんどすべての低レベルのバグが自律的に処理できるようになるまで、重要なギャップで作業を grind し、その後、エンジニアは真の高価値な作業、つまり機能のための良いアイデアを考え出し、実装を単純化する抽象化を見つけることに集中できます。

それが「生産性のプラトー」に到達する方法であり、そして最高のエンジニアリングチームが今後6ヶ月間運用する方法です。トークンマキシングはもちろん、AIを禁止することでもなく、このようなプロセスを使用してエージェントの準備状況をヒルクライムし、徐々に作業をより多く委譲していくことです。

私たちは今日、この一部をリリースしますが、このビジョンに向かって構築していく中で、これらのアイデアが製品でさらに形作られていくのを見るでしょう。

これは新しいことではない

テクノロジーは、低レベルの懸念事項を私たちを管理してくれるシステムに委譲することで進歩します。

2010年代に、私たちはソフトウェアをクラウドに移行し、物理的にどこで実行されているのか、あるいはサービスが実行されている仮想インスタンスさえも考える必要がなくなりました。より小さく、より集中したエンジニアリングチームが、今では成功したソフトウェア製品を構築できます。私たちは論理的な平面に住むことができ、プラットフォームが残りを処理します。しかし、私たちは同様の移行を経験しましたが、最初は非常に混乱しており、その過程で多くの不足しているプリミティブを理解する必要がありました。

CIとCDをセットアップするのはかつて数ヶ月プロジェクトでしたが、今では適切なプリミティブと成熟したツールがあるため、銀行メインフレームを移行している場合などを除けば、半日の作業です。同様の移行が「ループ」でも起こるでしょう。

私たちは採用しています！そして、もしあなたがこの旅に同行したいなら、ぜひ試してみてください：https://detail.dev/

---

［1］もし「センス」がかつて実際に差別化要因であったとしても、今はそうではありません。しかし、良いアイデアはそうです。

［2］いくつかのアプリドメインはかなりよく理解されています。eコマースウェブサイトの場合、カート放棄メール、「今、他のN人がこれを見ています！」ウィジェット、価格の横にあるスラッシュ付きのアンカー価格、その他すべてのようなものが必要になるでしょう。エージェントがプレイブックを実行すべきです。

［3］エージェントはまた、現実的なリスクが何であるかを知らずに、考えられるすべての曖昧さから防御したいという願望から、不必要に防御的なコードを大量に生成します。