このポジションペーパーは、現在コーディングエージェントの比較に使われているベンチマークが、エージェント型ソフトウェアエンジニアリングが実際に構築し運用しているものと噛み合っていないと論じる。その中心的な主張は、実際のコーディングエージェントはモデルではなく システムハーネス であるというものである。すなわち、モデル、ハーネス、コンテキスト、環境、フィードバックシグナルの複合体であり、著者らによれば、そのいずれか 1 つだけでも、隣接するモデル世代間の差に匹敵する幅でベンチマークスコアを動かしうる。SWE-bench、HumanEval、MBPP、LiveCodeBench、BigCodeBench といったベンチマークは、単一のモデル、単一のハーネス、単一の環境が単一の数値を生み出すという 1 つの構造を共有していると説明される。著者らはこれを、個々のコンポーネントのレベルでのシグナルを持たず、しばしば単一の参照解と比較されるエンドツーエンドのシステムスコアとして特徴づけている。
手法は実験的ではなく論証的である。著者らは既存のコーディングエージェント評価研究を、自らが定義するシステムハーネスという観点から読み解き、全体を通じて、自分たちが構築してオープンソース化した課題駆動型のシステムハーネスである NS2 を具体的な参照例として用いている。そのハーネスの構築と運用を通じて、本論文が明確にしたずれの多くが浮かび上がったと述べている。本論文は、生成 AI の評価を社会科学的な測定問題として扱う研究から測定の語彙を借用し、構成概念（たとえば「バグを解決する」）とその操作化を区別したうえで、その言葉を使って自らの症状を分類している。モデルとハーネスの混同は弁別妥当性に関する主張として、単一参照解への固定は内容妥当性に関する主張として提示されている。
その貢献は、3 つの症状の診断とそれぞれに対して提案された構造的な改善策、そしてコミュニティに向けた行動の呼びかけである。著者らは 3 つすべての根底に操作化ギャップ（operationalisation gap）を置いている。これは Wallach らから借用し、エージェント型コーディングに適用した用語で、コーディングシステムが何をすべきかを、エージェントがそれをどのように試みるべきかを規定することなく、自動採点器が適用できる形でどう記述するかという問題である。著者らはこれを、このプログラムの中で最も難しい未解決問題であり、次世代のベンチマークに対する決定的な制約であると述べている。
主なポイント
- 実際のコーディングエージェントはモデルではなくシステムハーネスである。これは、上位の目標をタスクに変換し、それらを 1 つ以上のエージェントハーネスに振り分け、環境を管理し、出力をフィードバックを通じてルーティングするオーケストレーション層である。大規模な実践的エージェント型コーディングはこのレベルで行われている一方、現在のコーディングベンチマークはエージェントハーネスのレベルで動作している。
- ベンチマークスコアはモデルをハーネスの残りの部分と混同している。本論文の表 1 は、ある 1 つの固定モデルを複数のエージェントハーネスで動かした Terminal-Bench のリーダーボードのエントリを再掲しており、正答率はおよそ 58% からおよそ 80% に及ぶ。モデルはすべての行で固定されているため、著者らはこの幅をモデル能力の違いとしては説明できないと論じる。ただし、これは 1 つのリーダーボードと 1 つのタスク分布に基づくものである。
- 推論の労力（inference effort）は、十分に規定されていない変数として挙げられている。一部のモデル API では呼び出し側が使用する推論計算量を変更できるため、モデル名とエージェントのコードが名目上変わっていなくても出力品質が変わりうる。
- 単一の参照解に対する採点は、構成概念と粒度の両方を取り違えている。著者らは、フレーキーなテストを別の抽象度で API を記述し直すことで解決したエージェントは、バグが修正されたかどうかではなく参照テストが依然として成り立つかどうかで判定されると論じる。また隠されたユニットテストには、良いコードと単に動くコードを分けるもの ── 抽象化の選択、アーキテクチャへの適合性、システム設計 ── が見えないとも論じている。
- コンポーネントレベルのシグナルがないため、エンドツーエンドのスコアに基づく反復改善は難しい。スコアは何かが失敗したことは示しても何を直すべきかは示さないため、改善サイクルは直感頼みのアブレーションに堕してしまう。著者らはソフトウェアにおけるユニットテストと結合テストの違いになぞらえている。
- フィードバックシグナルは、範囲、レイテンシ、信頼性によって 3 つの階層に分類されている。インナーループ（数秒〜数分：テスト、型、リント、コンパイル）、ミドルループ（数分〜数時間：レビュアーの要求、シミュレーション、保守エージェント、スコアのルーブリック）、アウターループ（数日〜数週間：PR の受け入れ、リバート率、インシデント報告、顧客フィードバック）であり、これに、ハーネスが変更できるシグナルとできないシグナルを区別する第 2 の軸が掛け合わされる。
- 症状ごとに 1 つずつ、3 つの改善策が提案されている。提出時にハーネスを考慮したメタデータ（モデル、エージェントハーネスのバージョン、環境ハッシュ、データセットのバージョン）を必須とし、加えて固定したベースラインに対してモデル以外の軸で少なくとも 1 つのアブレーションを行うこと。単一の参照解から導出したテストセットを、プロパティテスト、参照オラクル、差分テストといった多様な形の振る舞い検証器に置き換えること。そしてハーネスのコンポーネントをそれ自体として評価対象とし、最終的なプルリクエストがマージされたかどうかだけでなく、保守エージェントについて対象範囲を限定した健全性指標の前後差分を報告することである。
- 本論文は自らに対する反対意見を示し、それに答えている。たとえば「エンドツーエンドのスコアは実際の利用を反映している」という意見（著者らは同意したうえで、自分たちが反対しているのはエンドツーエンドの指標だけを使うことだと述べる）や、「分解された評価はコストがかかりすぎる」という意見（著者らは、現在の実践における支配的なコストは、改善の原因を誤って帰属させることによる機会費用だと主張する）である。
注記
本論文は、同じ方向に進んでいると自らが読み取る一群の研究と並ぶものとして自らを位置づけている。すなわち、ハーネスやスキャフォールドそのものを測定の対象として扱う研究や、テストに合格するだけではもはや成功とみなされないエージェント型ソフトウェアエンジニアリングという分野を枠づける研究である。本論文は自らの議論を、その枠組みに対応する測定面での対応物として提示している ── 成果物が複合的なシステムであるなら、ベンチマークは複合的なシステムを採点しなければならない。
ポジションペーパーであるため、独自の新しい実験やデータセットは提示していない。その根拠は公開済みの評価研究の読解と、著者ら自身のハーネスを運用した経験であり、著者らは 3 つの改善策の根底にある操作化の問題が未解決のままであることを明言している。再掲されている Terminal-Bench の数値はそのリーダーボードから引用されたものでここで測定されたものではなく、ハーネスに起因するばらつきの大きさについての著者らの主張は、その表と引用された実践者の報告に基づいている。