「独立性」 そうだけど、モデルやツールのプロンプトが生成者とレビュアーで同じだったり似てたりすると、同じように失敗するよ。質問：Claudeが書いたコードのCursorレビューを、Cursorが書いたコードのCursorレビューより信頼できると思う？それとも、あまり変わらない？ 「自律性」 たくさんのツールがAI支援のレビューに多くの投資をしていて、人間のレビュアーが差分を理解しやすくするための素晴らしいUIを作ってる。私たちの見解では、コードの検証は中期的には完全に自律的になるだろうから、私たちのシステムは人間の介入をオプションにするように設計されてる。これはあまり人気のない意見かもしれないけど、AI生成コードは常に人がレビューするべきだと言う意見も尊重してる。ただ、私たちがこの職業に望む未来ではないし、予測している未来でもない。 「ループ」 UXやツールに投資して、これを簡単にしたり難しくしたりできる。私たちがこれを簡単にするための第一歩は、/pluginsコマンド内のネイティブClaude Codeプラグインで、Claudeが計画を立てて、書いて、コミットして、レビューコメントをもらって、また計画を立てて書くループを実現することだ。

誰もが「すごく」良いとは思ってないよね。今ではリントを超えてると思うけど、9ヶ月前はそうでもなかったかも。これが証拠になるかはわからないけど、過去7日間でPRの著者がGreptileのコメントに「いい発見」「グッドキャッチ」って返信した回数は9,078回だよ。

私が作業していたコードの中で、こんな感じのがあった。 // stuff obj.setSomeData(something); // 他のコードが15行 obj.setSomeData(something); // もっとstuff 「something」はちょっと複雑だったけど、フォーマットが少し違う同じものだった。私のリントは重複した呼び出しを見逃した。AIチャットにコード変更のレビューを頼んだら、重複した呼び出しを正しく指摘してくれた。List objs = someList.stream().filter(o -> o.field.isPresent()).toList(); // ... var something = someFunc(objs); Thingy someFunc(List param) { return param.stream().filter(o -> o.field.isPresent()). ... そのフィルターの一つは不要だったんだけど、呼び出しの境界を越えてそれをキャッチしてくれた。だから、AIコードレビューはリントよりも良いと思う。ただ、アプリケーションの全体的なコンテキストやデータに関する保証、チームのコーディング規約（特に内部用語の命名規則の使い方）を知らないから、気にすることもある。

SOTAはコードの差分を出発点として使うことができない。 出発点ではないけど、大きなプロジェクトの複雑なフォークで、git diff main..fork > main.diffを使って、私が持っている仕様を読み込んで、差分をチャンクごとにレビューしながら./review.mdを更新することで、かなり良い結果が出てる。自分でいくつかのコミットを十分にレビューしなかったことで作った問題を解決してるけど、複数のコミットにまたがるインタラクションを見逃さずに拾ってくれるから、驚くほど効果的だよ。

Opus 4.5は、リンターでは見逃すようなことをたくさんキャッチしてくれるし、手動での促しもほとんどいらないんだよね。DBのインデックスが抜けてたり、忘れられたマイグレーションのシナリオ、似たようなサービスとの不一致、見落とされたエッジケースとか。今はロボットに定期的にブランチをレビューさせて、自分の考えに穴を開けてもらってる。コツは、LLMを確認用のマシンとして使わないこと。人間のレビュアーの代わりにはならないし、LLMのコードレビューをするために新たにCI統合にお金を払う意味がわからない。

GH Copilotは、単なるリンターよりもずっと優れている。具体的な例はないけど、私が特に注目したのは、diffの変更以外の文脈を使うところ。PR自体では通常見えない文脈を引き込んでくれる。例えば、これが典型的なパターンに従っていないとか、このバージョンは再利用可能なコードにすでにカプセル化されているとか、ここで使える既存の定数があるのにハードコーディングされた値を使っているとか。

それには完全に同意するわけじゃないな。私はAIコードレビューにCopilotを使ってるけど、GitHubに組み込まれてて使いやすいから。結果はバラバラだけど、全体的には悪くない。AIを使う以上、何をしているかを理解する必要があるから、自分のコードやアプリケーションの構造を理解しておかないと、全く的外れなことを言われることもあるし、逆のことを言われることもある。だから、そういう時は無視して会話を終わらせる。とはいえ、伝統的なリンターが見逃すようなバグや問題をたくさんキャッチしてくれるのは確か。自動テストの穴を埋めたり、セキュリティの問題を見つけたりするのに役立つし、一般的に良い修正案を出してくれるPRを上げてくれることもある。たまにそうじゃないこともあるけど、その場合も無視して次に進む。AIコードレビューは全くないよりはマシだと思うから、スタートアップには良いと思う。開発者が自分だけだったり、1、2人しかいない場合には特にね。でも、私が言いたかったのは、Copilotを使うのはGitHubのサブスクリプションの一部だから。これが一番いいのかはわからないけど、私にとっては統合コストゼロで価値を追加してくれる。だから、多くのGitHubのサブスクライバーにとってデフォルトのAIコードレビューオプションになると思う。そうなると、GitHubやGitlabのようなホスティングプラットフォーム以外でのAIコードレビューの未来がどれだけあるのか気になるし、厳しい統合が来るんじゃないかと想像してる。

GitLabでのレビュー用にCodeRabbitをインストールしたんだけど、結果には結構満足してる。特に低価格（たしか$15/ユーザー/月）を考えるとね。定期的に問題を見つけてくれるし、人間のレビュアーが見つけにくい微妙だけど重要な問題も見つけてくれる。修正案も結構良いのを出してくれる。ただ、理論上可能だけど実際には無理なことについて文句を言うことが多いから、そのコメントは特にアクションを取らずに解決することに慣れてしまった。もっとタイプを効果的に使えば、そういうことは減るかも。CodeRabbitの言うことには、DeepSourceを使っていた時よりもずっと注意を払っているよ。

AIコードレビューは、AIコード自体に似てると思う。平凡なこと、例えばリストが正しく逆転されているか、ポインタを正しく扱っているか、オフバイワンの問題がないかなどにはうまく対応できるけど、高レベルの問題、例えばコードが実際にビジネスの問題を解決しているか、正しい依存関係を使っているか、より広いデザインに合っているかなどには弱い。これは私にとっては予想通りだし、素晴らしい助けになってる。人間としては、ポインタのライフサイクルを正しく管理しているかをチェックする時間を減らして、コードが必要なことをするためにそこにあるかを確認することに集中できるのが嬉しい。

彼らは、私が作業しているコードのバグを100%見つけてくれるよ。でも、人間のレビューを完全に置き換えるわけじゃない。まだそこまで行ってないけど、役に立つツールだね。大体の人は、テストやリンターが先に動いてからコードレビューをするよね。