この記事は、コードレビュー（書いたものを誰かが読むこと）はエージェントに対してはスケールしないと論じる。誰にも読み切れないほどコードが多いからであり、そのため品質チェックのますます多くの部分が、エージェントを取り巻くハーネス、環境、オペレーティングシステムの側に置かれなければならない。中心となる主張は、ソフトウェアの品質はいまやエージェントの周囲に設ける制約にかかっているというものである。エージェントはどんな提案でもできるが、その提案が出荷に足るだけ安全で、正しく、範囲が適切で、有用かどうかを決めるのは制約である。著者自身はいまもコードを読んでレビューしているが、どこで制約にチェックを任せてよいと考えるかについては意図的に判断していると述べている。
記事はこうした制約を品質ゲートと呼び、バックプレッシャーとあわせて、エージェントが非常に多くの変更を生成する状況でもチームが本番ソフトウェアの信頼性を保つための仕組みとして扱う。記事の最後では、読者に品質のための制約駆動の計画を自分で書くよう呼びかけている。
要点
- 品質ゲートにはさまざまな形がある。ユニットテスト、プロパティテスト、受け入れテスト、ミューテーションテスト、循環的複雑度や行の長さといったコード品質の指標、そしてシステムがどの変更提案を受け入れて適用するかについてのチェックなどである。
- Guillermo Rauch による、コードを読まなくても許容されうる状況のリストを取り上げ、記事はそうしたケースがいずれも実際には「リスクが低い」（ユーザーがいない、使い捨てのコード、プロトタイプ）という主張であると指摘する。リスクが高まれば何かがコードを読まなければならず、それがすべての差分に対する人間でないなら、制約がその役を担わなければならない。
- 未解決の課題として 2 つが挙げられている。自律性（情報が欠けていたりタスクが曖昧だったりするとエージェントは失敗しうる。その理由の多くは人間が失敗する理由と同じで、脆い環境、非決定的なビルド、権限の不足、弱いテストなどである）と信頼であり、信頼は苦労して勝ち取らなければならないと著者は述べている。
- 記事が目指す環境は、エージェントが実際の仕事をこなし、信頼できるフィードバックを得て、失敗しても大きな損害を出さずに済む環境である。
- 制約が働くポイントはさまざまである。作業が始まる前にその形を決める制約もあれば、エージェントが作業している間にフィードバックを与える制約もあり、出力が本番の境界を越えてよいかどうかをそもそも判定する制約もある。
- 著者は、ユニットテストだけに頼るのではなく、型安全性やパフォーマンスから後段のセキュリティスキャンまで、それぞれが異なる責務を持つ、幅広くかつ意図的に選んだチェックの組み合わせを推奨している。アーキテクチャのルールは ESLint のようなリンティングツールで強制できる。
- 人間の注意は希少なものとして位置づけられている。それ以外は機械の速度で動くシステムに人間のチェックを差し込めば生産性が損なわれるため、人間は自動化されたガードレールが破綻したときに呼び込み、判断を要する微妙な問題に振り向けるべきだとされる。
- 品質は単一の指標ではなく、重要度の異なるシグナルの集まり、すなわち正確性、保守性、パフォーマンス、セキュリティ、効率性、理解しやすさとして説明されている。
- 検証が変更の量に追いつかない場合の対応として、記事は 3 つを挙げる。検証の仕組みをスケールさせる、エージェントが変更を生成する速度を落とす、品質の基準を下げる、である。また、ある箇所では制約を緩めつつ、最も重要な箇所では厳しく保つことも提案している。
- 著者は、現時点では、有用なエージェントの出力とスロップ（低品質な出力）との差の多くは、依然としてループを運用するチームの技量に帰着すると述べている。
背景
この議論は、計測された結果ではなく、著者自身の見解と経験として示されている。記事は、もともと著者の Substack で公開されたものであると記している。決定論的な品質ゲートとガードレールも参照。