Amazon Strolls Into Mordor

We’ve been noticing significant downtime from critical services at work recently. At GitHub, at AWS. We’ve been joking about vibe-coding at these companies. Joking, but kinda serious.

Turns out Amazon isn’t laughing.

The online retail giant said there had been a “trend of incidents” in recent months, characterized by a “high blast radius” and “Gen-AI assisted changes” among other factors, according to a briefing note for the meeting seen by the Financial Times. […] Junior and mid-level engineers will now require more senior engineers to sign off any AI-assisted changes, Treadwell added.

Good and long-established engineering practices — which Amazon (at least reputationally) once exemplified — should keep this from happening. I don’t think the engineers are at fault, though.

Amazon is pushing the blame downhill to the people whose independence they undercut. Roughly ten months ago, TechSpot reported they were force-feeding AI to developers:

Over the past year, managers have raised expectations and shortened deadlines, pushing engineers to adopt AI-powered tools like Microsoft’s Copilot and Amazon’s assistants to keep up with a relentless pace. Teams that once counted a dozen developers have been cut in half, yet the volume of code they’re expected to deliver remains unchanged – a shift that one engineer described to the New York Times as “building a feature for the website used to take a few weeks; now it must often be done within a few days.”

And there have been multiple rounds of layoffs. Last November Amazon cut 4,700 jobs, 40% of them engineers. Rumors say they will cut another 14,000 jobs next quarter.

This aggressive “right-sizing” appears to be driven by a new “efficiency matrix” that prioritizes AI-augmented productivity over traditional headcount. In divisions like Amazon Web Services (AWS), entire departments are reportedly being consolidated, with small clusters of senior engineers using advanced AI models like Claude Sonnet to manage workloads that previously required dozens of employees.

These teams are absorbing massive staffing cuts and dealing with reorganizations. It would be reasonable to expect that alone would represent a significant operational threat.

But they are also having to learn unproven tools that are changing rapidly, disrupting long-established workflows, with no “best practice” literature suggesting what to replace it with, and little understanding of the consequences. Meanwhile, both the pace of work and the productivity expectations have skyrocketed.

Oh no, the consequences, they’re here again

I am sure their engineers raised multiple warnings and those were waved away. Managers around the water cooler, saying: the engineers are just protecting their jobs. They’re resistant to change.

But no one embraces change quite like software engineers. My earlier skepticism about AI’s value came precisely because management was leaning on developer teams so hard to use it. If the tools are good, no one has to force them on developers.

And developers are coming around to AI. Some of us pay for it out of our pockets so we can do personal projects with it. We follow the news, learn the new practices. Our hands are on it enough to understand it.

But even the most enthusiastic AI-assisted developers I know are continually trying to rein in expectations. They can see that the speed of code generation far outstrips the ability for humans to review it. They recognize that changes this dramatic calls everything we do into question — and there are, as yet, no answers.

Even if we like using it, we all understand AI poses a threat to the quality and stability of the code we spend our days maintaining. We know it needs to be kept on a tight leash and the potential for dangerous or broken code making it into production is a vital and pressing concern.

But when the predicted failure arrived, Amazon’s response was to scold the engineers: y’all should have been paying more attention. Check your work. Seniors, keep your juniors in line.

“AI can make mistakes, please double-check responses.”

This is blame-shifting. Amazon created the environment that encouraged dangerous, irresponsible behavior and penalized responsible work. But they won’t take responsibility for it.

This pattern is not new. This pattern will repeat. If you’re an engineer facing this, I can’t tell you what to do. I don’t have your specific circumstances or problems. But I can say: some of us can see this is happening. And you are not the careless one.