「人間のスロップ」を掃除する時が来た

AIモデルがコード作成の核心プロセスを担うようになるにつれ、現在作成されているコードベースをAI自体でどのように効果的にレビューするかという議論が活発化しています。もし人間によるチェックポイントを上流に移すべきだというコンセンサスがあるなら、人間の開発者は実際にどこで働くべきなのかという疑問が浮上します。

これは、義務的なピアレビューが単なるゴム印と化しているチームで顕在化する痛点です。プルリクエストがピアレビューチャンネルに数日間放置され、コンテキストをほとんど持たない別の開発者がようやく対応可能になり、「賭けよう、マージしよう」と言うだけのケースです。

「私たちは『人間のスロップ』を掃除する時が来たことを認識すべきです。つまり、人間がAIよりもはるかに頻繁に犯す種類のエラーです。こうした間違いに対しては、疲れた人間よりもAIレビュアーの方がはるかに信頼できます。」と、クラウドネイティブ可観測性プラットフォーム企業groundcoverのソフトウェアエンジニア、Avital Tamir氏は述べています。

多くの開発現場ではこのシナリオがまだ続いています。おそらく、メリットがデメリットを上回るという無限の楽観主義があるからであり、またそれがソフトウェアチームに標準化と秩序の感覚をもたらすからかもしれません。

Tamir氏はここしばらくこの問題を考えてきました。彼はコードレビューのプロセス全体を変えるよう求めていますが、完全にカウボーイコーディングのカオスに陥ることを提案しているのではなく、過去20年間行われてきたコードレビューの方法を時代に合わせて変える必要があると主張しています。

「AIスロップ（幻覚、誤解されたコンテキスト、自信満々の誤りなど）については多くの議論がありますが、それらは現実の懸念です。しかし同時に、『人間のスロップ』を掃除する時が来たことも認識すべきです。この種の間違いについては、AIレビュアーは疲れた人間よりもはるかに信頼できます。」とTamir氏は言います。

Tamir氏が説明する人間のスロップの実例は、多くの開発者にとって馴染み深いかもしれません。機能が完了すると、プログラマーはプルリクエストを開きます。そしてしばらく放置されます。開発者は同僚をSlackでpingします。初日は何も起こりませんが、48時間後に誰かが変数名の些細な指摘や、コード内で既に回答されている質問をコメントします。開発者はこれらの厄介な要素を修正します。なぜなら、議論するよりもコード構造の重要でない要素を修正する方が時間がかからないからです。その後、ようやく「LGTM」が届きます。

「それで何が達成されたのでしょうか？」とTamir氏は問います。「火曜日に出荷できた機能が金曜日にずれ込みます。競合は火曜日に出荷し、水曜日に本当のバグを発見し、木曜日に修正します。一方、あなたはレビューのリンボで2日間を費やし、反復速度ではなく免責可能性を最適化しています。」

彼は、そのレビュー時間が実際に何を捕捉しているのかを考えるよう促します。「本当に痛いバグ、例えば競合状態、データのエッジケース、負荷下の障害モードは、システムコンテキストなしで孤立してコードを読む人によってめったに発見されません。届くフィードバックはスタイルに関するもの、例えば『早期リターンを使う』『関数を抽出する』など、良い静的解析が自動的に捕捉すべきものです。」

このプロセスを数十人のエンジニア、週複数のプルリクエスト、複数レビュアーポリシーで乗算すると、複合コストは相当なものになり、最終的には出荷機能や学習サイクルの損失として現れると主張するのは不合理ではありません。

「自己レビューは無レビューではありません。それはレビュー責任を最もコンテキストを持つソフトウェアエンジニア（通常は元の作成者）の手に直接委ねるように設計されたプロセスです。AIを活用したレビュープロセスを使用します。」

Tamir氏が提案する自己レビューフローは以下の通りです。

AIと緊密に協力し、すべての編集を読み、必要に応じて方向付け、何が変わったのか、なぜかを理解する。

完全なテストスイートを実行し、「カバレッジ」が意味があることを確認する。

動作をエンドツーエンドで手動検証してからプルリクエストを開く。

プルリクエストを開き、AIレビューツールを実行する。そのコメントをコーディングAIにループバックし、対応するか却下するかを決定し、反復する。

マージし、監視する。エラーレートとメトリクスをチェックする。結果に責任を持つ。

「そのプロセスは48時間LGTMを待つよりも厳格です。さらに、問題を理解している人物に説明責任を正確に置きます。不快な真実は、多くのコードレビューは単なるお芝居であり、厳格さの外見を作り出しているが、それを確実に提供していないということです。」

こうしたAIコードレビューツールの存在と提案を考慮すると、最終的にはソフトウェアエンジニアリングチームの構造とそれを監督する管理アプローチの本質に疑問が投げかけられるかもしれません。

これにより信頼が問題になります。Tamir氏は、経営陣がソフトウェアエンジニアに自分の仕事を責任を持ってレビューすることを信頼しないなら、「それはプロセスの問題ではなく、採用の問題です」と示唆します。

「高パフォーマンスのチームにおける信頼は成果を通じて構築されます。つまり、機能を出荷し、障害を所有して迅速に修正し、積極的に知識を共有し、意思決定に同僚を含めることです。これらの行動は、ピアレビューの承認キューが提供しないトラックレコードを作り出します。」と彼は結論付けます。

これらのテクニックの一部または全てを取り入れようとするチームは、まず低リスクの内部ツールや、おそらくグリーンフィールドサービス、または顧客向けでないシステムから始めると良いでしょう。このアプローチと並行して（チームが成功、デプロイ頻度、ロールバック率などを測定しながら）、同期型の人間コラボレーションはより重要度の高い決定のために留保することができます。

こうして、チームコラボレーションが真に重要になり、違いを生み出し、LGTMから「本当に私にとって良い」へと移行できるかもしれません。