「独立性」 そうだけど、モデルやツールのプロンプトが生成者とレビュアーで同じだったり似てたりすると、同じように失敗するよ。質問：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%見つけてくれるよ。でも、人間のレビューを完全に置き換えるわけじゃない。まだそこまで行ってないけど、役に立つツールだね。大体の人は、テストやリンターが先に動いてからコードレビューをするよね。

SOTAはコードの差分を出発点として使うことができない。HNのコメントの質の低さには驚いてる。ここ6ヶ月以上、あなたが言ってることを毎日やってるから、まさにその通りだよ。

今日のエージェントは、中央値の人間のコードレビュアーよりも「問題を見つけたり、基準を守ったりするのが上手くなってきている」。これは、良いコードレビューが主観的なものであることを意味していると思った。だけど、コードの基準やパターンを明確に定義すれば、リンターや自動化ツール、AIコードレビュアーは常に人間よりも多くのことをキャッチしてくれるよ。

でも、信号対雑音の比率が悪いね。 その通り。私が見たときは、いつもひどい。人間のレビューでも嫌なところなんだけど、名前について20個もコメント残して、実際の機能的な問題がその中に埋もれてることが多い。良いコードレビュアーは、イライラすることを全部無視して、重要なことに集中できるんだよね。コードに機能的な問題があるなら。AIがそれを克服できるかどうか、ちょっと疑問だな。かなり微妙なところだからね。でも、もしできたら、今の業界は多くの開発者にとって厳しくなると思う。エージェンシー以外では、これが自動化されにくい部分だったから。

コードレビューの重要なポイントの一つは、コードベースの進化を他のチームメンバーに理解させることだってことも言わないとね。レビュアーもレビューすることで得るものがあるし。

信号対雑音の理由で、最初にClaude CodeにPRをレビューさせるんだ。それから、実際のレビューに持ち上げたいものを選んでる。モデルにはない追加のコンテキストがあったり、ただの細かいことだったりすることが多いから。

AIの冗長さが本当に嫌い。コンテキストを与えることができるのは知ってるし、実際にやったこともあるけど、少しだけ助けになるだけだね。それでも、10個の「アイデア」を出してくるけど、その多くは互いに密接に関連してる。

最近ちょっと使ってみたんだけど、最初は楽しんでたんだ。でもすぐに、各マイナーなイテレーションごとに、nullとundefinedのチェックのループみたいな、いろんな小さな問題を見つけることになっちゃった。

同意するけど、無視するのは結構簡単だと思う。人間のレビューをLLMレビューに置き換えるつもりはないけど、頻度を下げて実行できる良い補完だと思う。だからこそ、ノイズを無視するのが簡単なんだ。大きなレビュータスクに対して、たくさんの変更があった後に使うからね。大体10個くらい見つけてくれて、その中の上位3つか4つは深く見てみる価値がありそう。

同意。Cスタイルの基本がうまくいってるのに、C++ライブラリコード、例えばstd::variantを提案してくるのには常に反発しなきゃいけない。

それは製品によるね。私の経験では、Copilotは信号ノイズがひどい。でもBugbotは素晴らしい。ノイズがほとんどなくて、私のチームの非常に経験豊富な人たちが見逃したものを一貫して見つけてくれる。

Codexを試してみるべきだよ。市場に出ているコードレビューのツールの質にはかなりの差があるから。

成功する方法の一つは、1) 問題を深刻度順にリストアップさせることと、2) それがどれくらい深刻な問題かを評価させることだね。そうすると、人間のレビュアーは上位10件のリストと、LLMが自分のリストについてどう思ってるかを簡単に確認できる。つまり、LLMが自分のアイデアをバカだと思ってたら、人間はあんまり深く考えなくてもいいってこと。問題の種類（命名、セキュリティ、パフォーマンス、正確性など）を明示的に指摘するのも役立つよ。人間はLLMに対して考える時間を割く必要はなくて、ただのアイデア生成ツールだからね。テーブル形式の上位10件リストを見れば、最初のチェックで10秒くらいでスキャンできるよ。

競争がないビジネスモデルは一番不安定だよ。他の誰もそのアイデアを持っていなかったら、たぶん間違ってる。彼らは持ってたけど、悪いアイデアだったから失敗したんだ。重要なのは、どうやって競争するかだね。ここにはたくさんの答えがあるけど、新しくて良いものは珍しい。

厳密に言うと、モデルに依存すること自体は問題じゃないと思う。そこには十分な「肉」があって、小さくて利益の出る会社を作ることができる。そういうツールは、モデルの評価や微調整に高額な人間の時間を使うことで、バニラエージェントよりも優れている。価値を加えるためのさまざまな統合、管理、報告機能も構築できる。もし今日、またはその会社のほとんどが始まった12ヶ月前にモデルの進捗を凍結したとしても、それは実行可能なビジネスだと思う。ただ、最初の部分で得た利益は新しいモデルに奪われるし、LLMが人々にかなり複雑な機能を迅速に構築させるようになると、2番目の部分の価値はそれほど高くなくなる。無価値かどうかは分からないけど、これらの会社は顧客を集めて、少なくとも買収のために自分たちを価値あるものにするための時間が非常に限られている。