Amazon's AI Code Is Breaking Production
I wrote about cognitive debt a few days ago, the idea that AI lets you produce things you can't explain, and that the bill eventually comes due. I didn't expect the bill to arrive at Amazon within the week.
On March 5th, Amazon's retail site went down for six hours. Tens of thousands of customers couldn't check out, couldn't access their accounts, couldn't load product pages. Amazon linked it to a "software code deployment," but five days later an emergency leadership meeting told a different story: internal briefing materials referenced "Gen-AI assisted changes" and acknowledged that safeguards for AI-assisted coding were "not yet fully established." Amazon formally denied that AI-written code was involved, and I think their denial is more interesting than the outage itself.
The Semantic Game
Amazon's official position: "none involved AI-written code." Their distinction is that it wasn't AI-written code, it was an engineer following "inaccurate advice that an agent inferred from an outdated internal wiki." I believe they think this exonerates them, but it describes something worse. The AI didn't just write bad code, it confidently synthesized bad guidance from stale documentation, and an engineer trusted it without verifying.
That's automation bias in its purest form, trusting the machine's output because the machine produced it, not because you independently verified it. The gap between "AI wrote the code" and "AI told the engineer what to write, and the engineer didn't question it" is not the gap Amazon seems to think it is.
I mentioned in the cognitive debt piece that people overestimate their understanding of things until they're asked to explain step by step, what psychologists call the Illusion of Explanatory Depth. Applied to code, developers mistake being able to read AI-generated code for actually understanding it. Having the code in front of you feels like comprehension. It isn't.
The December Warning
The March outage wasn't even the first sign. Back in December 2025, AWS Cost Explorer in China went down for thirteen hours after Amazon's internal AI tool Kiro resolved a reported issue by deciding, on its own, to "delete and recreate the environment." The agent had inherited an engineer's elevated permissions, bypassing the two-person sign-off that exists precisely to prevent this kind of thing. Amazon called it "user error," and technically they were right: the error was trusting an AI agent with admin credentials and walking away. But framing it that way misses the systemic problem, because the AI acted within the permissions it was given, did something reasonable-sounding but catastrophically wrong, and nobody caught it because the review process assumed a human was writing the code.
This happened while Amazon was aggressively pushing Kiro adoption internally, with a leadership memo setting an 80% weekly usage target. By January, roughly 70% of engineers had used it. Sobering to think that roughly 1,500 engineers internally endorsed Claude Code instead, calling Kiro "second best," which means even the engineers being told to use the tool didn't fully trust it.
The 90-Day Reset
Now, Amazon has announced a 90-day "code safety reset": two-person review mandated for all changes touching Tier-1 systems, director-level and VP-level audits across the board, and mandatory use of their internal change management tooling for all production deployments. A trillion-dollar company deliberately slowing down AI should make one think about the right use of this technology.
What Amazon discovered is something the industry doesn't want to say out loud: you can't review code you didn't write and don't understand. Two-person review only works if both people can actually reason about what the code does, and when AI generates the code and neither reviewer built the mental model, the review becomes theater. You're scanning syntax, not verifying logic.
The broader pattern confirms this. Consider that AI now contributes nearly half of all code for developers who use it, and roughly half of all new code at Google is now AI-generated. Code churn has nearly doubled since these tools became widespread, AI-generated pull requests contain roughly twice as many issues as human-written ones, and a Stanford study found that developers using AI assistants wrote more security vulnerabilities while believing their code was more secure. Not just getting it wrong, being more confident while getting it wrong.
Deciding Not to Decide
Amazon isn't alone. Debian, the Linux distribution underpinning much of the internet's infrastructure, recently shelved their decision on whether to accept AI-generated code contributions because three internal factions couldn't agree and enforcement was practically impossible anyway. They called it "deciding not to decide," and I think that phrase captures where most of the industry actually is right now. Nobody wants to ban AI coding tools because the productivity gains are real, nobody wants to fully embrace them because the failure modes are becoming clearer by the month, and everyone's quietly hoping the problem resolves itself. It won't, because the underlying issue isn't the tools. The underlying issue is that humans are building systems they can't explain, and the complexity is compounding faster than understanding.
The Bill Arrives
The cognitive debt framework predicted exactly this, the bill comes due the first time something breaks and nobody can explain how it was supposed to work. But Amazon is probably the best-positioned company on earth to handle this problem, with the engineering depth, the operational discipline, the resources to impose a 90-day reset, and even they're struggling.
If Amazon can't review its own AI-generated code, the question for every other company shipping AI-assisted software is blunt: can you? The velocity feels like progress, the diffs look clean, the tests pass, but somewhere between the prompt and production, understanding quietly left the building.