いちばん印象に残ったのは、「レビューは人間が読むもの」という前提をかなり崩しているのに、雑になっていないことでした。普通ならコードレビューを自動化すると、最後は誰かが薄く眺めて終わりになりがちです。この記事のやり方は逆で、機械に読ませる場所を増やすほど、人間は「本当に危ないところ」だけを見るように寄せている。そこが気持ちいいです。
特におもしろかったのは、レビューを“最後の関門”ではなく、書いている途中からずっと走る仕組みに変えている点です。テストを通す、build を見る、別 context の agent に diff を見せる。そうやって PR の前からかなりのミスを潰しておく。これ、言われてみれば自然なんですが、実際に運用まで持っていくのはかなり難しいはずです。人間のレビューを減らすには、単に速くするだけでは足りなくて、戻しや incidents が増えないことをちゃんと見ないといけない。その視点が一貫していました。
もう一つ、地味だけど大事だと思ったのは、「human review を減らした」ではなく「human time and attention を守る」と言っているところです。ここにはかなり実務っぽい感覚があります。レビューにかかる時間を削っても、後で壊れたものを直す時間が増えたら意味がない。だから revert や incident をガードレールに置いている。派手な AI 活用の話に見えて、実は運用の話なんですよね。
一方で、少し引っかかったのは、ここまで機械に寄せるには、レビュー基準やリポジトリごとのルールがかなり整っていないと回らなさそうなことです。CLAUDE.md や REVIEW.md のように、「何を大事にするか」を文章で固定しておくのは理にかなっていますが、裏返すと、その文書が古くなったり曖昧だったりすると、機械の判断もそれに引きずられるはずです。レビューの自動化って、コードを書く力よりも、ルールを書く力と保守する力が問われるのかもしれないと思いました。
