When the Bill Comes Due: Amazon's AI Bet and the Engineers It Let Go
Did Amazon fire the very people who could have prevented its recent outages?
Amazon recently suffered multiple high-severity production incidents. At least one of these incidents is linked to AI-assisted coding changes. At roughly the same time, the company cut 30,000 corporate employees, many of them senior engineers, justified in part by expected AI efficiency gains.
The timing is hard to ignore.
Amazon experienced something that should give every technology leader pause. The company recently suffered multiple high-severity production incidents. These events were serious enough that Amazon's SVP of eCommerce Foundation, Dave Treadwell, convened a meeting of retail technology leaders to perform a "deep dive" into what went wrong. His internal memo described the incidents as having a "high blast radius." At least one was linked to AI-assisted coding changes.
At roughly the same time, Amazon has been in the process of cutting approximately 30,000 corporate employees across two rounds of layoffs in late 2025 and early 2026. Many of those cut were skilled software engineers and technical staff. Thousands of those cuts landed in Washington State, right at the heart of Amazon's engineering operations. CEO Andy Jassy has been explicit as to the reason: Amazon expects "efficiency gains from AI" to reduce the need for its corporate workforce.
So here is the question I'd like to ask you to sit with: Is it possible that Amazon is now experiencing the consequences of an AI strategy it championed just months ago?
At roughly the same time, Amazon has been in the process of cutting approximately 30,000 corporate employees across two rounds of layoffs in late 2025 and early 2026. Many of those cut were skilled software engineers and technical staff. Thousands of those cuts landed in Washington State, right at the heart of Amazon's engineering operations. CEO Andy Jassy has been explicit as to the reason: Amazon expects "efficiency gains from AI" to reduce the need for its corporate workforce.
So here is the question I'd like to ask you to sit with: Is it possible that Amazon is now experiencing the consequences of an AI strategy it championed just months ago?
A Pattern We've Seen Before
In my two most recent articles, I've been tracing a troubling arc in the AI coding story.
In No Vibe for Vibe Programming, I argued that the seductive speed of AI-generated code creates a dangerous illusion. Teams see rapid early results and assume the velocity will hold. What they don't see (yet) is the accumulating mass of code that nobody on the team truly understands. Vibe programming doesn't reduce your need for developers. It creates code your developers must maintain without ever having built it. That gap between what your team understands and what your codebase contains widens over time.
In The Rich Get Richer, I dug into GitClear's research showing that while top performers see impressive gains from AI coding tools, average developers see far more modest results. The hidden cost across the board is a dramatic increase in code churn. AI-assisted developers generated nearly 10 times more code churn than they did before AI tools. Churn is not just waste. Churn is a leading indicator of technical debt, architectural inconsistency, and the fragility that eventually manifests as production outages.
Both articles were pointing toward the same underlying concern: Increased use of AI coding increases technical debt and increases the need for senior engineers to deal with it.
Is Amazon now living this concern?
In No Vibe for Vibe Programming, I argued that the seductive speed of AI-generated code creates a dangerous illusion. Teams see rapid early results and assume the velocity will hold. What they don't see (yet) is the accumulating mass of code that nobody on the team truly understands. Vibe programming doesn't reduce your need for developers. It creates code your developers must maintain without ever having built it. That gap between what your team understands and what your codebase contains widens over time.
In The Rich Get Richer, I dug into GitClear's research showing that while top performers see impressive gains from AI coding tools, average developers see far more modest results. The hidden cost across the board is a dramatic increase in code churn. AI-assisted developers generated nearly 10 times more code churn than they did before AI tools. Churn is not just waste. Churn is a leading indicator of technical debt, architectural inconsistency, and the fragility that eventually manifests as production outages.
Both articles were pointing toward the same underlying concern: Increased use of AI coding increases technical debt and increases the need for senior engineers to deal with it.
Is Amazon now living this concern?
The Deleted Sentence
There is a detail about Amazon's internal memo that is worth examining carefully.
According to reporting from CNBC, an earlier version of the document shared before the meeting explicitly cited "GenAI-assisted changes" and the absence of "best practices and safeguards" as contributing factors to the outage pattern. That specific reference was deleted from the document before the meeting took place.
Amazon's spokesperson, meanwhile, clarified that "a single incident was related to AI and none of the incidents involved AI-written code."
What should we make of that?
According to reporting from CNBC, an earlier version of the document shared before the meeting explicitly cited "GenAI-assisted changes" and the absence of "best practices and safeguards" as contributing factors to the outage pattern. That specific reference was deleted from the document before the meeting took place.
Amazon's spokesperson, meanwhile, clarified that "a single incident was related to AI and none of the incidents involved AI-written code."
What should we make of that?
- The deleted passage.
- The careful parsing of "AI-related" versus "AI-written"
- The framing of an incident involving Amazon's Kiro AI coding tool as "user error rather than AI error”.
What do all of these tell us?
I'm not here to say Amazon is hiding something. I genuinely don't know what happened in those production systems. But it does beg the question, were these issues caused or at least exasperated by AI-assisted coding? This isn't a question unique to Amazon. It is a question every organization deploying AI coding tools should be asking of itself.
I'm not here to say Amazon is hiding something. I genuinely don't know what happened in those production systems. But it does beg the question, were these issues caused or at least exasperated by AI-assisted coding? This isn't a question unique to Amazon. It is a question every organization deploying AI coding tools should be asking of itself.
The Staffing Calculation
Amazon's position is a fascinating case study in the logic, and potential limits, of the AI replacement thesis.
The core argument goes like this: AI tools make developers significantly more productive. Therefore, you need fewer developers to accomplish the same amount of work. The headcount savings can be redeployed as AI infrastructure investment, which makes the remaining developers even more productive, creating a virtuous cycle.
It is a coherent argument. And it may even be partially correct.
But consider what the GitClear research actually showed. The developers showing the largest productivity gains from AI tools were already the highest performers. These were the senior and staff engineers who already had deep architectural understanding, broad codebase knowledge, and the judgment to evaluate AI suggestions critically. These are the people who, in the language of my previous article, "know what they're doing."
Now consider what Amazon's layoffs actually targeted. It wasn’t entry-level support roles. It wasn’t warehouse workers. According to multiple reports, the cuts hit corporate employees across engineering, program management, and technical roles. This included senior program managers, principal designers, and applied scientists. These are precisely the people who would otherwise be the guardrails on AI-generated code.
The question I'd invite you to consider: If AI coding tools derive most of their value from the skilled human judgment that guides, reviews, and corrects their output, what happens to that value when you reduce the pool of skilled human judgment available?
The core argument goes like this: AI tools make developers significantly more productive. Therefore, you need fewer developers to accomplish the same amount of work. The headcount savings can be redeployed as AI infrastructure investment, which makes the remaining developers even more productive, creating a virtuous cycle.
It is a coherent argument. And it may even be partially correct.
But consider what the GitClear research actually showed. The developers showing the largest productivity gains from AI tools were already the highest performers. These were the senior and staff engineers who already had deep architectural understanding, broad codebase knowledge, and the judgment to evaluate AI suggestions critically. These are the people who, in the language of my previous article, "know what they're doing."
Now consider what Amazon's layoffs actually targeted. It wasn’t entry-level support roles. It wasn’t warehouse workers. According to multiple reports, the cuts hit corporate employees across engineering, program management, and technical roles. This included senior program managers, principal designers, and applied scientists. These are precisely the people who would otherwise be the guardrails on AI-generated code.
The question I'd invite you to consider: If AI coding tools derive most of their value from the skilled human judgment that guides, reviews, and corrects their output, what happens to that value when you reduce the pool of skilled human judgment available?
What Treadwell's Response Tells Us
David Treadwell's response to the outage pattern is interesting. Amazon's stated remedies include:
- Requiring senior engineer sign-off on AI-assisted changes before deployment
- Introducing "controlled friction" to changes in the most critical parts of the retail experience
- Investing in "deterministic and agentic safeguards"
Read that first bullet point again. The solution to AI-assisted coding errors, as Amazon has defined it, is more senior engineer oversight. More human review. More experienced human judgment applied to AI outputs before they reach production. I couldn’t agree more.
Is it possible that we're watching a company simultaneously reduce its supply of senior engineers while increasing the demand for their oversight? We simply do not know.
Is it possible that we're watching a company simultaneously reduce its supply of senior engineers while increasing the demand for their oversight? We simply do not know.
The Institutional Knowledge Problem
There is a subtler dimension here that I think deserves more attention.
In No Vibe for Vibe Programming, I described the "vicious cycle" that AI-dependent teams fall into: they use AI to write code they don't fully understand, then use AI to help them understand it, then use AI again to modify it. At each step, the human developers understand the system less. The institutional knowledge of *why* the system is built the way it is, is simply forgotten over time. The countless micro-decisions that accumulate into a coherent architecture are no longer available for discussion and review.
Now extend that dynamic to a large organization that has simultaneously reduced its experienced engineering workforce and increased its use of AI coding. You lose institutional knowledge in two ways at once: the AI-generated code that nobody designed, and the experienced engineers who might otherwise have maintained the organizational memory of how everything fits together.
The result isn't just more bugs. It's a system that becomes progressively harder to reason about, harder to change safely, and harder to diagnose when something goes wrong. You have fewer people who understand the system, and more code that nobody truly understands.
In that environment, what does a "high blast radius" incident look like? What does recovery from it look like? And how long does it take?
In No Vibe for Vibe Programming, I described the "vicious cycle" that AI-dependent teams fall into: they use AI to write code they don't fully understand, then use AI to help them understand it, then use AI again to modify it. At each step, the human developers understand the system less. The institutional knowledge of *why* the system is built the way it is, is simply forgotten over time. The countless micro-decisions that accumulate into a coherent architecture are no longer available for discussion and review.
Now extend that dynamic to a large organization that has simultaneously reduced its experienced engineering workforce and increased its use of AI coding. You lose institutional knowledge in two ways at once: the AI-generated code that nobody designed, and the experienced engineers who might otherwise have maintained the organizational memory of how everything fits together.
The result isn't just more bugs. It's a system that becomes progressively harder to reason about, harder to change safely, and harder to diagnose when something goes wrong. You have fewer people who understand the system, and more code that nobody truly understands.
In that environment, what does a "high blast radius" incident look like? What does recovery from it look like? And how long does it take?
The Broader Question for All of Us
The real story here isn’t something specific about anything Amazon did right or wrong. The real story is almost certainly more complex. Amazon operates at a scale that makes most comparisons strained, its layoffs had multiple stated motivations, and its AI investments may yet prove to be the right long-term strategic bet.
But the pattern Amazon is exhibiting is not unique to Amazon. It's playing out, at varying scales, across the industry.
Companies are simultaneously:
- Deploying AI coding tools to accelerate development
- Cutting experienced engineering staff justified partly by AI efficiency gains
- Discovering that AI-generated code requires more skilled human oversight, not less
- Scrambling to add review processes and safeguards after production incidents
It’s the same sequence that I talked about in my vibe programming article at the team level. This same sequence is playing out at the organizational level.
Questions Worth Asking in Your Organization
I'm not going to tell you that Amazon made the wrong decisions. I don't know enough to say that, and frankly, neither does anyone else. But I would encourage you to ask some pointed questions in your own organization before you find yourself in a similar position:
On your staffing model: If your AI productivity thesis depends on skilled humans reviewing, guiding, and correcting AI outputs, are you maintaining enough of those skilled humans? Are you retaining the right ones? Are you growing new people to continue having these skills in the future?
On your incident response: When a production incident occurs in an AI-assisted codebase, do your remaining engineers have the depth of system knowledge required to diagnose and fix it quickly? What happens to your mean time to recovery as institutional knowledge erodes?
On your post-mortems: When AI-assisted changes contribute to an incident, are your post-mortem processes designed to surface that honestly? Or do organizational incentives point toward attributing problems to "user error"?
On your safeguards: Treadwell acknowledged that "best practices and safeguards around generative AI usage haven't been fully established yet" at Amazon. Have they been established at your organization? If not, what is your plan, and how does it interact with your current AI deployment pace?
On your staffing model: If your AI productivity thesis depends on skilled humans reviewing, guiding, and correcting AI outputs, are you maintaining enough of those skilled humans? Are you retaining the right ones? Are you growing new people to continue having these skills in the future?
On your incident response: When a production incident occurs in an AI-assisted codebase, do your remaining engineers have the depth of system knowledge required to diagnose and fix it quickly? What happens to your mean time to recovery as institutional knowledge erodes?
On your post-mortems: When AI-assisted changes contribute to an incident, are your post-mortem processes designed to surface that honestly? Or do organizational incentives point toward attributing problems to "user error"?
On your safeguards: Treadwell acknowledged that "best practices and safeguards around generative AI usage haven't been fully established yet" at Amazon. Have they been established at your organization? If not, what is your plan, and how does it interact with your current AI deployment pace?
The Bill Always Comes Due
Technical debt has always been characterized by this property: you can defer it, but you cannot escape it. The interest compounds invisibly until suddenly it doesn't. A production incident is one way the bill arrives. A maintainability crisis is another. A death spiral of increasing AI dependency combined with decreasing institutional understanding is a third.
Amazon is one of the most sophisticated technology organizations in the world. It has resources, engineering talent, and operational discipline that most organizations can only aspire to. If the approach of "move fast with AI tools, reduce headcount, establish safeguards later" is creating visible problems there, what does that suggest about less well-resourced organizations following the same playbook?
I don't have a definitive answer to that question. But I think it's one worth sitting with before you file the next round of headcount reduction requests.
And the next time you read an article that someone “without coding experience was able to rebuild a popular SaaS application in 3 hours using just AI,” maybe you’ll realize just how much of a farce that assertion really represents.
The bill always comes due. The only question is when will it come due? And when it does come due, do you have the people and the understanding to pay it?
Amazon is one of the most sophisticated technology organizations in the world. It has resources, engineering talent, and operational discipline that most organizations can only aspire to. If the approach of "move fast with AI tools, reduce headcount, establish safeguards later" is creating visible problems there, what does that suggest about less well-resourced organizations following the same playbook?
I don't have a definitive answer to that question. But I think it's one worth sitting with before you file the next round of headcount reduction requests.
And the next time you read an article that someone “without coding experience was able to rebuild a popular SaaS application in 3 hours using just AI,” maybe you’ll realize just how much of a farce that assertion really represents.
The bill always comes due. The only question is when will it come due? And when it does come due, do you have the people and the understanding to pay it?
