この論文は、高忠実度の文書からリポジトリへの合成 — 中心となるのは、論文そのものだけを仕様として、 科学論文の実験を完全で実行可能なコードリポジトリとして再現すること — のためのオープンなエージェント型 コーディングフレームワーク DeepCode を提示する。論文は中核的な障害を、情報過多（論文は長くマルチ モーダルな仕様である）と、生成を行う LLM の有限なコンテキストウィンドウとの衝突として捉え、リポジトリ 合成を情報フロー／チャネル最適化の問題として扱うことを提案する。
DeepCode はこれに 3 つのフェーズで取り組む。Blueprint Generation（Concept Agent と Algorithm Agent が 階層的にインデックス化された元文書をそれぞれ独立に分析し、Code Planning Agent がそれを単一の実装 ブループリントへと統合する）、Code Generation（そのブループリントに沿ってファイルを反復的に生成する。 その際、生成済みファイルについての状態を持つ要約ベースのメモリ CodeMem と、外部リポジトリのパターンを 必要なときにだけ注入する検索拡張システム CodeRAG を用いる）、そして Automated Verification（静的解析の パスに続いてサンドボックス内で実行し、実行時エラーを修正のシグナルとしてフィードバックする反復ループを 回す）である。
要点
- PaperBench Code-Dev の ICML 論文 20 本からなるベンチマーク（OpenAI の o3-mini 上に構築された自動 判定器 SimpleJudge によって採点）で、DeepCode は 73.5±2.8 を記録した。これに対し、最良の汎用 LLM エージェントのベースライン（Iterative Agent の足場を用いた o1）は 43.3±1.1、科学コードに特化した エージェントのベースラインである PaperCoder は 51.1±1.4 であった。
- 同じ基盤モデル（Claude Sonnet 4.5-thinking）を用いて商用のコーディングエージェントと直接比較した 論文 5 本のサブセットでは、DeepCode は平均 0.8541 を記録し、Claude Code の 0.5871、Cursor の 0.5841、Codex（GPT-5-Codex-high）の 0.3997 を上回った。論文は、Cursor や Claude Code と基盤モデルを 共有していることを踏まえれば、この差は向上がモデルの選択ではなく DeepCode のアーキテクチャに由来する ことを示していると論じる。
- 論文 3 本のサブセットでは、DeepCode は平均 75.9±4.5 で、人間のベースラインの 72.4（Berkeley、 Cambridge、Carnegie Mellon などの機関に所属する ML の博士課程学生・博士号取得者 8 人が、4 週間に わたりパートタイムで取り組んだ 3 回の試行のうちの最良値）を上回った。
- 5 つの LLM バックボーンにわたるアブレーションでは、DeepCode のアーキテクチャを固定した場合、再現 スコアがモデルの能力に密接に連動することがわかった。Claude-4.5-Sonnet と GPT-5 は 3 つのタスクで 0.69〜0.82、Claude-3.5-Sonnet と Gemini-2.5-Pro は 0.44〜0.73、DeepSeek-R1 は 3 つすべてで約 0.29 で あった。
- Gemini-2.5-Flash で CodeRAG をアブレーションしたところ、CodeRAG の追加によって最大 70% の相対的な 向上が見られたが、論文はフロンティアモデル（Claude 4.5 Sonnet）に CodeRAG を追加しても向上は ごくわずかだったと報告しており、CodeRAG は主に、自らのパラメータ内に十分な実装パターンを持たない コスト効率の高いモデルに役立つと結論づけている。
- CodeMem のアブレーション（素朴なスライディングウィンドウ方式でメッセージを追い出すベースラインとの 比較）では、素朴な手法は基盤となるクラス定義をコンテキストの切り詰めによって失うため、一部のタスクで 0.33〜0.43 まで低下したのに対し、CodeMem は同じタスクでスコアを 0.70〜0.92 に回復させた。
- Automated Verification フェーズのアブレーションでは、一貫しているが比較的控えめな 3.7〜6.5% の向上が 見られた。論文はそれ以前のフェーズで技術的な正しさの大部分がすでに達成されていると位置づけており、 この向上は主に、より深いロジックの問題を直すことではなく、残存するエラー（変数名のタイプミス、依存 関係の欠落、誤ったコマンドライン引数）を修正することによるものとされている。
- 論文は今後の研究のための 3 つの未解決課題を挙げている。エージェントとしての能力と計算コストの トレードオフ（大規模モデルと小規模モデルを組み合わせたハイブリッドアーキテクチャを提案）、プロジェ クトごとにリセットされる「エピソード的」なエージェントから再利用可能な経験を蓄積するエージェントへの 移行、そして直線的な「計画してからコードを書く」ワークフローから、実装の途中でブループリントを改訂 できる動的で双方向の計画への移行である。
補足
この論文は査読中のプレプリントであり、公開時点では査読を経ていない。評価は、論文独自にゼロから構築 したベンチマークや人間による採点ではなく、PaperBench Code-Dev（OpenAI が作成した既存のベンチマーク） と LLM ベースの自動判定器（OpenAI の o3-mini 上に構築された SimpleJudge）に依拠している。人間の専門家 との比較ベースラインも、この論文が新たに収集したものではなく、ベンチマーク自体の先行する公開物から 取られている。DeepCode のソースコードは github.com/HKUDS/DeepCode で公開されている。