AI が生成した修正に関して最も役立つ質問は、「このパッチはコンパイルできますか?」ではありません。
それは「このパッチが間違っていたらどうなるか？」です。
その質問によってワークフローが変わります。これにより、システムは爆発範囲、可逆性、テスト、所有権、安全に戻る動作経路について推論することが強制されます。
本番環境の修正もリリースです
チームは、インシデントの修正を通常のリリースの考え方の例外として扱うことがあります。圧力が高いため、プロセスは薄くなります。
それは後ろ向きです。
インシデントの修正はまだリリースされています。チームの忍耐力が低下し、コンテキストが低下し、緊急性が高まった瞬間に、本番環境の動作が変化します。 AI が変更の草案作成を支援する場合、ワークフローは構造を削除するのではなく、追加する必要があります。
パッチは小さくする必要があります。証拠を添付する必要があります。レビュー担当者は、どの動作が変更されるか、どのテストが実行されたか、どのロールバック パスが存在するかを把握している必要があります。
可逆性が製品の特徴です
ロールバック思考は悲観主義ではありません。製品品質です。
修復プル リクエストがマージされる前に、チームは次のことに答えることができる必要があります。
- この変更をきれいに元に戻すことはできるでしょうか?
- 移行、顧客データ、請求状態、または権限に影響しますか?
- 再試行動作、キューのセマンティクス、冪等性は変わりますか?
- 機能フラグまたは段階的なロールアウトが必要ですか?
- 障害モードはパッチ適用前よりもパッチ適用後の方が安全ですか?
これらの答えが不明瞭な場合は、AI アシスタントがその旨を伝える必要があります。自信を持った説明は、可逆的な変化の代わりにはなりません。
PRに含めるべき内容
AI によって生成された強力な修復 PR にはコード以上のものが必要です。
ロールバックに関する短いメモを含める必要があります。変更を元に戻す方法、パッチが間違っていることを示す信号は何か、データをクリーンアップせずに元に戻すのが安全かどうかなどです。
これには、トレース、ログ パターン、デプロイの比較、パッチを作成したファイル パスなどの証拠が含まれている必要があります。
これには、変更が予想されるサービス、エンドポイント、ジョブ、テナント セグメント、または顧客パスなどの範囲を含める必要があります。
テストの信頼性、つまり何が実行され、何が実行されなかったのか、マージ前に人間が何を検証する必要があるのかを含める必要があります。
避けるべき間違い
危険なパターンは、運用計画のない、もっともらしいパッチです。
差分も早く出てくるので効率良さそうです。実際には、不確実性を調査から検討に移します。レビュー担当者は、ワークフローでスキップされたすべての質問をする必要があります。
それは加速ではありません。フォーマットが改善された借金です。
より安全なデフォルト
AI によって生成された修正は、ロールバック コンテキストを含む人間によるレビュー済みのプル リクエストをデフォルトにする必要があります。自動マージを使用する場合は、強力なテストと明確な所有権を使用して、範囲を限定して元に戻せる変更に限定する必要があります。
これにより、コード パスの検索、証拠の準備、最小のパッチの作成など、自動化の有用な部分が維持されます。
これにより、プロダクションをモデルが黙って即興演奏できる場所として扱うという無謀な部分が回避されます。
ロールバック思考は、AI 修復を正しい意味で退屈なものにしてしまいます。修正は、進む方向と戻る方向、そしてエンジニアが選択するための十分な証拠とともに提供されます。
