愚痴っていました。 また。
コードレビューが私の時間を食っていて、問題はますます悪化するだけでした。より速く、より多くの機能を出荷していました。その結果、コード量も増えます。しかも、その多くは私が深くは知らない領域のものです。エージェント型の開発はアウトプットには最高です。でも、作られたものをまだ理解しなければならない人にとっては、あまり良くありません。
一緒に働くAmitaiは、それについて聞くのにうんざりしていました。彼は私にリンクを送ってきました。
Tip 26
この記事は@ykdojoによる45 Claude Code Tips: From Basics to Advancedです。Tip 26はインタラクティブなPRレビューについてで、次のように述べています：
Claude CodeはPRレビューにとても向いています。手順はかなりシンプルです。
ghコマンドでPR情報を取得させ、その後は好きなやり方でレビューを進められます。全体のレビューをすることもできますし、ファイルごとに順を追って進めることもできます。進むペースをあなたがコントロールします。どれくらい詳細を掘り下げたいか、どの程度の複雑さのところまで扱いたいかもあなたが決めます。たとえば、全体の構造をざっと理解したいだけかもしれませんし、テストも走らせてもらいたいかもしれません。
重要な違いは、Claude Codeが「一発で終わる」機械ではなく、インタラクティブなPRレビュアーとして振る舞う点です。いくつかのAIツールは（最新のGPTモデルを含め）ワンショットのレビューには得意ですが、Claude Codeなら会話できます。
一度試してみました。 それからまた。 そしてそれをスキルにしました。
Why I still read the code
ワークフローの話に入る前に、部屋の隅にある象について触れておきたいと思います。
エージェント型の時代におけるコードレビューは、実際にかなり議論が分かれています。時代遅れになっていくと思う人もいます。私はそうは思いません。
エージェントはたくさんのコードを書きます。その一方で、たくさんの「手抜き」も生み出します。つまり、最適でない解決策、標準的でないパターン、チームの慣習に合わないもの、そしてときには単純なバグです。責任は依然として私たちの側にあります。Claude Codeの作者であるBoris Chernyでさえ、彼は自分が生成したコードを今でも読んでいると言っています。
さらに現実的な理由もあります。コードを書いた本人が来週は休暇を取っているかもしれないのです。私はそれを引き受けられて、変更できて、そして擁護できる必要があります。それが起きるのは、レビューの段階で実際に理解している場合だけです。
PhaseVでは、CoPilotがすべてのPRに対して自動レビューを実行します。その上で私はCodexと、Claude Codeに組み込まれたスキルを使って、ワンショットのレビューも手動で回しています。それらは本当に役に立ちます。とはいえ、自動レビューはコードの理解とは同じではありません。理解には人間が必要です。
How the flow works
私たちのチームは、変更の物語になるコミットを書きます。各コミットは原子的で、焦点が絞られています。
私は/review-pr-interactiveとPR番号を入力します。そこから：
- Claudeがブランチをチェックアウトし、PRの目的を要約します
- すべてのコミットを1行の説明付きで列挙します
- 最初のコミットから始めます。何が起きているのかを説明し、注意すべき点を挙げ、次に進む前に私の見解を求めます
- 私は自分でコミットを読みます。もし想定より大きいなら、掘り下げる前にファイルの推奨読解順をClaudeに提案してもらいます
- 一緒に、コメントする価値があるものを決めます
- ClaudeはGitHub CLIを使って、正確に関連する行にコメントを投稿します
そして次のコミットへ進みます。
私がよく分からないものに当たったら、Claudeに聞いて新しいことを学び、その後はたいていTwitterの#TILのところに投稿します。
Why a skill and not just a prompt
ここであなたは疑問に思うかもしれません。なぜこれをスキルとして形式化するのか？毎回、Claudeにやりたいことをその都度伝えればいいのでは、と。
答えは一貫性です。レビューを開始するたびに、Claudeはすでに私たちのチームの慣習を知っています。コメントに使うトーン、Nitpickと見なすもの、そして何かを投稿する前に私の承認を待つべきことも分かっています。私は再説明しません。何かを言い忘れることもしません。スキルとは、うまくいかなかったセッションを積み重ねた結果としての、蓄積された知識です。
具体例を1つ挙げます。私がスキルを書く前は、Claudeは各セッションで適切なghコマンドを見つけるのに、だいたい3回ほど試行していました。PRの特定の行にコメントを追加するためのコマンドです。今ではスキルに書き込まれているので、最初の一発で正しくやってくれます。
それにより、着手のハードルも下がります。/review-pr-interactive 847と打つだけです。詳細なプロンプトをゼロから書くのとは大違いです。
What we added along the way
毎日使った後、私たちはスキルをチームのやり方に合わせて改良しました：
- 焦点を定義する — このタイプのPRで最も重要なことを最初に設定する
- Nitpickのラベリング — スタイル上の問題を指摘してもいいが、それを「Nitpick」と明確にマークする
- ボーイスカウトのコミット — PR内の別コミットとして、無関係なクリーンアップを許可します。別PRは不要なので、切り離しておくだけにしましょう
- 自動コメントしない — Claudeは何かを投稿する前に、私の明示的な承認を待つ
もう1つ整える必要があったのは、ClaudeがPRを承認するときの振る舞いです。最初の頃は、承認メッセージの一部として、PRが行ったことを全部まとめた長いエッセイを書いていました。とても変でした。PRの作成者は、自分が作ったものが何かを知っています。そこでスキル内で「単純なLGTMで十分」または「本当に目立ったことへの短いメモ」で良いと定義しました。
The thing that surprised me
私はこれが時間を節約すると期待していました。実際に節約できました。
予想外だったのは、これによってレビューで私がより当事者として関わることになり、むしろ関与が減るのではなかった、という点です。ワンショットの自動ツールでは、私は「指摘事項」の一覧を読んで次に進みます。しかしこのフローでは、私は実際にコードの中にいます。コードを読み、質問し、判断の決定をする。AIが土台（足場）を用意します。私が理解を持っていくのです。
それは、適切な分担のように感じます。
AIがあなたのコードベースのより多くを書いていく中で、あなたはコードレビューをどう扱っていますか？
