エージェントが生成したコードを責任を持って扱う: Vercelのフレームワーク

(vercel.com)

11 ポイント投稿者 GN⁺ 27 일 전 | まだコメントはありません。 | WhatsAppで共有

コーディングエージェントは前例のない速度でコードを生成するが、厳密な判断なしに使えば、誤った前提をそのまま本番にデプロイするための効率的な経路になってしまう
エージェントが生成したコードは、PR説明、静的解析の通過、テストカバレッジまで備えており、経験豊富なエンジニアが書いたもののように見えるが、実際の本番環境のトラフィックパターン・障害モード・インフラ制約はまったく反映できていない
AIを**活用する(leveraging)ことと依存する(relying)**ことは根本的に異なり、真の活用とは、エージェントの出力物の動作方式とリスクを完全に理解し、オーナーシップを持つことを意味する
自律型デプロイ、継続的検証、実行可能なガードレールという3つの原則によって、エージェントが高い自律性で動作しながらも安全な環境を構築できる
最も多くコードを生成するエンジニアではなく、何をデプロイすべきかについて冷静な判断力を保てるエンジニアが生き残る時代になった

問題: Green CIはもはや安全の証拠ではない

CI通過は単にエージェントがパイプラインを納得させる能力を反映しているにすぎず、実際のインフラの安全性とは無関係
- テストは通るが、本番でフルテーブルスキャンするクエリをデプロイしてしまう可能性がある
- 正常に見えるリトライロジックが、ダウンストリームサービスにThundering Herdを引き起こす可能性がある
- TTLのないキャッシュがRedisを静かに死に至らせることがある
エージェントは、Redisインスタンスの容量状況、DBに特定リージョンのハードコードがあるかどうか、フィーチャーフラグのロールアウトがダウンストリームシステムの負荷プロファイルを変えるという事実などを知らない
**「このPRは正しそうに見える」と「このPRは安全にデプロイできる」**の間のギャップは常に存在しており、エージェントはそのギャップをさらに広げる

依存(Relying): エージェントが書いてテストが通れば、デプロイ準備完了だと仮定するやり方
- 作成者が変更内容についてのメンタルモデルを構築しない
- 作成者もレビューアもコードが実際に何をするのか把握しないまま、隠れた前提だらけの巨大なPRが生まれる
活用(Leveraging): エージェントを高速な反復に活用しつつ、出力物に対する完全なオーナーシップを維持するやり方
- コードが負荷下でどのように動作するかを正確に把握する
- 関連するリスクを理解し、それを引き受ける意思がある
PRに名前を載せることは、「読んで、何をするものか理解している」という意味であり、これがエンジニアリングプロセスの基準点

シンプルなテスト: 「このPRに結びつく本番インシデントを自分がオーナーとして引き受けることに抵抗はないか?」
PRを出す前に自分へ問うべき3つのこと
- このコードは何をするのか? ロールアウト後にどう動作するのか?
- 本番や顧客にどのような悪影響を及ぼし得るのか?
- このコードに結びつくインシデントを自分がオーナーとして引き受けることに抵抗はないか?
「Yes」ならAIを活用できているのでデプロイ、「No」ならまだやるべきことがある

自律型デプロイ(Self-driving deployments): すべての変更はゲート付きパイプラインを通じて段階的にロールアウトされ、カナリアデプロイは性能劣化時に自動でロールバックする
- エンジニアがダッシュボードを監視するやり方に依存しない
- 問題発生時も全体ではなくトラフィックの一部でのみ隔離して処理される
継続的検証(Continuous validation): デプロイ時だけでなく、常時インフラ自体のテストを実施する
- 負荷テスト、カオス実験、災害復旧訓練が継続的に実行される
- Vercelが昨年夏に本番でリハーサルしたデータベースフェイルオーバーが、実際にAzure障害が発生した際に顧客へまったく影響を与えなかった理由
実行可能なガードレール(Executable guardrails): 運用知識をドキュメントではなく、実行可能なツールとしてエンコードする
- safe-rolloutスキルは、フィーチャーフラグの動作を説明するNotionページではなく、フラグを接続し、ロールバック条件付きのロールアウトプランを生成し、想定動作の検証方法を明示するツール
- ガードレールが実行可能であれば、エージェントは自律的にそれに従え、人間はそれを暗記する必要がない