5ヶ月間、バグを患者として扱い、コーディングエージェントを医療チームとして運用した実験

4月の水曜日の夜から金曜日の午後の間に、Cockroach LabsがデータベースをCockroachDBに移行するために出荷しているツールであるMOLTは、IBM Db2ソースからの移行能力を獲得しました。 商用で利用可能になった最初の関係データベースの1つであるDb2は、豊富なSQL方言、複雑な型システム、ネイティブなワイヤプロトコルを持っています。MOLTでそれをサポートするには、新しいスキーマコンバーター、行をプルしてCockroachDBに取り込むための新しいFetchパス、ロード後にそれらを比較するための新しいVerifyパス、ベンダー化されたANTLRグラマー、CI用のDockerイメージなどが必要でした。2024年にMOLTツールにOracleサポートを追加したとき、同等の作業には9ヶ月かかり、エンジニアリング時間で約16万ドルかかりました。Db2は2日未満で完了し、人間がコードを書いたわけではありません。トークンの請求額は4172ドルでした。164倍高速で、38倍安価でした。 すべては、その要求を説明する単一のGitHubイシューから始まりました。 次に、プランニングエージェントがそれを読み、一度にすべてを処理するには大きすぎると判断し、明示的な依存関係グラフを持つ15個のサブイシューに分解しました。まず基盤、次に型システム、次に行イテレータ、次にFetch、次にVerify、次にConvert、次にCI、次にテストデータです。サブイシューのうち2つは、その作業の中で大きすぎると判断され、再度分解されました。その過程で、エージェントは自身の作業に対してさらに12個のイシューを提出しました。フィクスチャのギャップ、型マッピングのバグ、分離レベルの修正です。親イシューがクローズされるまでに、その下に32個のサブイシューが開かれ、27件のプルリクエストがマージされ、レビュアーは作業を55回差し戻し、9件のイシューがエスカレーションされ、そのうち2件は人間にエスカレーションされました。テストカバレッジは、PostgreSQL（最もテストされた方言）に対する測定値と同等でした。 しかし、これらはすべてどのようにして起こったのでしょうか？これを推進していたものは何で、より重要なことに、最終的に高品質なものが出てくることを保証していたものは何でしょうか？Db2サポートのイシューを開く前に、まず、MOLT Sinaiと呼ぶコーディング病院を構築しました。MOLTはCockroachDBの移行ツールのセットの名前であり、パイプラインを病院にモデル化することにしたとき、MOLT Sinaiは抵抗できないほど良いポートマンテオでした。なぜなら、マウントサイナイは、私たちが住んでいるトロントとニューヨークの両方の都市にある著名な教育病院だからです。その名前は定着し、語彙も定着しました。イシューは患者です。マージは退院です。責任者は医学部長です。 エージェントが大量のコードを迅速に書くことは、この話に限ったことではありません。ソフトウェアファクトリーは業界の至る所に登場しています（OpenAIのここにあるようなものも）。私たちのケースでユニークなのは、それらのエージェントとメインの間にあるもの、なぜそれを病院のように見せるように構築したのか、そして5ヶ月間実際の作業でそれを実行したときに何が起こったのかということです。 なぜ教育病院なのか コーディングエージェントの問題は、コードを書く能力は十分にあるものの、十分にテストされ、保守可能で、望ましい範囲内にあるプロダクショングレードのコードを生成することを信頼するのが難しいことです。エージェントの実行コストは比較的安いですが、そのコードが顧客の手に入る場合、それはほとんど慰めになりません。私たちは、エージェントが実行に時間がかかる（10倍長くても）方が、顧客のCockroachDBへの移行で間違ったデータを着地させるよりも良いと考えています。スピードは重要ですが、品質ははるかに重要です。 過去1年間に、エージェントコーディングを自動化するいくつかの試みが出現しましたが、その多くはスループットに最適化されています。例えば、Gas Townは、コードの衝突を解決するためのマージ処理レイヤーを持つコードベースに対して、多くのエージェントを並列で実行します。これは、ボトルネックがコードの書き込み速度である場合に良い設計です。そして、Cursorからのこの実験があり、彼らはSQLiteを非常に迅速に再構築したため、変更量を処理するために独自のバージョン管理システムを書く必要がありました。それは興味深い実験ですが、明らかに品質の高いデータベースコードをユーザーに出荷するように設計されているわけではありません。初期のエージェント自動化実験の大多数では、スピードが主な動機でした。 私たちの動機は異なりました。私たちは分散SQLデータベースと、そのデータベースへのワークロードを移行するためのツールのスイートを構築しています。移行ツールの微妙なバグは、何よりも正確性を維持することを目的としたデータベースへの移行中に、誰かのデータを破損させる可能性があります。その結果、私たちが気にかけていた質問は「1時間あたりのPR数は？」ではなく、「それらのPRのうち、自分たちでマージしたことを恥ずかしく思うようなものはいくつあるだろうか？」でした。この再定義により、スループット最適化されたエージェントの群れが良いモデルではないことが明らかになりました。 そこで、私たちは、能力にばらつきのあるスタッフによる高リスクの作業を管理する長い経験を持ち、必須の引き継ぎ、必須のセカンドオピニオン、そして引き継ぎがずさんだった場合に何が起こるかについての文献があるモデルを探しました。そして、教育病院にたどり着きました。 この比喩は、私たちにこれらの役割を与えました。 その中心には、病院に入ったことがある（またはThe Pittを見たことがある）なら誰でも期待する他のアクターがいます。30分ごとに患者を探して回るチャージナース、メインが壊れたら建物中のすべてのワークフローをロックダウンできる感染管理エージェント、毎週のプロセスレビューを書き、インシデント後の会議を実行する安全部門、そして新しい作業を提案する研究部門です。 これが、群れよりも安価であるとか、単一のエージェントよりも単純であるとは主張しません。しかし、それはどちらよりも高品質な製品を生み出します。データベースビジネスにいるなら、その品質のためなら支払う準備ができています。以下で見るように、教育病院の残念な側面（官僚主義、待ち時間、コスト）のいくつかももたらしますが、それらは価値のあるトレードオフだと信じています。 どのように構築されたか 病院のすべてはGitHub Actionsで実行されます。各患者の状態は、イシューのラベル、および病院が各患者の進捗状況を追跡するために作成するいくつかのスクラッチファイルに格納されています。 各ステージはGitHubワークフローであり、その「ラベルイン」がイシューに付与されたときに開始されます。エージェントが完了すると、「ラベルアウト」を書き込み、そのラベルが次のステージの「ラベルイン」になります。破線の矢印は作業を戻します。作業の却下はワークアップへ、CIの失敗または変更要求は治療へ、そして停滞したステージは部長へです。 表示されていません：4つの部門は独自のスケジュールでこのフローの外で実行されます。チャージナースは停滞したステージを再実行し、感染管理はメインが壊れたときに病院をロックダウンし、研究部門と安全部門は新しいイシューとポリシーPRを提出し、それらは他の患者と同様に部長を通じて入ってきます。 ラベルを適用するとGitHubワークフローがトリガーされ、ロール固有のプロンプトがロードされるため、エージェントは病院の従業員として機能します。作業が完了すると、エージェントはそのイシューのチャートを含むファイルに構造化されたノートを追加し、フローの次のラベルを適用します。ノートには、後続のエージェントが検索して解析できるように、<!-- SINAI:TREATMENT_PLAN -->のようなセンチネルが含まれています。 スキルにエンコードされた基本的な病院のルールが、ほとんどの安全性を保証しています。 計画なしにコードを書かず、レビューなしに計画を立てない。フェローが何かを修正する前に、問題の再現、鑑別診断（病院の専門用語を使用）、ターゲットを絞った調査の実行、および治療計画の投稿（診断、変更するファイル、追加するテスト、リスク、未解決の質問）を行う必要があります。レビュー担当者（修正ではなく欠点を見つけることに焦点を当てたプロンプトで実行される別のエージェントインスタンス）が計画を読み、承認または却下します。その後にのみ治療が開始されます。このゲートを追加したのは、間違った修正を自信を持って実装するエージェントは、計画をチェックするために立ち止まるエージェントよりもはるかに多くの時間とトークンを無駄にするからです。 即興しない。治療中にスコープが変更された場合、フェローは停止し、改訂された計画を投稿し、計画レビューに戻ります。スキルファイル内の指示は2つの単語です。「即興しない」。 近道はしない、特にテストに関しては。エージェントは、テストをパスさせるためにテストを無効にしたり、スキップしたり、弱めたり、変更したりすることはできません。テストが失敗した場合、証明されるまでテストは正しいと見なされます。エージェントが本当に信じている場合