Amazon's Senior Sign-Off Rule Is the Right Response to AI-Caused Outages

Amazon’s decision to require senior engineer sign-off before AI-assisted changes land in production, reported by Ars Technica following a string of outages attributed to AI-generated code, is drawing the usual skepticism: it won’t scale, it creates bottlenecks, it treats the symptom rather than the cause. These objections misidentify what the policy is for.

The Failure Mode the Policy Targets

The outages that prompted this policy were not caused by syntax errors or type mismatches. Those categories of bug are caught by automated tools already embedded in every modern CI pipeline. The failure mode that sends production systems down at AWS scale is something different: plausible-but-wrong code. Changes that are syntactically valid, pass all tests, survive a quick read, and are wrong in ways that only surface under specific production conditions that nobody wrote a test for.

This is the characteristic failure mode of AI-generated code, and it is categorically different from the defects that static analysis, type checkers, and test suites are designed to catch. A model generating a Terraform module for VPC routing has no access to the operational state of the live system. It produces configurations that are valid against the schema and consistent with the patterns in its training data. Whether a given configuration interacts correctly with the specific topology your payments service runs on, the specific partition scenarios your on-call team has learned to fear, or the implicit ordering constraints between your ACL rules that nobody wrote down anywhere, is outside what the model can know.

Infrastructure and operational code carries this risk in a concentrated form. Application logic typically has test coverage and fails in ways that surface during staging or canary rollouts. A change to a cross-region failover configuration, an IAM permission boundary, or a service mesh routing rule may have no automated test coverage at all. Its correctness depends entirely on understanding the production system as it actually operates, and AI models cannot observe that.

Why Senior Engineers Specifically

The policy does not require any review. It requires senior engineer review. That distinction is load-bearing.

A reviewer without deep production context will evaluate whether a change is syntactically correct, whether it matches the stated intent, and whether it follows team conventions. They will not catch that the change breaks an assumption that lives only in an incident postmortem from two years ago or in the institutional memory of the engineers who were on call during the last major failover. Junior reviewers are susceptible to the same failure mode as the AI: they can assess plausibility but not production correctness.

Research on pair programming is instructive here. Studies consistently find that the benefit of a second reviewer scales with the expertise gap between the two. When two junior engineers review each other’s work, they catch syntax errors and obvious logic mistakes. When a junior engineer works with someone who has owned a production system through multiple incidents, they catch a different category of problem, the kind where the code is right but the assumptions are wrong. Amazon’s policy applies that same logic to the AI review gate.

The senior engineer carries a mental model that automated tools cannot encode: what invariants are maintained by humans rather than enforced by the system, which services have undocumented cross-dependencies, which operational sequences will expose a gap between what the code specifies and what the system will actually do. For AI-generated infrastructure changes, that model is the only review that matters.

This Pattern Has Established Precedent

Mandatory human sign-off by a designated reviewer before code ships is not a new idea applied awkwardly to a new problem. It is the standard control in any domain where the cost of a wrong deployment justifies the overhead.

Aviation software developed under DO-178C requires review artifacts keyed to software criticality levels. Safety-critical functions require multiple sign-offs from engineers whose qualifications are documented. The underlying reasoning is the same as what Amazon is applying: automated verification catches known categories of defect; human review catches the rest, up to whatever knowledge the reviewer brings.

Medical device software under IEC 62304 applies comparable requirements. Class C software, the category with potential for serious patient harm, requires design reviews formally traceable to safety requirements. These reviews are not optional and not waivable under deadline pressure.

Financial services change management controls under Sarbanes-Oxley require documented approval from designated reviewers before deployment to systems that affect financial reporting. The SOX-era change advisory board generated a lot of paperwork and moved slowly, but the principle it enforced was sound: certain categories of change require human authorization before they ship.

Amazon is not inventing a novel control. It is applying a mature one to a risk category that has only recently become relevant at software companies.

The Scalability Objection Is a Different Problem

The most common criticism of the policy is that it will not scale. This is true and beside the point.

The policy is not designed to be permanent. It is designed to reduce the incident rate while the industry builds tooling that would make a more mechanical control possible. That tooling, reliable AI provenance tracking in commit metadata, CI-level gates triggered by provenance markers, audit trails that survive post-incident review, does not exist in production-ready form today. Until it does, process controls with human enforcement are the available option.

The history of infrastructure change management follows this arc. ITIL-style change advisory boards were the correct interim state when infrastructure changes required human coordination and the tooling to enforce constraints mechanically did not yet exist. Terraform and infrastructure-as-code eventually replaced the honor-system layer by making infrastructure state explicit and auditable in version control. That transition happened because the industry built better tooling, not because it decided the review requirement was unnecessary.

Objecting to Amazon’s sign-off policy now on scalability grounds is equivalent to objecting to pre-deployment CAB reviews in 2005 because they would become unnecessary once Terraform existed. True as a long-term observation, irrelevant to the current moment.

What the Review Has to Actually Do

The policy only creates value if the review engages with the specific risks AI generation introduces. A senior engineer approving an AI-generated change because CI is green and the code looks reasonable adds nothing to the gate.

Useful review in this context asks the questions that automated tools cannot: Does this change interact with anything in the production topology that is not captured in the code? Does it depend on operational invariants maintained by humans rather than enforced by the system? Does the logic hold at production scale, under failure modes that have not been explicitly modeled in any test?

These are questions the engineer who has owned a system through multiple production incidents is positioned to ask. They require exactly the knowledge that a model generating the code could not have had. The policy designation of senior engineer is not cosmetic; it reflects a required knowledge threshold. A pro-forma sign-off from a senior engineer who does not engage with those questions provides the same false assurance as skipping the review entirely, which is an argument for executing the policy well, not for abandoning it.

The Right Call

Amazon’s policy has real limitations. Self-reporting of AI-assisted changes is unreliable without tooling to enforce it. Sign-offs will sometimes be rushed under deadline pressure. The policy will not catch every AI-generated issue, particularly in code paths where reviewers do not recognize the AI contribution.

These limitations are real and worth solving. They are not an argument against the policy. They are arguments for building the tooling that makes the control mechanical instead of procedural, which is the same path every other high-stakes change management practice has eventually taken.

For right now, the failure mode that caused Amazon’s outages requires a reviewer who carries knowledge the model could not have accessed. Senior engineers are that reviewer. The policy correctly identifies both the problem and the right layer at which to address it.