ソフトウェアの実務者が、コーディングエージェントによる出力の高速化は必ずソフトウェアの品質低下につながるという想定に異議を唱えた。人間が書くコードにも用いている品質管理を強化すれば、チームはリスクを抑えられると論じる。9月20日に公表した論考では、仕様、テスト、焦点を絞ったレビュー、手作業での確認、本番環境の監視を組み合わせた多層的な作業手順を説明している。

中心的な主張は、正式なベンチマークではなく著者の経験に基づく。実装前にAIシステムへ要件と技術設計のレビューを依頼すると、想定漏れや予期しない相互作用を発見する助けになったという。この手順により、一部のチームメンバーが新たに書く機能の不具合が減ったと報告している。ただし、システムが存在しない懸念を作り出すこともあり、どの提案が妥当かを人間が判断する必要があった。

次の層を形成するのがテストだ。推奨する順序は、要件からシナリオを導き、それに沿って実装し、残る網羅性の不足を埋めるというものだ。この切り分けは重要である。コードを生成した後でだけテストを書くよう求められたエージェントは、自らの誤った動作をそのまま期待結果として組み込むかもしれないからだ。著者は、コーディングツールにより幅広い単体テストの網羅が容易になると論じるが、自動測定されたカバレッジを機能が正しく動く証拠とは扱っていない。

手作業によるテストは依然として制約になる。人はなお機能を実際に使い、例外的なケースを探索し、意図した体験に合っているかを判断しなければならない。論考によると、この作業の生産性向上はコード生成ほど大きくなく、著者が述べる全体の生産量の増加は、10倍といった規模ではなく、およそ2～3倍にとどまった。これらは個人的な観察であり、独立して検証された性能結果ではない。

複雑な変更については、著者は引き続き人間のレビューを重視している。理由として、アーキテクチャー上の相互作用の見落とし、不必要に複雑な実装、不適切な言葉の選択を挙げる。追加の自動確認では、命名、ファイルの配置、書式、論理、セキュリティーを異なる角度から調べられる。著者の現在のチームでは、異なる問題を見つける傾向があるため、別々のAIレビューツールを二つ使う。ただし、それらのコメント自体も選別し、役に立たない指摘や過度に細かい指摘を取り除いている。

既存の利用者の操作フローを壊す変更を見つけられることから、エンドツーエンドテストも別の防御策として示されている。論考は、可能ならマージ前、ステージング環境、デプロイ後に実施するよう勧める。同時に、こうしたテスト群は完全ではなく、探索的テストの代わりにはならないと警告する。コードを本番で動かした後は、ログ、エラー率、遅延のダッシュボード、利用者セッションの記録、エラー追跡サービスから、リリース前の確認では捉えられなかった証拠が得られる。

より広い教訓は手順に関するものだ。コーディングエージェントはチームが生み出せる量を増やすが、速度だけでは信頼性は決まらない。要件はなお精査が必要で、テストは実装から独立していなければならず、影響の大きな変更には人間の注意が要り、本番での動作も観察しなければならない。著者によると、AIはこれらの防御を低コストで適用できるようにするが、それはチームが出力を、検証を通じて本番投入に値すると認められるまでは信用できない成果物として管理する場合に限られる。