リポジトリレベルのコーディングとは、CodePlan: LLM とプランニングを用いたリポジトリレベルのコーディング が、局所的な 1 か所で問題を解決するのとは対照的に、コードのリポジトリ全体に広くわたって編集を行うソフトウェアエンジニアリング活動を指して用いる用語である。同論文がこの定式化のもとにまとめている活動は、パッケージの移行、静的解析やテストから来るエラーレポートの修正、そしてコードベースへの型アノテーションやその他の仕様の追加である。
用法
この定式化は、大規模言語モデルに直接頼めることの境界を示すために導入されている。同論文は、GitHub Copilot のような LLM を活用したツールが、局所的なコーディング問題に対して高品質な解決策を提示することに成功してきたと指摘したうえで、リポジトリレベルのタスクはより複雑であり、LLM を使って直接解決することはできないと論じている。その理由として 2 つの性質が挙げられている。リポジトリ内のコードは相互に依存しているため、ある箇所の編集が別の箇所に影響を及ぼすこと、そしてリポジトリ全体がプロンプトに収まらないほど大きい場合があることである。
これら 2 つの性質があるために、この用語は、個々の編集が難しいかどうかではなく、構造的に難しいタスクを示すものとなっている。この定式化とあわせて報告された評価では、対象となったリポジトリレベルのタスク——C# におけるパッケージの移行と Python における時間的なコード編集——は、リポジトリあたり 2 から 97 ファイルにわたる相互依存的な変更を必要とした。
同じ 2 つの障害は、イシュー解決に関する研究でも、独立に述べられる形で再び現れる。Alibaba LingmaAgent：包括的なリポジトリ探索による自動イシュー解決の改善 はこの用語を使ってはいないが、同じ出発点から論じている。リポジトリには数千ものファイルが含まれることがあり、モデルのコンテキストに入れるには多すぎる——そして仮に大量のコンテキストを与えられたとしても、モデルは関連するコードを見つけるのに苦労する——一方で、1 つの機能のコードは順番に並んでいるのではなく、フォルダやファイルにまたがって論理的に散らばっているため、バグがエラーを発生させる場所と変更が必要な場所が別々のファイルにあることもある、というものである。その対応策は、一連の編集を計画することではなく、リポジトリをファイル、クラス、関数、呼び出し関係からなるナレッジグラフに凝縮し、そのグラフを探索することである。