コーディングエージェントが実際に行動するために必要なコンテキストは何か？
新しい研究によると、コーディングエージェントがコード編集時に本当に必要なコンテキストは最小限であり、信号は編集対象のコード自体にのみ存在する。自然言語要約はソースコードが答える行動質問にほとんど答えられず、周囲のコンテキスト（UMLスケルトン）は削除と同等で、圧縮コンテキストは三分の一のトークンで完全なファイルと同等の性能を示す。温度0推論では約9%の結果が変動し、ノイズフロアとなる。著者らは検証済み環境、決定論的パッチ、事前登録済み仮説を含むツールを公開している。
現代のコーディングエージェントはリポジトリ全体をコンテキストウィンドウに収めることができるが、その読み取りの大半は無駄である。Brian Sam-Bodden氏がarXivに提出した新しい研究（論文番号2607.09691）では、エージェントがコードを編集する際に実際にどの程度のコンテキストが必要かを調査している。研究者らは「発見」と「行動」を分離し、発見部分をオラクルで固定してコードの表現のみを変え、SWE-bench Verified上で実際の問題解決能力を評価した。
結果は驚くほど最小限であった。本当に必要な信号は編集対象のコードそのものに存在する。自然言語による要約は、ソースコードが答えられる行動質問のほとんどに答えられない（4/45対27/45、独立した評価者による）。この差は要約器ではなく表現に起因しており、フロンティアモデルの要約でも3Bモデルと同様に低いスコアだった。周囲のコンテキストもほとんど重要ではない。すべてのマルチファイルインスタンスにおいて、ファイルの残り部分をUMLスケルトンとシグネチャで表現しても、完全に削除した場合と比べて解決される問題の数に有意差はなかった（N=70、マクネマー検定p=0.75）。これは事前登録された仮説であり、棄却された。
一方、圧縮コンテキスト（クラスシグネチャやインターフェースなど）は、トークン数が三分の一で完全なファイルと同等のパフォーマンスを達成した。解決された問題あたりの平均コンテキストトークン数は19Kであり、94Kではない。さらに、温度0のAPI推論は、バイト単位で同一の実行間で約9%の結果を変動させることが判明した。これはSWE-bench上で報告されるすべての小効果に対するノイズフロアとなる。
研究者らは、ゴールドバリデーションされた環境、各インスタンスで参照編集がすべてのアームのコンテキストから表現可能であることの証明、決定論的パッチ構築、および帰無仮説を公開した事前登録仮説を含むツールを公開している。これらの成果は、コーディングエージェントの能力をより正確に評価し、コンテキスト使用を最適化して推論コストを削減するのに役立つ。