私たちが知るプルリクエストは約20年前のもので、多くの現役エンジニアのキャリアよりも若い。コードレビューも永続的なもののように感じられるが、そうではない。Googleは2006年頃から社内でコードレビューを開始した。初期のWindowsソフトウェアの多くは、現代的なレビューに相当するものなしに出荷されていた。
コードレビューは現在、ソフトウェアエンジニアリング業務の形態に合わなくなった承認ゲートとなっている。そして、私たちが再びそれを変えようとしている今、私たちがそもそもこのプラクティスを発明したことを思い出すのは役に立つ。コードレビューは特定の課題を解決した。統合前の欠陥検出、ジュニアエンジニアへの教育、そして単一の人物がすべてのコンテキストを持たないようにするための知識共有だ。やがてそれはコンプライアンスやゲートキーピングとなり、多くの組織では演劇と化した。
“コードレビューはマージの時点で止まっていた。AIはそれを上流へ移す強制力となる。”
今やコードの量がこのプラクティスを破壊している。直面するジレンマは、コードを一切読まないことと、人間がAI生成コードを1行ずつレビューしてスロップを防ぐことの間にあるのではない。コードレビューが本来何のためにあったのか、そして機械がほとんどのコードを書く世界でその機能を再構築することにある。
レビューはマージの時点で止まっていた
誰かにコードレビューがどこで行われるかを尋ねれば、答えは自動的に返ってくる。マージ直前だ。前でも後でもない。パイプライン上の1点であり、それが唯一のポイントとなっていた。
Thoughtworksでは、トランクベース開発、テスト駆動開発、ペアプログラミングが宗教のように実践されており、レビューは儀式ではない。メリットは継続的に、ペアリングセッションの中で得られるのであり、誰かがようやく500行の差分を開く何週間も後ではない。数週間ブランチに留まらず、テストが十分であれば、グリーンのパイプラインが最も必要とするものだ。
統合前がレビューの唯一の場所であるべきではないという考えは新しいものではない。欠けていたのは強制力だった。今、私たちは強力なエージェント型AIとエージェント型IDEがより多くのコードを生成するようになったことで、誰もが再びこのことを考え始めている。エージェントが1回の午後で1機能分のコードを生成できるとき、捕捉したいギャップは上流、つまり開発者がツールに意図を表現する瞬間に移る。差分が存在する時点では、数時間前に下された、数千トークン相当の判断の結果をレビューしていることになる。
“差分が存在する時点では、数時間前に下された判断の結果をレビューしている。”
AviatorにおけるIntent-driven developmentとは、意図が生まれた時点でそれを捕捉することを意味する。これはスコープの簡単な説明、明示的にスコープ外とするもの、または受け入れ基準のリストになり得る。私たちの経験では、意図はプロンプトから直接、またはエンジニアがエージェントと作業する中で下した判断から捕捉するのが最適だ。
今、私たちは何をレビューしているのか？
意図を表現すると成果物が生まれる。機能ごとに数十のMarkdownファイル、仕様書、明確化質問のログ、プロンプト会話に埋もれた決定木だ。ほとんどのチームはこれらをバージョン管理していない。そのため、何をコードレビューする価値があるのかという考え方が変わった。
3つの陣営が現れた。仕様書のみをレビューし、他は信頼するチーム。仕様書、コード、その間のすべてをレビューし、自分たちがボトルネックになっていることを十分承知しているチーム。何もレビューせず、実行中のシステムをテストするチーム。コード量が多すぎて他に選択肢がないからだ。
コードレビューの実施方法も、生成されるコード量の増加により変化している。5ファイルを超える差分は、意図した変更と実際の変更を結びつける人間の能力をすでに圧迫する。それが10倍になる。レビュアーは差分とチケット以上のものを求める。元の意図、エージェントがたどった経路、そしておそらくコードを見たいと思う。
実装ではなく意図を読む
レビュアーは数百行のコードを見てそれが正しそうかどうかを判断する必要はない。10行の意図と受け入れ基準を見て、「これは正しい問題を正しい制約で解決しているか？」と問うだけでよい。これはシニアエンジニアの時間のより良い使い方だ。
また、レビューの知識共有機能も維持される。プラットフォームに長年存在する日付処理ライブラリを知っているレビュアーは、その知識を組織のAI slop registerに体系化でき、それは美しくスケールする。過去1,000件のレビューコメントをマイニングし、クラスタリングし、人間による承認のための不変条件候補を生成する。体系化された不変条件1つは、二度と書く必要のないコードレビューコメントとなる。
集団的コード所有権、つまり1人の人物がすべてのコンテキストを持たないという考えは、コンテキストがLLMにとって有用になるために人々の頭から出なければならないため、ようやく実践されるようになった。
コードをレビューするエージェントはUIを必要としない
今日のAIコードレビューツールの多くはGitHubやGitLabの上に位置し、コメントを残す。エージェントはコメントを読み、反論し、変更をプッシュするか、自分を弁護する。それは以前と同じ演劇が両側で自動化されたものであり、もはやインターフェースを必要としない。
人間であれエージェントであれ、コードレビューははるかに早い段階で行われる必要があり、レビューである必要すらない。ラバーダッキングや教育の機会になり得る。できる限り左に引き寄せることで、下流でやるべき作業量を最小限に抑える。生成中に同行し、アンチパターンが形成される時点で捕捉する助言的または対立的なエージェントは、コミット後にコメントするエージェントよりもはるかに価値がある。
Thoughtworksでは、ジュニア開発者向けの教育エージェントとして始まったコードレビューエージェントを構築した。チームの既知のアーキタイプとコンベンションドキュメントを対象に、開発者が逸脱している点を説明するよう指示された。それはレビューエージェントへと進化した。
Aviator Verifyはサーバーを起動し、実際のトラフィックを送信し、UIインタラクションを駆動して、コードが意図したとおりに動作することを確認する。見た目が正しいだけでなく、意図どおりに動作することを確認する。目標はレビュアーに証拠を渡し、レビューを「証拠と意図が理にかなっているか」という質問に変えることであり、行ごとの差分読み取りではない。
コードレビューは一夜にして進化しない
これらのことは組織全体のメモで一夜にして起こるものではない。数十年来の信念を手放すようチームをコーチすることはできない。実践で示す必要がある。
あるThoughtworksのクライアントには、コンサルタントが作成したものはすべてレビューしなければならないという厳格なルールがあった。その後、仕様駆動開発のパイロットが大量のMarkdownと異常に大きな変更セットをもたらし、ルールは現実と衝突した。彼らは従来の方法ですべてをレビューすれば自分たちがボトルネックになるということに自ら気づいた。
“検証は機械へ。判断と知識は人間に残る。”
AI slop registerの構築には時間がかかり、最初の1ヶ月は二重の作業のように感じるだろう。コードレビューを行い、Invariantsを構築する。しかし、一度体系化されれば、slop registerは二度とレビュアーを必要とせず、同じミスが再発するのを防ぎ続ける。
検証は機械に、判断は人間に
形は変わるが、レビューの理由は変わらない。私たちは依然として欠陥を捕捉し、次のエンジニアを教え、決定を見えるようにする必要がある。変わるのはその作業が行われる場所だ。検証は機械に移り、機械の方が私たちよりも高速で一貫性がある。判断と知識は人間に残る。なぜならそれらは学習にとって重要なレビューの部分だからだ。
したがって、移行はレビューからノーレビューへの移行ではない。コードを読むことから意図を読むことへの移行だ。
Group Created with Sketch.
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.