Amazon’s AI coding troubles point to an industry-wide control problem

In case you missed it, here’s a condensed timeline of events for the Amazon controversy:

• July 2025: Amazon launched Kiro, an agentic AI-powered IDE, and reportedly set an internal goal of 80% weekly engineer usage.
• Mid-December 2025: A Kiro-assisted production change reportedly caused a 13-hour AWS Cost Explorer outage in mainland China after the tool deleted and recreated an environment.
• Late 2025: A separate incident involving Amazon Q Developer reportedly caused an internal service disruption under similar circumstances.
• February 20, 2026: The Financial Times published its investigation into the Kiro incident, and Amazon responded by calling it “user error” and misconfigured access controls rather than AI itself.
• March 5, 2026: Amazon’s retail website and shopping app were down for roughly six hours due to what the company described as an erroneous software code deployment.
• March 10, 2026: FT reporting indicated Amazon held a mandatory deep-dive review after four Sev-1 incidents in one week, with an internal briefing note (later deleted) linking “Gen-AI assisted changes” to a broader incident trend.

Amazon’s public position has been that these incidents reflect user error and misconfigured access controls rather than AI itself, though that response has been met with broad skepticism. But the real takeaways have nothing to do with the details of any single incident. 

The more important story is that software organizations are expanding their use of AI faster than the supervision and validation needed to keep that use in check. 

Code assistants are a part of that picture, but so are agentic workflows, automated change recommendations, and systems that can act with broad permissions inside development and production environments. The shared underlying problem is not the actual presence and use of AI – it’s that too many organizations are still overlooking validation in favor of deployment speed.

That approach was already weak before AI entered the picture. With AI now in the loop everywhere, it becomes even harder to defend and can be downright dangerous.

Faster software changes raise the cost of weak validation

The Amazon story matters – as do the reactions to it – because both reflect a wider industry trend. Teams are widely adopting AI to remove friction from software delivery only to discover that some of that friction was actually performing useful control functions. 

Code review slows people down, but it also catches bad assumptions. Narrow permissions may look inefficient when building, but they can limit the blast radius in production. Independent testing takes time and effort, but it tells you whether a change created a real problem in a live environment.

Once organizations start using AI to accelerate code generation, suggest fixes, create infrastructure changes, or act across systems, these controls matter even more. The question is no longer limited to whether an AI tool can produce insecure code. It is now whether the organization can validate the quality and effect of AI-influenced change across the full software lifecycle.

That full cycle includes not only functionality but also reliability, availability, and security. Any of those can break when validation is treated as an afterthought.

This isn’t only about coding assistants

One of the risks in this conversation is that “AI coding” becomes a convenient label for a broader set of control failures. If a development team relies on AI-generated code without meaningful review, that’s a validation problem. If an AI agent is given excessive permissions to modify systems or workflows, that’s a supervision problem. If teams trust automated outputs without confirming what is actually running in production, that’s an assurance problem. None of those are specific or exclusive to AI-generated code.

What’s more, all those failure modes are related and can easily cross categories. A functionality bug can become an availability issue. A reliability problem can create a security gap. An overpowered agent can make a poor recommendation, execute the wrong action, and do so at machine speed. None of that requires futuristic speculation – it just follows directly from runaway automation that gives excessive autonomy to systems while leaving oversight at pre-AI levels or lower.

That’s why the tech industry should resist the temptation to turn every story that mentions AI and software in the same sentence into another argument about whether AI is “good” or “bad” at writing code. That remains a valid issue to debate, but the more pressing question is whether organizations have built a strong enough validation layer around everything AI is being asked to do.

The industry is trying to automate judgment without proving outcomes

Many organizations are not just using AI to deliver code faster – they are doing so while compressing review capacity, stretching experienced teams, and still expecting the same or better outcomes.

When human oversight gets spread thinner at the exact same time as automation and AI autonomy get stronger, validation must become more precise to compensate, or something will break. 

It’s not enough to just say that people remain accountable for the final decision. Sure, that sounds sensible and responsible, but it often means little in practice if reviewers are overloaded, permissions are too broad, or testing cannot keep up with release velocity.

For software in particular, outcomes matter more than intentions. An instant code suggestion that introduces a defect is still a defect. An efficient AI-assisted workflow that contributes to an outage still affects availability. A fully automated change that exposes an application or API to attack still creates risk. If your outcome is a major global incident, there are no prizes for getting to that outcome more efficiently.

Again, this is why validation is key. Claims about improved productivity are easy to make. Claims about safety, resilience, and security require actual verification.

Security teams should keep the conversation anchored in runtime reality

While the Amazon story isn’t directly related to security, it does reinforce very practical security lessons for AppSec teams. As AI increases the pace and scale of change, security has to be closely tied to what applications and APIs actually do in operation. That means validating live behavior, confirming actual exposure, and prioritizing issues based on real impact rather than raw scan volumes.

This is especially important because AI-originated security failures can have many facets. Sure, AI might occasionally generate outright insecure code, but it can also greatly amplify ordinary operational mistakes. 

AI can recommend flawed changes that pass casual review but fail in production. It can help rapidly create functionality that works as intended for the business while exposing new attack paths. Finally, it can power agents and workflows that are highly effective and efficient – until they act outside the boundaries the organization thought it had set.

At AI-powered velocity, it’s often impossible to identify and cover every possible mode of failure in advance. This places a premium on always validating what is real, what is reachable, and what needs attention now.

That is where automated security testing and continuous verification have a clear role in the broader AI security discussion: not as a brake on innovation or compliance-mandated ballast on developer productivity, but as a way to keep software organizations honest about actual outcomes.

Final thoughts: The Amazon story is really a warning about control, not about AI use

Amazon makes an attractive target for “told you so” finger-pointing as one more example of AI hype colliding with operational reality, but the details of that story are less important than the core lesson to learn: This is what can happen when supervision and validation don’t keep pace with AI adoption. 

The problem is not confined to one company, one coding assistant, or one class of incident. It reflects a broader industry tendency to overly trust AI outputs, AI recommendations, and AI-driven actions before building enough discipline around how all those rapidly delivered outputs are reviewed, tested, and constrained.

As organizations push AI deeper and more pervasively into software creation and operations, validation has to move closer to the center of the process. This isn’t because AI is somehow inherently or uniquely dangerous but because its scale, speed, and autonomy can greatly magnify the consequences of otherwise ordinary control failures. When so much more of the software lifecycle is influenced by AI, the burden of proof has to rise accordingly.

Ultimately, this is a question of ensuring that software quality matches the AI-amplified release cadence. Companies that get this right might not make news for ensuring reliability, availability, and security, but they will be much more likely to stay out of the headlines about the latest breaches and outages.