AIがコードを書く時代、検証は誰が担うのか
AI Can Write the Code. Who Verifies It?
22,000人の開発者を2年間追跡したFarosの調査によると、AI導入率の高い組織では開発スループットが上がる一方、開発者あたりのバグは54%増、PRレビュー時間は約5倍、PRあたりのインシデントは3倍以上に膨らんだ。AIが生成した巨大な差分を少人数でレビューするのは現実的ではない。SuperpowersやRoboRev、Claude Code Review、Codex Review、Copilot、Cursor Bugbotといったツールを整理しつつ、リンターやテスト、セキュリティスキャン、AIレビュー、人間の承認を組み合わせた検証パイプラインの全体像を示す。
モデルの多様性は魔法ではない。2つのエージェントが同じ誤った答えで一致したり、同じ要件を見落としたり、存在しないバグを自信満々に指摘したりすることもある。
HNでの議論
58- pianopatrick
私が考えているアイデアの一つは、リンターを使ってAIが使える言語を、レビューがあまり必要ないようなサブセットに制限することです。
例えば、特定のHTMLタグと特定のCSSプロパティのみを許可し、JavaScriptを一切使わないWebフロントエンドを書けば、ある種のエラーを完全に回避できます。
あるいは、C言語で動的メモリ割り当てを禁止すれば、やはりエラーのクラス全体を回避できます。
これらはリンターで設定できるチェックだと思うので、AIが生成したコードに特定のエラーがないという確信をより持てるようになります。
- alcomatt
ここでの問いは、「すべてがうまくいかなくなったとき、誰が責任を取るのか？」であるべきかもしれません。
- salawat
伝統的には、それは専用のQAチームと、部分的にエンジニアリングチームが支援する共同作業でしたが、誰もその費用を払いたがらないのです…
- thisisthenewme
AI：
- コードを書く
- コードをレビューする
- 設計する
- 製品化する
- 宣伝する
- 消費する
- simianwords
何人かの友人と、エージェントに完全にコミットしているなら$current_yearでCI/CDをどう使うべきかについて話していました。業界の適応は驚くほど遅く、私は業界で標準化してほしい2つの機能について書いています。
エージェント的テスト（ひどい響きだと分かっています）の標準化が欲しいのです。これは、システムの曖昧な意図を捉える、より広範なテストです。ユニットテストやe2eテストは焦点が絞られていて維持が難しい。エージェント的テスト（または振る舞いテスト）では、エージェントが根底にある振る舞いの意図を理解し、その場でシナリオを作成して実行します。
例えば、Claude Codeが複数のエージェント的テストを通過することを想像します。そこではClaude自身がデスクトップ制御を使ってソフトウェアを使おうとします。これによりはるかに広範なバグを捉えられ、e2eテストやユニットテストに必要な面倒な配線（モックとか、もう）がなく、意図の記述だけが必要なので維持もずっと簡単です。
SCENARIOS.mdのようなものを用意するだけで、フレームワークがテストに必要な共通環境を立ち上げてシナリオを実行してくれるようなフレームワークが欲しいです。業界はこの種の機能がひどく欠けています。
次に欠けているのは、エージェント的デプロイ検証です。
サービスをデプロイしていて、すべてのサーバーに昇格させる前に複数のメトリクスが正常であることを検証する必要があると想像してください。伝統的には、これは開発者による手動チェック（面倒でエラーが起きやすい […]