The Amazon AI Outage Began With a Stale Wiki, Not Bad Code
Amazon traced its one AI-related incident to advice inferred from an outdated wiki. Why diff review cannot catch a stale premise and what control can.
Quick Answer
Amazon said only one of a cluster of retail incidents in March 2026 involved AI tooling, and that it began with an engineer following inaccurate advice an AI tool had inferred from an outdated internal wiki. No AI-written code was involved. That makes the Amazon AI outage a stale-evidence failure, where a change can correctly implement a false premise. Diff review cannot see the premise, so the control has to sit on the evidence and its age.
The Amazon AI outage of March 2026 is usually told as a story about AI-generated code. We think the version Amazon itself published is more useful, because it describes a failure that code review was never designed to catch.
According to Amazon, the one incident that involved AI tooling started with advice inferred from an outdated wiki page. Nothing in the chain malfunctioned by its own standards. The wiki was stale, the tool summarised what it found, and an engineer trusted a plausible answer.
This post covers what was reported and what Amazon said, why this is a stale-evidence failure, why review and faster detection both miss it, what a control on evidence looks like, and when diff review alone is enough.
Six Months of Arguing About the Wrong Artifact
Much of the debate about AI-assisted engineering has been about the quality of generated code, security flaws in it and its effect on delivery stability. That debate is about the artifact. The Amazon case is about the input.
In March 2026, The Register reported that a briefing note for Amazon's weekly retail operations meeting, seen by the Financial Times, described a "trend of incidents" with a "high blast radius" and "Gen-AI assisted changes." Amazon disputed the implication, repeating its earlier statement that it had "not seen compelling evidence that incidents are more common with AI tools."
We cannot settle that wider question from public data, and neither could The Register, which noted Amazon had provided no data for independent analysis. What we can do is read the one incident Amazon described closely.
What Amazon Said Actually Happened
Amazon answered the coverage with a correction of the Financial Times report. It said the meeting reviewed a few separate outages on its website and app, and that "Only one of the incidents involved AI-assisted tooling, which related to an engineer following inaccurate advice that an AI tool inferred from an outdated internal wiki, and none involved AI-written code."
The same statement says the cause was unrelated to AI and that its systems allowed an engineering team's user error to have broader impact than it should have. Amazon also said it had updated internal guidance to prevent similar problems.
Fortune's report on the incidents, citing the Financial Times, described four high-severity incidents on the retail site in one week, including a six-hour disruption to checkout, account information and pricing. We take Amazon's framing at face value here. The interesting part is not if the AI was to blame, but what kind of failure Amazon described.
A Stale-Evidence Failure Has Three Steps and No Broken Link
Walk the chain Amazon described, and each step did what it was supposed to do.
1. The Wiki Was Out of Date
Internal wikis drift as systems change. A page that was right when written becomes wrong without anyone editing it. We would expect most internal documentation to contain some pages like this.
2. The Tool Answered From What It Found
The AI tool inferred advice from the page it retrieved. Producing a confident synthesis of the available text is exactly what these tools are built to do, and nothing in the page told it the content was stale.
3. The Engineer Trusted a Plausible Answer
The engineer acted on advice from a tool that is usually right. That trust is the premise of adopting such tools at all.
We call this a stale-evidence failure, where a change built on that advice can be a correct implementation of a false premise. If a wiki says a setting is required and the change adds it, the code does what it intends. The failure lives in the gap between the documentation and the current state of production.
Why the Amazon AI Outage Gets Past Code Review
Some coverage suggested Amazon had added approval requirements for engineers using AI tools, and Amazon's correction says reports that it "introduced new approval requirements for engineers working with AI tools" are false. Senior sign-off on AI-assisted changes is still a control many teams are adopting, so it is worth asking if it would have caught this failure.
We do not think it would. A reviewer looking at a diff inspects the artifact, meaning the logic, the syntax and the stated intent. The diff does not contain the premise behind the change, the source of that premise or the date the source was last true.
A senior reviewer who sees a change that faithfully follows a documented procedure will approve it. The question review answers is if the code does what the author intended. The question that would have caught this failure is if the assumption behind the change is still true in production today, and nothing in a pull request puts that question in front of the reviewer.
That is why we treat a stale premise as a separate failure class from bad code.
- Bad code is visible in the diff, and more review time finds more of it.
- A stale premise is invisible in the diff, and more review time finds none of it.
- Seniority helps only if the reviewer happens to know the documented fact has changed, which is luck rather than a control.
We have argued elsewhere that a pull request is not a review gate on its own. The Amazon case shows a sharper version of the same point. Even a perfect review of the artifact cannot validate an input it never sees.
The Usual AI Quality Statistics Measure the Output
The figures most often quoted about AI and software quality all evaluate what was produced. Security scans measure generated code, delivery metrics measure throughput against stability, and telemetry studies such as the one behind our post on incidents per pull request and the AI productivity paradox count failures per change.
Those measures matter. None of them can tell a correct output built on a false input from any other change that later breaks production. In the data, a stale-wiki incident looks like a clean change that happened to fail. We think that makes stale evidence one of the least measured risks in AI-assisted operations.
Faster Detection Does Not Reach a Stale Premise
A common answer to AI risk is better runtime sensing rather than more gatekeeping. We agree for emergent faults, such as a retry loop that misbehaves only under high latency, which no reviewer could predict.
A stale premise is different. It is wrong at the moment of the decision, and it can be checked at that moment against the source's last-modified date. Detection is a safety net after the fact, while this failure needs a check on the evidence before the change is made.
A Control on Evidence Looks Like Citations With Dates
If the failure is in the evidence, the control has to attach to the evidence. We would build it from four parts.
- Agents must cite their sources, including the passage used, the time it was retrieved and the source's last-modified date.
- Reviewers get one added question, which is what premise the change rests on and if that premise has been checked against current production.
- A second check retrieves its own context rather than reading the first tool's summary, so both checks cannot inherit the same stale page.
- Documentation that agents rely on gets an owner and a review date, and pages past that date are marked as unreliable for automated use.
The third part matters most. Two readers of the same stale synthesis reach the same wrong conclusion, which is why independent verification has to mean independent evidence. Our post on cross-checking AI root cause analysis describes the same principle for investigations.
Tooling can make this the default. Look for agents that cite the evidence behind every finding and keep an audit trail a reviewer can read, so the human checks the reasoning and its sources as well as the change.
When Reviewing the Diff Is Enough
Not every AI-assisted change needs an evidence trail. We would not add one where the premise lives entirely in the code being changed.
A pure refactor, a test addition or a change whose correctness can be fully checked by running it locally carries its premise inside the diff. Review and tests already cover it. The evidence control earns its cost on changes that depend on facts about production, such as configuration, flags, access rules, runbook steps and operational procedures.
Put a Date on Every Piece of Evidence Your Agents Use
The Amazon AI outage is a useful case because nothing in it was exotic. A stale page, a confident summary and a trusting engineer exist in almost every company, and the resulting change would pass most review processes.
We would start small. Require citations with dates on agent advice, add the premise question to review checklists and find out which internal pages your agents actually read. For investigations, Operate runs dedicated AI agents that cite their evidence, log every query they run and propose fixes as a patch for an engineer to review.
Frequently Asked Questions
Amazon says no AI-written code was involved and only one incident involved AI tooling, where an engineer followed inaccurate advice an AI tool inferred from an outdated internal wiki. We read that as a stale-evidence failure, since the tool reported what an out-of-date source said.
It is a failure where a person or tool acts correctly on information that is no longer true, so the resulting change faithfully implements a false premise. We see it as distinct from bad code, because the error sits in the source rather than in the artifact that gets reviewed.
Some coverage reported new approval requirements, but Amazon said those reports were false. We think the more useful question is if senior sign-off would catch this failure class, and we doubt it, because the stale premise never appears in the diff.
Make agents cite sources with retrieval and last-modified dates, give each relied-on page an owner and a review date, and flag stale pages as unreliable for automated use. We also have a second check gather its own evidence rather than reuse the first answer.
Review inspects what the change does, not the facts it was based on. We find it reliable for logic and style errors, but a change that correctly follows an outdated procedure looks right in the diff, so the premise needs its own check.
About the author
Operate Team
The team behind Operate
Operate Team builds Operate, enterprise AI agents for production operations. Operate answers production questions from Slack and Microsoft Teams, investigates alerts, and reviews performance, security and cost. It finds the root cause with evidence and proposes a fix for an engineer to review, with controlled access to your systems.
