Amazon and agentic AI: when the code slips out of human hands

Picture this. You are an engineer at Amazon. On a Thursday afternoon, the retail site goes down. Not a discreet error page tucked away in a corner of the platform, no. For six hours, tens of thousands of users can no longer see prices, access their account, or complete a purchase. The next day, an email from SVP Dave Treadwell lands in every inbox: "the availability of the site and related infrastructure has not been good recently." It is the kind of understatement you reach for when the situation is far worse than anything you can put in a corporate email.

And then, the following week, word gets out that the internal weekly meeting, the TWiST, "This Week in Stores Tech," until now optional for many engineers, becomes mandatory for everyone. With an agenda that leaves no room for ambiguity: understand what happened, and above all why it keeps happening.

What has been unfolding at Amazon for the past few weeks goes far beyond a technical anecdote. It is a real-time case study of what happens when an organization pushes agentic AI into its critical systems without having built the organizational guardrails that go with it.

The sequence of events

The incidents did not fall out of the sky. They piled up over several months, with a clear acceleration early in the year.

In mid-December 2025, the internal development tool Kiro, AWS's in-house AI assistant, caused a 13-hour outage on AWS Cost Explorer in the Mainland China partition. According to several AWS engineers cited by the Financial Times, the agent is said to have taken it upon itself to delete a production environment and recreate it from scratch, rather than apply the planned incremental fix. Three AWS employees confirmed to the FT that the engineers had let the AI resolve the problem without human intervention.

Shortly afterward, a second incident, less severe, this time involving Amazon Q Developer. Here again, an AI-assisted code change produced unexpected behavior in production.

Then on March 5, 2026, it was US retail that went down. Six hours of unavailability. More than 22,000 reports on Downdetector at the peak of the outage. Broken checkout, order history out of reach, prices that no longer displayed. The official cause given by Amazon: "a software code deployment."

What the internal memo says (and what was taken out of it)

This is where the affair becomes especially revealing.

A briefing document prepared for the TWiST meeting on March 10, shared with the Financial Times, explicitly referred to a "trend of incidents" since the third quarter, characterized by a "high blast radius" and "Gen-AI assisted changes." The text noted that best practices and guardrails around these tools were "not yet fully established."

But, and this is the detail that says the most about internal politics, CNBC reports that the explicit mention of GenAI was removed from the document before the meeting. After the publication of their article, an Amazon spokesperson stated that a "single incident" was linked to AI and that no incident involved code written by AI.

You can measure here the full tension between operational reality and the public narrative. On one side, an SVP asking the entire division to understand what is happening. On the other, corporate communications that methodically downplay it.

The decision that changes the game

The organizational response, for its part, is unambiguous. Treadwell told the teams that junior and mid-level engineers will now have to obtain approval from a senior engineer before pushing any GenAI-assisted change to production. In his message, he mentions introducing "controlled friction" on the most critical parts of the retail platform, alongside an investment in more durable guardrails, both deterministic and agentic.

In plain terms: after a phase of massive, accelerated adoption of AI development tools, Amazon is reintroducing human validation where it had been removed, or never installed in the first place.

The context that makes all of this systemic

These incidents are not happening in a vacuum. They occur in a context that amplifies every signal.

Since October 2025, Amazon has cut roughly 30,000 corporate jobs in two successive waves, 14,000 in October, 16,000 in January 2026, affecting AWS, retail, Prime Video, human resources. James Gosling, the creator of Java and a former distinguished engineer at AWS, publicly stated on LinkedIn that after the explosion of hype around AI, he had been "astonished by how the structure of the business got torqued around, and how teams got demolished," teams that did not directly generate revenue but were essential to the stability of the infrastructure.

In parallel, Amazon claimed to have deployed 21,000 AI agents within its Stores division, with announced savings of 2 billion dollars and developer velocity multiplied by 4.5. Figures spectacular enough to make any reversal on AI adoption politically impossible.

This gets to the heart of the problem. AI tools were not introduced as a complement. They were introduced as a partial replacement for humans, and headcount was reduced accordingly. When incidents multiply, there are no longer enough senior engineers to absorb the volume of review that the new rules require.

What this means for all organizations

The Amazon case is instructive because it is happening in one of the most sophisticated engineering organizations in the world. If Amazon, with its deployment pipelines, its runbooks, its automated rollback mechanisms and its blameless post-mortem culture, ends up having to reintroduce human friction on its critical systems after AI-related outages, then the question for every other organization is not "will it happen to us?" but "when and at what scale?".

Agentic AI is extraordinarily effective at generating code, refactoring modules, prototyping. But as soon as it operates on production systems with complex dependencies, sensitive business logic, availability stakes or direct revenue implications, it remains fundamentally incapable of measuring the systemic consequences of its own decisions. An agent that deletes a production environment to recreate it is an agent that has found the optimal solution to a local problem with no understanding of the global one.

That is exactly the difference between writing code and understanding a system.

The three reflexes I recommend

In my consulting work and my support of technical teams, I stand by three principles that the Amazon case validates in spectacular fashion.

The first: no code fully generated or heavily modified by AI should reach a critical production environment without qualified human review. Not a cosmetic review, a review by someone who understands the target system.

The second: critical areas, checkout, pricing, authentication, payments, identity management, must remain under the explicit sign-off of a technical lead or an architect, whatever the tool used to produce the change.

The third: measure the real indicators. Not raw velocity. Velocity, production bugs and time to resolve incidents, together. When Amazon announces a 4.5x productivity gain but strings together six-hour outages, that is the signal that the numerator was optimized without looking at the denominator.

The final word

We talk a lot about AI as autopilot. The Amazon case is a reminder of a more prosaic reality: in March 2026, AI is a brilliant copilot, but blind to the consequences of its own maneuvers. The organization that confuses the two ends up with a grounded plane.

And in a grounded plane, it is never the algorithms that explain the failure to the passengers.