どうもです、タドスケです。
最近、職場でも Claude Code を積極的に使うようになり、以前にも増して高速で実装が行えるようになりました。
その一方で悩んでいるのが、「AI の変更量が多すぎてレビューできない問題」です。
「AI の変更量が多すぎてレビューできない問題」とは？
これまでは「AIが一度に変更できるコード量 ＜ 人間がレビューできるコード量」でした。
（それ以上の変更を一度にやらせようとすると、AIの精度が落ちる）
しかし Claude Code を使ったプルリクのレビューをするようになってから、それがついに逆転したなぁという実感があります。
もちろん、AIを使う人間の方で制御できる話ではあるのですが、現場には常に「できるだけ早くリリースしたい」圧があり、それが「AIが書いた動くコードをきれいにする」ことを妨げています。
「変更量が多過ぎてレビューできないけど、時間がないから最低限の動作確認だけしてリリース」を数回繰り返した結果、コードベースは複雑化し、それにより Claude Code ですら正しく解析できない状況になってきました。
「リリース後に時間を取ってリファクタリングする」のがシンプルな解決策ではありますが、リファクタリング中に緊急の割り込みタスクが入ってくることもあり、常に実施できるものではありません。
そもそも「動くけど人間がレビュー不可能なプルリク」が作成されるのを防ぐルールや仕組みを作れないものでしょうか？
ここまで調べた限りで参考になった情報をまとめます。
TDD で監視しながら進める
こちらの記事では、TDD（テスト駆動開発） を使い、AIが作業しているのを監視しながら進めることが提案されています。
「AIに任せて他のことをする」とは逆の考えなので、一見非効率に思えますが、手戻りのコストを考えると結局はこの方法が良いのだそうです。
実際に僕もこれまでの開発で「AIに長時間やらせた後でどうにもならずに全部破棄」を繰り返してきたので、納得感があります。
TDD 自体は万人に受け入れられる手法ではないので、このまま現場に導入できるかはわかりませんが、「AIを監視しながら一緒に進める」アプローチは試してみたいと思いました。
コミットを細かく区切らせ、一つずつ見ていく
こちらのポッドキャスト内では、テスト駆動開発で有名な t_wada さんが、「プルリク作成までは一度にやってもらうけど、コミットは細かく区切ってもらって、一つずつ見ていく」というアプローチを紹介していました。
このやり方なら、「AI に大きなタスクを任せてある程度の並列性を保ちつつ、レビューはしやすい」という状況を作れるかもしれません。
「レビュー可能な単位のコミット」をどうやってAIに作らせるかが課題ではありますが、とりあえず「こまめにコミットして」のように指示して様子を見てみるのはありかもしれません。
測定可能な仕組みを作り、ブラックボックスを許容する
こちらの動画では、「測定可能な仕組みを作り、ブラックボックスを許容する」という主旨のことが語られていました。
プログラミングにおける「測定可能な仕組み」とは、テスト・パフォーマンス測定・静的解析ツールなどがこれにあたります。
例えば中身の実装を知らない関数があるとしても、「A を入れたら常に B が返ってくる」というのが分かっていれば、その関数を利用した機能を作ることはできます。
アプリ開発では多くのオープンソースライブラリを使いますが、中身のコードを全て読んで理解してから使っている人はほとんどいないと思います。（全部にそんなことしていたら時間がいくらあっても足りない）
これと同じようにAIが作るコードについても、テストで「A を与えたら B が常に返ってくる」ことを保証したうえで、中身はブラックボックスのライブラリのようなものとして扱えるようになると、「見ないといけない部分」が減り、コードの全体像を把握しやすくなります。
このあたりの話は、以下の記事の内容とも通じるかもしれません：
コメント