人類の歴史の大部分において、コード品質はコードレビューによって評価されてきた。誰かがあなたの書いたコードを読み、それがクリーンで、思慮深く、高速で、理解しやすく、テストも十分に行われていることを確認する。しかしエージェントにとって、このアプローチはスケールしない。誰かが読むにはコードが多すぎるのだ。その結果、品質チェックのますます多くが、エージェントの周囲にあるハーネス、環境、オペレーティングシステム上で行われなければならなくなっている。私は今でもコードを読み、レビューしているが、制約をチェックとして使うことにどこで安心できるかについては、非常に意図的に判断している。
ソフトウェア品質は今や、エージェントの周りに設定する制約にかかっている。
ギジェルモのリストは、レビューを省略しても問題ないかどうかを判断する良い試金石になる。すべての「はい」が、実際にはリスクがいかに低いかを示していることに注目してほしい。ユーザーがいない、使い捨てのコード、プロトタイプ。リスクが高くなれば、誰かがコードを読まなければならない。毎回の差分をあなたが読まないのであれば、制約が読むしかない。
制約は、エージェントの提案に対してテストや決定的な制約を突きつけることで、システムが何を許可されるかを定義する。こうした制約を設定し維持することによって、エージェントが毎日数十万、あるいは数百万もの変更を生み出す場合でも、高品質な本番ソフトウェアを確実に届けるループを構築できるのだ。
私たちはこうした制約を品質ゲートと呼び、それにはさまざまな形態がある。
具体的には、従来のユニットテスト、プロパティテスト、受け入れテストなどがある。また、コードの変異体を生成し、同じテストで実行して、見逃しているバグが紛れ込んでいないことを確認するミューテーションテストも含まれる。さらに、循環的複雑度や行の長さといったコード品質に関するメトリクスもあり、コードの可読性を保つのに役立つ。
コードを読むべきかどうかについては意見が分かれても、メカニズムについては一致することができる。ギジェルモはコードを読む。ボブは一切読まない。両者が語っているのは試練の道であり、違いはその中に人間がいるかどうかだけだ（私はボブの他の見解を支持するものではない）。
制約は、システムがどの提案をコード変更として受け入れ、適用するかという点でも重要な役割を果たす。変更提案が、エージェントを実行するインタープリターからエージェントコントローラーへ、そして本番環境へと移動する頃には、私たちは十分なチェックを実施しており、安全にリリースできること、そしてその変更の影響がエージェントのスコープ内に十分収まっていることを確信できる。
エージェントは何でも提案できる。あなたの制約が、その提案があなたとチームにとって十分に安全で、正確で、スコープが適切で、有用であるかどうかを決定する。
このモデルは多くのものを提供するが、一方で多くの要素が欠けている。そして、そうした欠落は今日考えてみる価値がある。ひとつの問題は自律性だ。エージェントは意図をうまく実行できるかもしれないが、情報が不足していたり、実行しようとしていることが曖昧だったりすると、失敗する可能性がある。これはタスク自体にも、ハーネスや環境、その他のコンポーネントによってタスクがどのようにパラメータ化されるかにも当てはまる。
人間が優れたコードをリリースできない理由の多くは、エージェントにも当てはまる。スクリプト駆動のストレスに耐えられない脆い環境、非決定的なビルド、権限の不足、弱いテストなどだ。このことは、より良い環境の構築を後押しする。その環境とは、エージェントに信頼できるフィードバックを与え、損害の少ない失敗モードを可能にし、成功を段階的に積み上げやすくするものだ。
私たちが目指す環境とは、エージェントが実際の作業を行い、信頼できるフィードバックを得て、大きな損害を与えずに失敗できる環境だ。
もうひとつの重要な問題は信頼だ。現代のエージェントのように賢く堅牢なものであっても、その正確性をチェックせずに、意図を盲目的に委ねるわけにはいかない。私たちは信頼から始めるが、その信頼は努力して勝ち取られなければならない。
ある制約は、作業が始まる前にその形を決める。別の制約はエージェントが作業している間にフィードバックを与える。さらに別の制約は、その出力が本番環境の境界を越えられるかどうかを決定する。
システムの周りに検証構造を置く方法には、さまざまなモデルがある。
私の経験では、ユニットテストだけに頼るのではなく、意図的に選択された、より幅広いチェックセットを制約として持つのが有用だ。各チェックには明確な責任があり、それは型安全性やパフォーマンスから、後期段階のセキュリティスキャンまで及ぶ。ESLint のようなリンターツールが強制できるアーキテクチャルールなど、独自の制約を定義することもできる。これらのツールの多くには組み込みのフックがあり、問題が発生したときにエージェントや人間を呼び込むために使用できる。
今のところ、役立つエージェント出力と粗悪な出力の違いの大部分は、ループを運用するチームのスキルに帰着する。
AI は大量のコード生成と高速性をもたらすが、それは同時に、人間がすべての変更をレビューすることが難しくなることも意味する。代わりに、人間の注意がどこに向くかを意図的に設計する必要がある。それ以外はマシンスピードで動くシステムに人間によるチェックを入れると、生産性に影響が出ても驚かないでほしい。人間の注意は希少で価値があるため、私たちの判断を必要とする最もニュアンスのある問題に積極的に向けるべきだ。後段の人間は、制約に関する自動化されたガードレールが破られたときにのみ呼び込まれるべきだ。
未来の人間による「コードレビュー」は、これまでとは大きく異なるものになるだろう。
正確性は重要な側面のひとつだが、保守性、パフォーマンス、セキュリティ、効率性、理解しやすさなど、他の側面も気にかけるかもしれない。正確性が多くのシグナルタイプに分解されるように、品質の他の側面も同様だ。そして、どれだけ多くの制約を設けているかも重要だが、それ以上に重要なのは、それらの制約が品質と本番準備の基準を満たすのに十分に挑戦的なものであるかどうかだ。
ソフトウェア品質は単一のメトリクスではない。それは、あなたとあなたのチームにとって重要度の異なるシグナルの集合体として考えるべきだ。
バックプレッシャーは多くのツールを通じて実装できる。コンパイラが無効なコードを拒否する、テストが失敗する、セキュリティポリシーが悪いプラクティスをブロックする、CI がデプロイを拒否する、といった形だ。理想的には、それはすべての作業の最後にある単一のレビューとしてではなく、ループ全体に存在すべきだ。
デックス・ホーシーによる同じループの図（『Why Software Factories Fail』より）。緑色のボックスは、人間によるレビューはループに置き換えられるのではなく、ループの中に戻されるべきだという彼の主張を示している。
制約とバックプレッシャーによって、エージェントは問題になる前に悪い成果を検出できる。
変更量がツールの処理能力を超えていて制約を適用できない場合はどうなるのか。結局、キューを構築し、人間の速度で動く検証システムに頼ることになる。スケールさせるには、検証を最後まで待つのではなく、できるだけ多くを検証ループに押し込みたい。自動化されたチェック内でスケールできれば、デリバリーシステム全体の速度とスループットを向上させることができる。検証ループの余地が尽きた場合、いくつかの選択肢がある。
まず、検証システムをスケールさせ、入ってくる変更を制約し押し返すための容量を増やすことができる。次に、エージェントが新しい変更を生成する速度を落とし、検証が作業量に追いつけるようにすることができる。第三に、品質バーを下げて、検証が通常ほど強く抵抗しないようにすることもできる。スケーリングの観点からは、これらすべてを行う準備が必要だ。同時に、一部の方向で制約を緩めることで、実際にはより多くのことを達成できるかもしれないという認識を持ち続けるべきだ。エージェント開発者の群れや自動化されたソフトウェアファクトリーを用意し、それぞれのレビューを待たずに変更を生成させることで、エージェント生成の変更速度を上げられるかもしれない。
また、ある部分ではより厳しい制約を維持する限り、別の部分ではエージェントにより多くの自由を与えたい場合もある。最も重視する部分に厳しい制約を設けることで、品質を犠牲にすることなくスループットを最大化できる。こうした決定には多くの選択肢がある。最も明白なのは、品質のさまざまな側面の間でトレードオフを行わなければならないことだ。強調してきたように、セキュリティは非常に重要だが、セキュリティを提供することと製品を期日通りに提供することの間でもトレードオフを行わなければならない。一方の端にイノベーション重視、もう一方の端に品質重視というスペクトルがある。そのどこかに、私たちがいたい位置を選ばなければならない。
私たちは、環境とシステムからの明確なフィードバックをエージェントやチームに送り返し、人々がセンス、意図、アーキテクチャといったより主観的な関心事に集中できるようにしたい。人間が制約の安全な範囲内に留まるのを助けることができれば、どこで問題が発生したかを必死に解明する必要を避けられる。
ソフトウェア品質は正確性だけにとどまらない。ソフトウェア品質とは、保守性、優れたパフォーマンス、セキュリティ、効率性、そして理解しやすさも意味する。これらの基準を満たし、本番環境の流れを維持するのに役立つすべての制約は、デリバリーパイプラインにバックプレッシャーを生み出す。
私たちは、どこに強い制約を適用し、どこで制約を削除または緩和するかについて、意図的な決定を行う必要がある。これらの目標の両方に役立つ場所には強い制約を適用しよう。一方または両方に役立っていない場合は、それらを維持すべきではない。必要に応じて基準を引き上げたり引き下げたりする準備をしよう。そして、ソフトウェアシステムのさまざまなポイントにあるこうした制約こそが、ソフトウェア品質を強制可能にしていることを忘れないでほしい。
強い制約は、その二重の目的に最もよく役立つ場所に適用し、どちらの目的にもうまく役立っていない制約は削除または緩和を検討すべきだ。また、必要に応じて品質バーを上下に調整する準備も必要だ。実際、ソフトウェアシステムのさまざまなポイントにあるこうした制約こそが、品質に実効性を与えている。多くの場合、新しいツールを導入したり、既存のツールを強化したりすることで、より多くのバックプレッシャーと制約を生み出すことができる。これらはすべて、ほとんどの変更要求に抵抗するために使用できる。これらをパイプライン全体にわたって構築したい。
私たちは、パイプラインの最後になって、問題を修正しない限りデプロイできないと CI システムに告げられるのを待ちたくない。これらのシグナルを、可能な限り早く、あらゆる経路を通じて使いたいのだ。このシステムにおける究極の制約は、システムを構築し運用するために取った決定と行動に責任を持つという、私たち自身に課すものだ。しかし他のすべての制約と同様に、私たち自身の判断がどれだけ抑制し、バックプレッシャーをかけ、最終チェックとして機能するかについて、思慮深いトレードオフを行う必要がある。
品質は、エージェントの周りに置く制約の中にある。あなた自身のアプリの品質を考えているなら、この問題提起を受け止め、独自の制約駆動型プランを考案してほしい。
品質といえば、エージェントがあなたのコードを書いている。Sonarは、それをリリース可能にする品質ゲートを提供する。 すべてのコミットに対して同じ完全なチェックを実行する。詳細なファイル横断分析、リスクの所在を示すマップ、そしてすべての人間とエージェントをひとつの基準に引き上げる品質ゲートだ。
この記事は、100% 人間が書いたと Pangram 4 によって評価されました。
