こんにちは！スタッフエンジニアの @kenkoooo です。
ここ1年で、開発の現場でAIを使う機会が一気に増えました。新規実装からテストコード、既存コードのリファクタまで、AIがコードを書いてくれる範囲は広く、チーム全体のスピード感も変わりつつあります。
一方で、よく聞く話として「AIが大量のプルリクを出してくるのでレビューが大変」というものがあります。しかし、レビューがつらくなる原因は量そのものではなく、レビューしやすい前提が揃っていないためであると考えています。
この記事では、AIが出してきたプルリクをレビューしづらい原因を考え、それらに対してどのように対処しているかを紹介します。
意図がわからない
「何が問題で、何が原因で、どのように変更したことで問題を解決したのか」という意図が分からない場合があります。変更内容からそれらを推測できる場合もありますが、容易には推測できない場合もあります。
プルリクの説明文に意図が書かれておらず、変更内容から自明でもない場合は、レビューの前にプルリクの description に変更の意図を説明させたり、変更箇所のコメント内で意図を説明するように指示しています。
ちょうどいい大きさの塊になっていない
レビューの大変さは単に変更量によって決まるわけではありません。500行の変更でも簡単に理解できる場合もありますし、40行の変更でもレビューが終わらない場合もあります。
以下の点に注目して、プルリクがちょうどいい大きさの塊になっているかを考えています。
- 複数のテーマに跨る変更が1つのプルリクに詰め込まれていないか
- プルリク内で理解が完結しない境界で分割されてしまっていないか
個人的な肌感では、AIが出してくるプルリクが中途半端に分割されることは少なく、大きすぎることの方が多い印象です。ちょっとレビューして大変さを感じたらすぐに分割するよう指示をしています。
既存の流儀に則らず、複雑さが増えている
AIはリポジトリ内のコードを全て読んでいるわけではないので、既存の関数を使わずに再実装してしまうことがあります。また、社内ライブラリの情報などを適切に渡せていない場合も同様のことが起こります。コードの再実装の他にも、タスクの情報が上手く渡せていなかった場合など、不必要に複雑な実装になってしまうケースがあります。例えば、「とりあえず LightGBM で動けば OK」くらいの温度感で依頼したつもりなのに、XGBoost と CatBoost のモデルも作ってスタッキングしてくれたりします。
このような場合、AIが出してきた複雑な実装を理解しようとする前に、改めて指示を出し直しています。人間がやってくれたものを「こんなに複雑なことをしなくてもいい気がするなぁ…」で作り直させるのは気が引けますが、AI相手だと気楽に作り直しをお願いできるので良いですね。
まとめ
AIが出す差分が大きいほど、レビューが大変に感じることがあります。ただ多くの場合、つらさの正体は「量」ではなく、レビューに必要な前提が欠けていることだと考えています。AIは作り直しが速いので、気軽に作り直しを依頼できます。頑張ってレビューする前に、レビューできるプルリクになっているかという視点で考えてみるとラクになることもあります。
estie では AI を開発で使い倒しています。「俺の方が活用しているぞ」という方、ぜひ対戦よろしくおねがいします。
