コードレビューをやめる時が来た

この見出しを読んで緊張した人もいるでしょう。私もつい最近まで同じ立場でした。今年の初め、私は当時——今もかもしれない——世界最高のAI支援コードレビューツールを1ヶ月かけて作っていました。しかし今、私は古典的な意味でのコードレビューをまったく行っていません。

人間主導のソフトウェア開発において、コードレビューには主に3つの目的がありました。1つ目は知識の伝達です。特定のコードを安全に変更できるエンジニアが1人だけ、という状態はよくありません。レビューは、チームの別の誰かがそのコードと背景を理解する良い手段でした。2つ目はトレーニング。シニアがジュニアのコードをレビューすることで、次の改善につながります。3つ目は欠陥検出と技術的負債の回避です。

著者は最初の2つはもはやレビューに頼る必要はないと言います。AI支援があれば、任意のコードの内容を非常に速く把握でき、「マージ前に各PRを何時間も読む」というトレードオフは成立しません。必要な時に必要な文脈を好きなツールで引き出せばいいのです。また、モデルは今のところセッションをまたいで学習しませんが、各研究所がこの問題に取り組んでおり、おそらく数年以内に実現するでしょう。そしてAIが書いたコードについてジュニアにフィードバックするために時間を割く価値は、十分にありません。

技術的負債もほぼ問題ではなくなりました。方向を間違えたなら、コードを正しい方向に変更すればいいのです。これはより高いレベルでのYAGNIです。将来のコストが今と同じかそれ以下なら、今高価なことをする必要はありません。実際、Fable 5、やや程度は落ちますがSol 5.6やK3といった新モデルは、前世代のモデルが生んだ技術的負債をきれいにできるほどコード改善が得意です。それでも間違いはありますが、新しいリリースのたびに減っています。

残るのは欠陥検出です。第一に、コードレビューはもともと欠陥を見つけるのが得意ではありませんでした。最も良い研究でも検出率は約35%、セキュリティのような専門領域ではさらに低いことがよくあります。エンジニアなら自動化を考えます。ソフトウェアQAには膨大な実証研究があり、分散システムのような難しいコードを堅牢にする手法も数十年前からありますが、従来はプロジェクトの構造や計装を大きく変える必要があり非現実的でした。オンデマンドの知能を使えば、その問題は消えます。にもかかわらず、ほとんど誰もこれらの手法を取り入れ始めていないのは私には不思議です。

静的解析も同様です。Coverityは2002年からありますが、より野心的なチェックは実コードベースではノイズが多く、RuffやClippyのような単純なツールが好まれてきました。ところが今は、AIがノイズをかき分けて、関連するものだけを判断できます。安易に「警告を全部直せばいい」とやるとコードが悪化することもあるので、判断は依然として必要です。私はBifrost用に2つのカスタム解析パイプラインを書き、GPTに「無視・自動修正・人間にエスカレーション」を分類させています。

では「レビュー」予算の正しい使い方は何でしょうか。人間がアーキテクチャ、不変条件、意図を理解する必要は今も変わりません。しかし、diffを手で読むことは、その理解を得る・維持する最善の方法ではなくなった、というのが著者の主張です。/plan を使うことを勧めています。FableやSolは戦術レベルでは旧モデルほど /plan を必要としませんが、指示の曖昧さを表面化して解決するには /plan が最適です。機械的に単純な変更以外は省略すべきではありません。永続化データ形式、公開API、プロトコルなど、変更が難しい外部コミットメントの確認にも最適です。

今朝の例を紹介します。著者は「ハーネス・オブ・ハーネス」であるHelを構築していました。セッションが数十万イベントまで成長すると、worker-controllerプロトコルが肥大化し、再接続に数分かかることに気づきました。これは昔のレビューなら100%気づいた類の問題です。しかし全コミットにそのレベルのレビューをしていたら、4日で1.0にほぼ到達するどころか、スタートラインにも立てません。問題を発見したので、彼は /plan で「ダッシュボードの目標を踏まえて、ワーカーからどのイベントが必要か、どう表現すべきか」を尋ねました。モデルは妥当な設計を返しましたが、いくつかズレがあったため、次に「デタッチ中に未読を表示したい」という機能と設計を対応付けるよう求め、さらにドリフトを洗い出しました。

2024年頃までは、コードレビューは知識を広め、チームを指導し、技術的負債を防ぎ、バグを早期に直す貴重なツールでした。しかし変更が容易になり、やり方も変わった今、手作業による定型的なdiffレビューはシニアエンジニアの時間の無駄です。今私がICとして仕事を探すなら、このようなmake-workを続けている組織は、不必要な会議と同じくらい不快なので避けるでしょう。ほとんどのテック企業で人的エンジニアリング時間は最も高価な資源です。それをdiffレビューに使うのではなく、人間の目よりも優れた回帰バグを捉える新しいシステムの構築に使いましょう。