Overview
タイトルのとおりなんですが、Serena MCPはClaude Codeを救うのか？ の記事に触発されて、ここ2ヶ月くらい LLM (Claud Code) と serena をセットで利用しています。
最初はトークン数を削減できるとか、Agentic Coding ならではのペインを解決できるものとした一過性の流行りかなと思って静観していたのですが、使ってみながら挙動を眺めてると LLM も人間と同じようなコードの読み方をしているんだなということを感じられて、アウトプットの精度も向上したので結果として使い続けています。
どういうところが人間とにているのか？
例えばある実装やコードの調査においてその依存先まで含めて調査をしたいときに LLM に「〇〇という関数の実装を依存先まで含めて詳細に調査し、説明してください」というプロンプトを入力したとします。
このとき、LLM は愚直に〇〇という関数とその依存先のコードをファイルを探して、依存先を grep して、というような流れをたどることが多いです。
さながら「人間が find して grep して」を繰り返すのと同じような振る舞いをしています。そしてやったことがあればわかりますが、この調べ方はめちゃくちゃハイコストです。現代でこんな感じで実装の調査をすることは稀ではないでしょうか？
基本的には Editor に備わっている依存先へのコードジャンプや Call Hierarchy を追っかけていって調査することが多いと思いいます。
serena を動かしてるときのコードの探索の仕方はさながらこれです。serena も LSP を使ったコードの解析をしてると明言しています。
つまり serena を使わずにコードを探索するというのはさながら今どきな Editor を使わずにメモ帳で開発してるようなもので、かなりハイカロリーなことを LLM に要求してることになるのとほぼ同じことなんだなと使っていて気づきを得ました。
人間ももはや Editor 同梱の LSP や独自の Index をつかったコードジャンプがない世界で実装を進めるなんてものは厳しいを通り越してもう無理なんじゃないかとすら思います。
LLM と LSP
serena はどういった立ち位置のプロジェクトなのかは自分はあまり詳しくないですが、LLM に LSP がついてコードを解釈できるようになった、というのはめちゃくちゃ効くな、と実感しました。
エントリでも言及されていますが、今後は LLM も IDE のようなコードを解析して index を貼っておく、という風に進化していきそうな気がします。というかコードを書くのであれば絶対必要なサポートだと実感します。
自分ですらもう Editor のサポートがない世界でプログラミングをするのは無理なので、LLM もまぁ多分ハイカロリーなんだろうと想像しています。そしてそれを少しでも減らせるなら使って損はないなと思います。
Agentic Coding はモデルを持っているところが先行してこういったプロトコルのサポートを表明、サポートしていくことで開発者体験も高攘夷していくと思うので、ぜひとも各社頑張ってほしいとも思いました。
serena を使い続けてる理由
ちなみに LSP を使うのであれば普段自分自身は Go をメインで使っていて、公式が gopls の MCP を公開していたりするので、そちらを整備すれば良かったりするんですが、serena は Go 以外にも対応してることと、Docker をつかうと local で簡単に起動できるという手軽さ + コンテナイメージは公開されているので必要なツールが増えたときに公式の対応待たずとも自分でイメージをカスタマイズすればいい、というポータビリティの高さが自分の使用感にマッチしているので利用を続けています。
モデルを提供してる公式が自前の Coding Agent に LSP を導入してくるまでは利用続けようかなと思っています。（なお明日には別のツールに移行してる可能性もあります）
