Amazon finds out AI programming isn’t all it’s cracked up to be

Businesses love that they can use AI to replace those pesky, expensive developers . For example, Atlassian just laid off 10% of its workers, about 1,600 jobs, to throw more money into AI. Block (formerly Square) CEO Jack Dorsey recently announced he was cutting 4,000 jobs, almost 40% of the company’s staff, saying the intelligence tools we’re creating and using…”are enabling a new way of working which fundamentally changes what it means to build and run a company.” New? I think not. Businesses have been firing people to become more profitable since Ea-nāṣir of Ur let his copper quality assurance engineer go. What’s that — AI is different, you say? It really contributes to a business’s bottom line while maintaining high standards. But does it, really? Let’s check in over at Amazon to see how AI is working there. First, Amazon, like so many other companies, is laying people off left and right — 30,000 so far in the last six months. “This generation of AI is the most transformative technology we’ve seen since the Internet, and it’s enabling companies to innovate much faster than ever before,” wrote Beth Galetti, Amazon’s senior vice president of People Experience and Technology. This means Amazon could “be organized more leanly .” In plain English, that means they’re firing people. Amazon might yet regret that move. Multiple Amazon Web Services (AWS) and Amazon retail outages have prompted an internal crackdown on how generative AI (genAI) is allowed to touch production code. What’s’ that line about the horse and the barn door? It started in mid‑December, when an internal AWS AI coding agent called Kiro was allowed to make live changes to a customer‑facing cost management system . Kiro decided the best fix was to “delete and recreate the environment,” triggering a roughly 13‑hour outage that hit the AWS Cost Explorer service in parts of mainland China. Amazon has insisted the root cause was “user error” and misconfigured access controls. They argued that the same problem could have happened with any developer tool, not just AI. Internally, AWS characterized the disruption as “extremely limited,” stressing that core compute, storage, database, and AI services were not affected. That could be true. People have been making mistakes and writing sloppy code long before AI got into the programming mix. But (surprise!) the December failure wasn’t an isolated case. There have been at least two production outages in recent months, where Amazon AI coding tools can take some of the blame. Internally, those outages were described as “small but entirely foreseeable.” The root cause was that AI was effectively treated as an extension of a human operator and granted operator‑level permissions. That’s just stupid. You never give someone —or something — system administration privileges unless they absolutely need it and you completely trust them. Neither was true in this case. So, it was that this combination of high privileges and no supervision blew up. Amazon insists it was human error. Yes, it was. The error was humans putting too much trust in AI. This will only happen more and more often as we replace people who know what they’re doing with often clueless AI agents and bots. But, wait! There’s more. AI failures have spread beyond AWS infrastructure to Amazon’s retail storefront. In early March, multiple AI-assisted blunders resulted in four — count ’em four! — major incidents. One led to a six-hour outage. Amazon had had enough. Amazon Senior Vice President Dave Treadwell acknowledged that “GenAI tools supplement or accelerate production change instructions, leading to unsafe practices.”  Why? Amazon AI safeguards “are not yet fully established.” You know, maybe it’s just me, but before firing a ton of people, I’d make sure that 1) AI could do their jobs and 2) I had a way of ensuring that I could spot, track, and repair AI errors before things go awry. You know, safeguards. For now, Amazon has a new AI rule for the next 90 days: junior and mid-level engineers now need senior sign-off on any AI-assisted production changes. They’ll also be resetting their code practices and re‑emphasizing traditional safeguards. Engineers in the e‑commerce group have been told to attend normally optional weekly meetings focused on recent outages and new rules around generative‑AI‑driven deployments. Publicly, Amazon has pushed back against the narrative that AI agents themselves “caused” the outages. Instead, it has been reframing these failures as classic access-control and process failures. Company spokespeople have repeatedly said the incidents were user error and coincidence, stressing that they have “no evidence” that AI tools make mistakes more often than traditional software developers. Amazon’s top brass is missing the point. Of course, humans must take the blame. If Amazon executives had a clue, they might recall that back in 1979, an IBM training manual stated, “ A computer can never be held accountable , therefore a computer must never make a management decision.” Unfortunately, from the top down, Amazon is insisting that AI be used even when, as has become apparent, it doesn’t work that well. Amazon’s engineers know that. They’ve told The Guardian that they must use AI and “that we have to go faster , this will make us go faster, and that speed is the number one priority.” The result according to another Amazon employee is “This pressure to use [AI] has resulted in worse quality code, but also just more work for everyone.” How does the saying go? Oh yeah, “You can have two out of three: fast, cheap, or good.” For Amazon AI may be fast and cheap, but it’s failing to be good. To get true productivity out of AI, you need to double and triple check its work. This is a lesson that not only Amazon needs to learn, but all businesses suffering from the hallucination that AI is ready to replace programmers. It’s not. It’s that simple.