On March 5, 2026, Amazon's North American retail site lost approximately 99% of its order volume for nearly six hours. Internal documents obtained by Business Insider put the number at 6.3 million lost orders. Three days earlier, a separate incident had already caused 120,000 lost orders and 1.6 million site errors. Both were traced to AI-assisted code changes deployed to production.
The root cause of the March 2 incident was Amazon's own AI coding assistant, Q Developer, which gave an engineer inaccurate advice inferred from an outdated internal wiki. The engineer acted on it. The change shipped. The site broke.
The March 5 outage was worse: a production change deployed without the mandatory documentation and approval process. No formal review. No sign-off. Straight to production on one of the highest-traffic retail platforms on earth.
Amazon's response wasn't to build a smarter AI assistant or deploy an autonomous testing agent. It was a 90-day safety reset across 335 critical systems. The new rules:
Read that list again. Two-person review. Documentation. Approval gates. Senior sign-off. These aren't cutting-edge practices. They're the fundamentals that every engineering textbook has recommended since before AI wrote its first line of code. Amazon didn't need a new tool. It needed the process it already had — enforced.
Amazon's outage is the most visible case, but it's not an outlier. Lightrun's 2026 State of AI-Powered Engineering Report, surveying 200 senior SRE and DevOps leaders, found that 43% of AI-generated code changes require manual debugging in production — after passing QA and staging. Not before. After.
Zero percent of respondents described themselves as "very confident" that AI-generated code will behave correctly once deployed. Not a minority. Zero.
The broader picture:
The code is shipping faster than ever. It's also breaking faster than ever. The speed gain and the failure rate are the same phenomenon — the review and testing steps that used to catch these bugs are the same steps that got compressed to save time.
Here's the part that connects Amazon's outage to every other outage we've written about this year. The Shopify Cyber Monday failure was a login flow nobody load-tested. The emergency call system outage was a certificate renewal nobody verified. Amazon was a code change nobody reviewed against the real system.
The pattern is always the same: the test that would have caught it was simple, the flow was critical, and nobody ran it.
AI-generated code makes this worse in a specific way. When a human writes a code change, they have context about the system — the load patterns, the edge cases, the downstream dependencies. When an AI generates a change based on an outdated wiki page, it doesn't know what it doesn't know. It produces code that looks correct in isolation and fails under the conditions that actually exist in production.
A unit test won't catch this. The unit test verifies the logic of the change in isolation — the same isolation where it looked correct. An integration test against a mock won't catch it either, because the mock doesn't have the stale state, the concurrent traffic, or the downstream service that chokes on the new payload format.
The only test that catches it is one that runs the actual change against the actual system and watches what actually happens. The order page loads. The checkout completes. The payment processes. The confirmation email arrives. If any of those steps fail, you know before your customers do.
The zero-percent confidence number from the Lightrun survey deserves its own section. Two hundred senior engineering leaders — people whose job is to keep production running — and not one of them is very confident that AI-generated code will work correctly in production.
They're still shipping it. The productivity pressure is real: 84% of developers use AI coding tools daily. The code volume has increased dramatically. But the testing capacity hasn't scaled to match, and the review process that used to serve as a safety net has been compressed into a rubber stamp.
Amazon's mandatory two-person review is an acknowledgment that the old single-reviewer model doesn't work when the code wasn't written by the person submitting it. The reviewer needs to be more skeptical, not less, because the author — an AI — can't explain why it made a particular choice. It doesn't have reasons. It has patterns.
Strip away the headlines about AI going rogue and look at what Amazon actually did. They didn't ban AI coding tools. They didn't build an AI agent to test the AI's output. They imposed process: review the code, document the change, get sign-off, run automated checks. They made it harder to skip the step between "the code exists" and "the code is in production."
That step — the one between writing and shipping — is where testing lives. Not unit tests in the CI pipeline, though those help. The test that matters is the one that runs the real flow on the real system and confirms the thing you're about to ship doesn't break the thing your customers depend on.
Amazon can afford a 90-day safety reset and mandatory senior review on 335 systems. Most teams can't. But most teams can do the simpler version: record the critical flows, replay them against the real app after every change, and know — before the deploy goes out — whether the checkout still works, the login still holds, and the dashboard still loads.
The $24 billion test automation market is building AI agents that write tests, heal tests, and plan tests. Amazon just spent a quarter re-learning that someone needs to run them.