エージェントが生成するすべての変更をレビューすることは、不可能になりつつあります。
長時間動作するエージェントは、より大きく、より頻繁なプルリクエストを作ります。さらに、ツール、ワークフロー、人のいずれからでも、ほとんど労力をかけずにPRを開けるようになりました。これによりエンジニアリングチームが実行できることは大きく増えましたが、コード変更の管理には新しい課題も生まれています。
エージェント型SDLCでは、人間の注意力が希少なリソースになりました。それにもかかわらず、既存のワークフローはその注意力を低価値な作業に浪費しがちです。
開発者が意味のあるコードを書いたりレビューしたりする前に、三つの隠れた「注意力税」が高価値な仕事との間に立ちはだかります。
- トリアージ税: 何に最初に注意を向けるべきかを決めること。
- 理解税: 断片化されたファイルからコンテキストを再構築すること。
- 警戒税: マージ後もコードを安全に保つこと。
トリアージ税: 誰かが人間の注意に値するものを決めなければならない
かつてプルリクエストは、慎重な投資でした。チームは作業をスコープし、計画し、それから誰かが数時間から数日をかけて変更をコードにしていました。そのため、PRは比較的まれなものでした。現在では、AIが書いたPRの約3件に2件はマージされません。クローズされるまでキューに残り、スペースと注意力を奪い続けます。
多くのプルリクエストキューは、到着順、リポジトリ、作成者、レビュー状態で並びます。これらの情報は管理には役立ちますが、どの変更を優先すべきかは示しません。
提案される変更が増えるにつれて、レビュアーは人間のルーターのように振る舞うようになりました。タイトルを読み、コンテキストをつなぎ合わせ、適切な担当者を探し、何が緊急かを判断し、その変更がそもそもレビュー可能かどうかを見極めます。これはしばしば混乱を生みます。重要な作業が価値の低い変更の後ろで止まり、レビュアーは本来見る必要のないものに時間を使い、チームはコードレビューを始める前にキューの整理で時間を失います。
顧客をブロックしている小さな修正は、長くレビュー待ちになっている大きなリファクタリングより先に注意を向ける価値があるかもしれません。セキュリティ修正はすぐに出荷しなければなりませんが、同時に慎重な検証も必要です。作業量と重要度は別々の軸であり、PRキューへの到着順はどちらも表していません。
病院で外科医に待合室のトリアージを任せることはありません。しかし、私たちはまさにそれをシニアエンジニアに求めています。何が注意に値するかを決めるために認知帯域を使い切らせ、その後でようやく本当に重要な仕事に取りかからせているのです。
影響に応じたレビューの振り分けは、エンジニアリングシステムそのものの一部になりつつあります。チームには、人間が差分を読み始める前に、価値、緊急度、リスク、依存関係、準備状況、レビュアー適性を区別できるキューが必要です。
理解税: 開発者は断片化されたファイルからコンテキストを再構築しなければならない
PRが詳しく見る価値を得たとしても、レビュアーはまだそれを理解しなければなりません。そして多くのレビュー画面は、その理解を必要以上に難しくしています。最初に表示されるのはファイル、行、コメントであり、レビュアーはファイルツリーから変更の認知地図を組み立てることになります。
リポジトリは実装を中心に整理されていますが、レビュアーはユーザーフローで考えます。一つのユーザーフローは、ルート、プロバイダー、設定ファイル、テンプレート、テストにまたがることがありますが、ファイルツリーはそれらを一緒に並べてくれません。すべてのレビュアーが、そのPRの理解をゼロから作り直さなければなりません。PRの複雑さによっては、コードをレビューできるほど理解するまでに30分以上を失うこともあります。
従来のコードレビューは、レビュアーがその認知地図を簡単に作れることを前提にしています。しかし、エージェントがサービス、データモデル、インフラをまたいで大きな変更を行うと、その前提は崩れます。コードは行単位では正しくても、変更全体としては理解しにくいままかもしれません。
たとえば、差分はある関数が変更されたことを示します。しかし、その変更が認可境界を越えるのか、マイグレーションを開始するのか、外部連携を壊すのかまでは説明してくれません。
その説明がなければ、レビューは推測になります。組織はより速く出荷しながら、システムに対する共有理解を少しずつ失っていきます。
レビュアーに必要なのは、その変更が何を意味するかのtl;drです。有限の注意力を持つレビュアーを前提にしたUIが必要です。変更が触れる契約、ドメインの振る舞い、連携、テスト、マイグレーションを明確に示し、その変更がどこまで届き、どこに深い確認が必要かを正直に説明するUIです。
理想的には、レビュアーは一、二分で、その変更が何をしようとしているのか、なぜそれらのファイルが一緒に変わったのかを理解できるべきです。
本番環境のオブザーバビリティは、システムがどのように動いているかをチームに見せます。AI生成の変更がより大きく、より一般的になるにつれて、チームにはコードの説明可能性も必要になります。つまり、意思決定や振る舞いがシステムの一部になる前に理解する方法です。
警戒税: 注意はマージ後も続かなければならない
変更は出荷された後も意味を持ち続けます。各PRは単独では正しく見えても、時間とともにコードベースのエントロピーを高め、安全性を下げる可能性があります。
依存関係は変わり、新しい脆弱性が現れ、データフローは移り、サービスは新しい形で接続されます。マージ時点では安全だったアーキテクチャ上の選択が、数か月後にも安全であるとは限りません。
チームはこのことを理解し、不安を抱き始めています。同時に、開発者の生産性を高めている同じAIが、攻撃者にとって脆弱性を見つけて悪用しやすくしていることも理解しています。従来のルールベースのセキュリティツールだけでは、新しい攻撃ベクトルからコードベースを守るには不十分です。
チームは、マージ前と同じ厳しさをマージ後の変更にも適用し始めています。レビューシステムは承認で終わることはできません。何が変わったのか、その変更がどんな前提を導入したのか、そしてその前提をいつ見直す必要があるのかを理解できるようにしなければなりません。
重要なことに集中する
ソフトウェア開発の次の時代は、組織がどれだけ多くのコードを生み出せるかだけで決まりません。どれだけ多くの変更を責任を持って扱えるかで決まります。
誰も読み切れず説明しきれない速度でコードが出荷されるなか、チームは自分たちの仕事を意図的に形作る力を失いつつあります。何に注意を向けるべきか、何が検証済みか、そして一つひとつは妥当に見える変更によってコードベースが安全でなくなっていないかを判断することは、すべての開発者が毎日成果で支払っている税です。
もし開発者がその税を払わなくてよくなったら、何が残るでしょうか。人間にしかできないこと、つまり判断を使って、より良く、より安全なコードベースを作ることだけが残ります。
まもなく、そうなるでしょう。変更を管理するより良い方法が来ています。
