巨大PRをStacked PRに分割したら、AIレビューが見逃していたバグを見つけてくれた

GitHubに追加されたStacked Pull Requestsを実際に使い、巨大なPRを分割してAIレビューにかけてみた。すると、分割前の巨大PRでは指摘されなかった不具合が、分割後の一つのPRで見つかったという。コード自体はほぼ同じで、違ったのはレビュー対象となる差分の大きさだけだった。

ここが面白いところだ。AIレビューは「PRが大きいと細部を見落とす」という点で、人間のレビューと同じ弱点を持っているらしい。人間が「PRは小さくしろ」と言われ続けてきた理由が、そのままAIにも当てはまるわけだ。AIに実装を任せれば任せるほど書かれるコードは増え、レビュー対象の差分は膨らむ。書く速度が上がったぶん、レビューする側の負担が増えるという、いびつな構造が見えてくる。本当に効いているのは、AIのレビュー精度よりも「レビューに渡す単位」を設計し直すことなのかもしれない。

もう一つ見逃せないのは、分割した後の運用の話だ。従来、小さいPRを順番に作ろうとすると、レビュー待ちで実装が止まりがちで、細かく分けることと開発速度がトレードオフになっていた。Stacked PRではそこが緩む。さらに、親PRをマージした後のrebaseや、後続PRのマージ先の付け替えをGitHubが引き受けてくれる。面倒な作業を人間が手でやらなくて済むなら、分割は現実的な選択肢になる。

中小企業の現場で言えば、システムや業務ツールの変更を一度に大きくまとめて出すのをやめ、「何のための変更か」が一目で分かる単位に切ってからAIにチェックさせる、という一言に落とせる。ただし、分割したPRが単体では正しくても、組み合わせると後続が壊れることもある。最後に全体をまとめて確認する工程は省かないこと。