【読むだけでバグが直る】大LLM時代のOSSバグ修正はこう変わる
この記事は何か？
- 「LLMと一緒にOSSコードリーディングをするVSCode拡張」に「バグ修正をする」新しい機能を加えました（VSCode拡張の詳細は下を参照）
-
「関数探索するだけでバグが直る」ユーザー体験が、今後のLLM時代の超大規模コードバグ修正になるのでは？
-
まだ作りたてほやほやなので、今後は自分でもバグ見つけられるか試してみたいです
OSSバグ修正までの長い道のり
OSSバグ修正。それはコードベースが大きくなればなるほど、修正が小さいように見えても裏に見えないのは苦難の連続です。
実際、私も Next.js に１件だけバグ修正でコントリビュートしたことがありますが、
2023年12月から始めた Next.js のコードリーディングから、自分で出したPRがマージされるまで4ヶ月ほどかかりました。
調査した issue の数は10件を超え、時にはuglifyされたReact Server Componentのコードを読み、時にはReact本体にPRを投げたりして、たまたま専門外だった Server ActionのバグIssueを直そうと思って調べたら、たまたま当たりを引いただけでした。
その道は険しく、とても再現性のあるものではなかったと思います。
そんなOSSのバグ修正は、未来では 「コードをLLMに人間制御のもと読ませれば、勝手にバグが直る」 に変化するのでは？という仮説を持ったので、この記事を書きました。
どう変わる？OSSのバグ修正は？
では OSSのバグ修正はどう変わるのでしょうか？
簡単に言うと、以下のようにしてOSSバグ修正のステップは変わると思っています。
[Step1]コードリーディング
<before>人手で行うもの
<after> LLMが行うもの
[Step2]バグ修正
<before>Issueをあさって人が修正するもの
<after> IssueをもとにLLMがバグを修正するもの
Step1は下記の記事で書きました。
さて、ではどのようにStep2でLLMがバグを修正するか？
それは、「Step1で人がLLMと探索した結果をもとに関連するコードのみを渡して、バグを発見してもらう」です。
つまり、「関数探索をしながらバグ修正ができる」。
さらにこれを応用すれば、
１：なんなら人の制御がなく勝手に探索してバグを直す
２：関数探索中に勝手にコードを直す
３：Issueからの情報吸い出しもLLMが行う
のようなことも実装可能だと思っています。
「こんなこと結構簡単で自分でも思いつきそうだわ」
そうです。これは発想としては簡単で、LLMを使ったコードリーディングの実装をしたことがある人なら簡単に思いつきそうなアイデアです。
ただ自分はこれを思いつくまで、１週間かかりました...
思いついたら吉日。で、この実装を書いたのがつい今日の夜中1時。
そして、version 1.0.11 として一旦「これまで読んだ関数群の情報をもとにバグ修正する」機能を、10のコマンドとして登録しました。
やっていることは簡単。
ただレポート機能で関数群を渡してレポートを生成しているのの、バグ修正版です。
これまで行った関数探索で取得した関数群からバグがないかをLLMに渡して判断してもらっています。
ちなみに kubernetes の関数探索でこの「バグ修正」機能を使ったところ、まだ誰もが驚くような当たりは引いていませんが、Claudeは簡単な修正案を提案してはくれていました。
【思考実験】何が今までと違うか？
これはなぜこの考えが、今までのLLMコーディング製品よりも優れていると言えるか？
私自身Clineを真似した自作エージェントを使うくらいで、Devin や Codex は使ったことないので、実地の強い製品は見聞きした情報のみの判断になり、間違った情報もあるかもとは思いますが、
などを参照する限り、既存のLLMは大規模コードの修正に関して幾つかの欠点を持っていると思います。
- 長時間タスクは迷走しがちだそうだが、大規模コードの文脈を適切に切り分けできないのかも
- LLMとLSPを組み合わせるのはDevinなども裏では行うことはできるが、どうやらデフォルトではない（もしくはLSPの知名度が低くユーザー目線だとあまり気にされないか...下記リンクのLSP箇所）。つまり Devinは、LLMとLSPを組み合わせることを手段としていない可能性はなきにしもあらず、と想像しています（またC系のLSPの場合はcompile_commands.jsonを用意しないといけない場合もあって面倒なので、全言語対応は意外と面倒）。
-
LLMとLSPを組み合わせたとて、LLMの精度が高くない場合も個人的には観測しているので、そこら辺の制御は今後のLLMの発展にかかっている
-
ClineはLSP組み込みを実装はしているもののLSPを深く実装の中で使っていない（２ヶ月前に確認したところ定義されているだけで深くまで使っていないなと言う感想だったのですが、間違っていたらすみません！）
などの状況が想像されます。
これらの問題の本質は、３つあるかなと思っています。
- 今のLLMではコンテキストに入れる情報に限りがある
- コンテキストに入れる情報が無限だったとしても、ある程度構造化するか範囲を絞らないと、コード理解にはならない
- だからと言って、コーディングエージェントではLSPを頻繁には使わない（最低限Clineは）
だったら、その後者の「ある程度構造化するか範囲を絞」る部分は関数探索したついででできるよね、というのを LSPなしでできるかというと個人的には疑問でした。
今後の展望
とはいえ、作ってはみたものの、出来立てほやほやでまだ試用段階です。
また個人の技量の拙さで私の作ったVSCode拡張では、まだバグが残っていたりします。
なので、今後は自分で作ったものを使ってみて、自身のバグを直したり、Go言語の大規模OSSのバグを的確にLLMが見つけてくれるかを見てみたいと思います。
また、もし興味があったら、JavaやTypeScriptで実験しても面白いかもしれませんね（Cは２回目になりますが、compile_commands.jsonを用意しないといけないので汎用的ではなく面倒でした...）
短い概要だけの記事でしたが、ここまで読んでくださりありがとうございます！
Discussion