Verification Fatigue and the Three-Way Gate
Amazon just restricted the deployment of AI-generated code after production outages. Their fix: require senior engineer sign-off on every AI-assisted change.
That's putting a human gate on a firehose.
I learned the same lesson with Terraform. I use coding agents for infrastructure, and early on one of them issued a terraform destroy that destroyed a service — fortunately in dev! The agent wasn't hallucinating. It followed the state file logically. It wasn't wrong, it just wasn't checked.
The natural reaction is "I'll review every plan myself from now on." I did that for about a week. You know what happens? 95% of plans are safe creates and tag changes. You start rubber-stamping. And then the one plan that actually matters, the one with a destroy line buried in 200 lines of output, sails right through. Verification fatigue.
The fix wasn't better reviewers. Terraform plan output is fully parseable. So I built a three-way gate:
- Auto-pass: creates only, tag changes, no stateful resources touched.
- Human escalation: any destroy, modifications to databases or S3 buckets, IAM or security group changes.
- Auto-fix: known drift patterns like duplicate resources or tag normalization.
Now when something lands in my review queue, I know it actually needs my eyes. The gate didn't just catch the dangerous changes, it made me better at reviewing the ones that matter. By routing the easy cases away, you train yourself to pay attention when something does come through. Same lesson ops teams learned with PagerDuty: if every alert is critical, none of them are.
Amazon's instinct is right. Add a gate. But make it deterministic first, and only route to humans what actually needs judgment.
Read the full Trust Topology writeup →