この arXiv プレプリントは、コードベース全体に一度に手を入れる種類のソフトウェアエンジニアリング作業 ── パッケージの移行、静的解析やテストによるエラー報告の修正、型アノテーションやその他の仕様の追加 ── を取り上げ、それを リポジトリレベルのコーディング として定式化している。これらを別個に扱う理由として著者らが挙げるのは、大規模言語モデルを基盤とする GitHub Copilot のようなツールは局所的なコーディング問題では成功を収めてきたが、リポジトリレベルのタスクは LLM を用いて直接には解けない、という点である。リポジトリ内のコードは相互に依存しており、リポジトリ全体がプロンプトに収まらないほど大きい場合がある。
本論文の回答は、リポジトリレベルのコーディングをプランニング問題として捉え、それを解くためのタスク非依存のフレームワーク CodePlan を提示することである。CodePlan は多段階の編集の連鎖 ── プラン ── を合成し、その各ステップは特定のコード位置に対する LLM の呼び出しとなる。その際のコンテキストは、リポジトリ全体、過去のコード変更、タスク固有の指示から導出される。著者らは、このフレームワークが 3 つの要素の新しい組み合わせに基づいていると説明している。すなわち、インクリメンタルな依存関係解析、変更の影響可能性解析（may-impact analysis）、そして適応的プランニングアルゴリズムである。
CodePlan は 2 つのリポジトリレベルのタスク ── C# におけるパッケージ移行と Python における時間的なコード編集 ── で評価されており、いずれも 2〜97 ファイルにわたる相互依存的な変更を要する複数のリポジトリを対象としている。著者らは、このレベルの複雑さを持つコーディングタスクが LLM を用いて自動化されたことはこれまでなかったと述べている。CodePlan はベースラインよりも正解データによく一致し、6 つのリポジトリのうち 5 つで妥当性チェック（たとえばエラーなしでビルドできること、正しいコード編集を行うこと）を通過させたと報告している。一方、同じ種類のコンテキスト情報を持つがプランニングを行わないベースラインは、1 つのリポジトリも通過させられなかった。
本論文はソフトウェアエンジニアリング（cs.SE）に分類され、2023 年 9 月 21 日にバージョン 1 として投稿されており、arXiv が発行した DOI 10.48550/arXiv.2309.12499 が付与されている。
主なポイント
- 本論文は、パッケージの移行、静的解析やテストによるエラー報告の修正、型アノテーションやその他の仕様の追加を、リポジトリレベルのコーディングタスク ── リポジトリ全体に広く及ぶ編集を伴う活動 ── として定式化している。
- これらが LLM の直接的な利用になじまない理由として、2 つを挙げている。リポジトリ内のコードは相互に依存していること、そしてリポジトリ全体がプロンプトに収まらないほど大きい場合があることである。
- CodePlan は、問題をプランニングとして扱うタスク非依存のフレームワークとして提示されている。多段階の編集の連鎖を合成し、各ステップでは、リポジトリ全体、過去の変更、タスク固有の指示から得たコンテキストを伴って、1 つのコード位置に対して LLM を呼び出す。
- このフレームワークは、インクリメンタルな依存関係解析、変更の影響可能性解析、適応的プランニングアルゴリズムの新しい組み合わせとして説明されている。
- 報告されている評価は、2 つのタスクと合計 6 つのリポジトリを対象としている。CodePlan は 6 つのうち 5 つのリポジトリで妥当性チェックを通過させたのに対し、プランニングを行わないベースラインは 6 つのうち 0 だった。この比較ではベースラインにも同じ種類のコンテキスト情報が与えられているため、著者らはその差をプランニングに帰している。
注記
ベースラインは 1 つの変数を切り分けるように構成されている。アブストラクトによれば、ベースラインは CodePlan と同じ種類のコンテキスト情報を持ち、プランニングを行わない点だけが異なる。評価の規模はリポジトリ数で見ると小さく、2 つのタスクを合わせて 6 つである一方、リポジトリごとの変更は 2〜97 ファイルと大きい。この複雑さのタスクが LLM を用いて自動化されたことはこれまでなかったという著者らの主張は、先行する技術水準に対する著者ら自身の評価としてアブストラクトで述べられているものである。