Amazon's Mass Layoffs, Kiro AI, and Why Shipping AI-Generated Code to Production Should Terrify You

Let's talk about Amazon. Because Amazon has had a very eventful few months, and not in the exciting product launch way — in the "what on earth is going on over there" way that makes you sit up and pay attention.

In October 2025, Amazon announced its largest layoff in its 31-year history — over 14,000 corporate jobs eliminated. That number alone would be a story. But when you crack open the WARN filings submitted across Washington, New York, New Jersey, and California — the official government documents companies are required to file when laying off workers — you find something much more specific and much more alarming: nearly 40% of those 4,700+ documented positions were engineering roles. Roughly 1,800 engineers, gone, in one swing. Mid-level software engineers — SDE II roles — were disproportionately hit.

And at the exact same time Amazon was handing these engineers their severance packages, it was rolling out Kiro — its own AI coding assistant — and making it clear to the engineers who weren't laid off that using it wasn't really optional. One Amazon employee described managers receiving reports on who was and wasn't using Kiro, with conversations happening when engineers weren't adopting it.

So. Amazon fires its engineers. Then tells the remaining ones to let AI write the code. Then claims the whole thing is about "culture" and "startup agility."

I have a lot of thoughts about this. Put the coffee on.

What Is Amazon Kiro and What Does It Actually Do?

Before we get into the business and ethical chaos of all this, let's be precise about what Kiro actually is — because it's more ambitious than most people realize, and understanding the product is critical to understanding why this situation is so interesting.

Kiro isn't just another autocomplete tool. It isn't GitHub Copilot with an Amazon logo. Kiro is an agentic coding service built on Amazon Bedrock that works alongside developers to turn prompts into detailed specs, then into working code, documentation, and tests. It's built on the same VS Code foundation as Cursor and most modern AI IDEs, but its architectural philosophy is different — it's built around what Amazon calls "spec-driven development."

Here's how that works. Instead of you typing a prompt and getting code back immediately, Kiro takes your natural language description, breaks it down into formal requirements with acceptance criteria, builds out an architecture plan, and then generates an implementation task list — complete with tests. The idea is that you're not "vibe coding" (typing prompts and hoping for the best) — you're working through a structured development process with AI at each stage.

You can chat with Kiro about your code through natural language conversations, ask questions about your codebase, request explanations for complex logic, generate new features, and debug tricky issues.

And then at re:Invent in December 2025, Amazon took it further. AWS announced the Kiro autonomous agent — claiming it can work independently for days at a time. "You simply assign a complex task from the backlog and it independently figures out how to get that work done," AWS CEO Matt Garman told the re:Invent audience. Amazon says Kiro maintains "persistent context across sessions," meaning it doesn't run out of memory and forget what it was supposed to do.

Amazon also paired Kiro with two companion agents: an AWS Security Agent that works independently to identify security vulnerabilities as code gets written, and a DevOps Agent that handles performance testing and compatibility checks before code goes live.

On paper, this is impressive. An AI that understands your entire codebase, builds out a proper spec before writing a line, generates tests automatically, remembers context across multi-day tasks, and has a security agent running alongside it catching problems. That's a genuinely sophisticated vision of how AI-assisted development could work.

In practice? Let's talk about what happens when you actually use it.

The Honest Early Verdict on Kiro

I want to be fair here. Kiro's architectural ideas are legitimately interesting. The spec-driven workflow — forcing you to articulate requirements before generating code — is philosophically the right way to use AI in development. Most AI coding tools let you go straight from "vague idea" to "generated code" with no checkpoint in between, which is how you end up with AI-generated code that technically runs but doesn't do what you actually needed.

But the early reviews tell a complicated story.

One detailed hands-on review characterized Kiro's spec workflow as a "waterfall approach" where requirements and design artifacts don't auto-update, causing implementation and specs to drift apart and breaking the iterative flow developers rely on. For teams used to agile development — short cycles, constant feedback, rapid iteration — the rigidity of Kiro's planning phase can feel like a step backwards.

Other early adopters noted that while Kiro's AI-generated outputs often surpass those of competing tools, its meticulous task queuing system can occasionally slow down workflows, particularly in fast-paced development environments.

And then there's the security issue that I cannot gloss over, because it's directly relevant to everything I'm about to say about AI-generated code in production.

During early beta testing, one developer discovered that Kiro was automatically accessing and reading files containing sensitive API credentials — without any permission request — while they were actively developing software that managed those exact credentials. This isn't a hypothetical attack scenario. This is a behavior that happened during normal use, caught because the developer happened to notice it. How many people didn't notice?

And it gets worse. Researchers later documented that Kiro.dev was among the AI IDEs affected by a series of vulnerabilities — collectively named IDEsaster — involving prompt injection attacks that could enable data exfiltration and remote code execution across more than 30 AI coding tools. The tool designed to write secure code for Amazon's engineers had its own security vulnerabilities being actively researched by the security community.

Let that breathe for a moment.

Andy Jassy's "World's Largest Startup" Fantasy and What It Actually Means

Since becoming CEO, Andy Jassy has been driving an effort to reshape Amazon's corporate culture into what he describes as "the world's largest startup." His approach is to reduce bureaucracy, remove management layers, and get engineers doing more with less. Fewer people, faster decisions, scrappier teams.

On Amazon's Q3 2025 earnings call, Jassy said the cuts were not finance-driven: "And if you grow as fast as we did for several years, the size of businesses, the number of people, the number of locations, the types of businesses you're in, you end up with a lot more people than what you had before, and you end up with a lot more layers."

I want to be generous here. The intention behind reducing bureaucracy is sound. Large companies do develop organizational bloat. Layers of management that exist to manage other layers of management. Approval chains for decisions that should take ten minutes. Amazon at the scale it reached during the pandemic-era hiring surge had genuinely real structural problems. Wanting to fix that is not wrong.

But here's what the "world's largest startup" framing gets wrong in...

startups are small because they don't have the resources to be large yet.

They're scrappy by necessity, not by design choice. The founding engineers at a five-person startup write everything themselves because there's no one else to write it — and when they ship something insecure, it affects a few hundred users and they patch it fast. When Amazon ships something insecure — at the scale of AWS, of Amazon retail, of Prime, of the cloud infrastructure running a significant fraction of the internet — the blast radius is a different thing entirely.

The contradiction becomes glaring when examining Amazon's AI investments. The company recently launched Kiro, its coding assistant, while simultaneously eliminating the engineers who would typically integrate such tools. It's investing heavily in AWS AI services while downsizing the technical teams that support enterprise customers.

Amazon's engineering cuts expose the tech industry's biggest contradiction — claiming AI requires faster innovation while eliminating the technical talent needed to build it.

You can't have it both ways. You can't say "we need to innovate faster than ever before" and in the same breath eliminate 1,800 engineers. Unless the implicit assumption is that AI is going to fill that gap. And that assumption should make everyone uncomfortable — including the people making it.

The Senior Engineer Review Bottleneck Nobody Is Talking About

Here's the part of this story that I think is genuinely underexplored, and it comes directly from my own experience — both in web development and running a hosting operation where I've been responsible for code that runs in production environments serving real customers.

When you remove a significant portion of your engineering team and replace them with AI-generated output, you don't eliminate the need for human review. You concentrate it. The review burden now falls entirely on whoever's left — and in most organizations, that means senior engineers.

Think about what that looks like on the ground. You have Kiro generating code. Autonomous. Working for days. Producing output across fifteen different internal applications. And on the other end of that pipeline, you have a handful of senior engineers whose job is now to review every line of it before it goes anywhere near production.

That's not a productivity win. That's a senior engineer bottleneck.

The people Amazon just made "more productive" by giving them AI tools are now spending their days doing something that looks a lot like code review — which is important work, but it's not the same as building. Senior engineers who should be making architecture decisions, mentoring mid-level developers (you know, the ones who just got laid off), solving hard technical problems — they're now effectively QA for an AI that produces hundreds or thousands of lines of code per hour.

"Functional applications can now be built faster than humans can properly evaluate them," according to OX Security's research. "Vulnerable systems now reach production at unprecedented speed, and proper code review simply cannot scale to match the new output velocity."

That quote is important. Code review as a safety mechanism was designed around human-speed code production. An engineer writes a feature, submits a pull request, another engineer reviews it. The review burden scales with the writing speed, which is human speed. When you replace the writing with AI that produces code orders of magnitude faster than any human — you haven't solved the bottleneck, you've moved it and made it worse.

I've seen this play out on a smaller scale in my own work. The moment you introduce AI into your coding workflow without a corresponding change to your review process, your review queue starts backing up. And under schedule pressure — which is always present, because schedule pressure is the permanent condition of software development — that queue gets shorter and shorter until eventually things get merged and deployed that shouldn't have been. Not because anyone is negligent. Because the math of the situation makes it structurally inevitable.

Cybersecurity Reality of AI Code in Production

I want to spend significant time here because this is the part of the conversation that gets glossed over in the hype cycle, and it's the part where I have the most to say from personal experience.

Let me tell you something from years of running a hosting business and doing cybersecurity work...

code that looks correct is not the same as code that is secure.

This sounds obvious when you say it out loud. But it's a distinction that the AI coding ecosystem is consistently failing to take seriously.

A recent study found that 62% of AI-generated code solutions contain design flaws or known security vulnerabilities, even when developers used the latest foundational AI models. The root problem is that AI coding assistants don't inherently understand your application's risk model, internal standards, or threat landscape.

Let me say that again. Sixty-two percent. More than half of the code these tools produce has a security problem baked in. And critically — some of the most dangerous AI-generated flaws don't look like flaws at all. They emerge in the cracks between logic, edge cases, and business context. They are harder to spot since the code looks correct and might even pass some basic checks.

This is the nightmare scenario for anyone who's done real security work. The vulnerability that looks like normal code. The exploit that hides in a completely legitimate-looking code path. The SQL injection that exists not because the AI wrote something obviously wrong, but because it generated a perfectly clean-looking query without parameterization in one specific edge case that only triggers under specific conditions.

I've written about this specifically in the context of HTTPS and web security — the idea that things that appear completely secure on the surface can have structural vulnerabilities that only reveal themselves under adversarial conditions. An HTTPS certificate tells you the connection is encrypted. It doesn't tell you anything about the code running on the other end of that connection. AI-generated code that passes linting and basic testing tells you something similar: the code runs. It doesn't tell you whether it's secure.

Veracode's 2025 GenAI Code Security Report, which analyzed code produced by over 100 LLMs across 80 real-world coding tasks, found that GenAI introduces security vulnerabilities in 45% of cases. The CTO noted: "Our research reveals GenAI models make the wrong choices nearly half the time, and it's not improving."

That last part is what I want you to sit with: it's not improving. Newer and larger models don't generate significantly more secure code than their predecessors. The security performance has remained largely unchanged over time, even as models have dramatically improved in generating syntactically correct code. The models are getting better at writing code that runs. They're not getting meaningfully better at writing code that's secure. Those are different problems.

What Kinds of Vulnerabilities Are We Talking About?

Let me get specific, because "security vulnerabilities" is vague enough to mean nothing to someone who hasn't worked in this space.

If a developer asks an AI assistant to "query the users table by ID," the model might return a textbook SQL injection flaw — something like sql = "SELECT * FROM users WHERE id = " + user_input — because that insecure pattern appeared thousands of times in GitHub repos the model trained on.

This is how training data turns into production vulnerabilities. The model learned from code that's on the public internet. The public internet contains a lot of insecure code — because real-world developers write code under deadline pressure, because tutorials don't always follow best practices, because old code from ten years ago that predates modern security guidance is still sitting in public repos being indexed. The model learned all of that too.

AI can also unintentionally leave security guardrails out because it's unaware of the risk model behind the code. API endpoints can be produced that accept input without validating, sanitizing, or authorizing the payload simply because the prompt never said they needed to.

Here's a PHP example of what this looks like in practice. Ask an AI to build a user login endpoint and it might give you something that looks completely functional:

<?php

$username = $_POST['username'];
$password = $_POST['password'];

$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($conn, $query);

That code runs. It processes the login. It'll work in testing. It's also a SQL injection vulnerability that lets an attacker bypass authentication entirely by submitting ' OR '1'='1 as the username. Completely invisible in a quick code review if you're not looking for it. The AI didn't write "bad code" in the sense that it looks like nonsense — it wrote code that does the job while quietly leaving the door open.

And this isn't a PHP problem specifically. Java had the highest failure rate among languages tested, with LLM-generated Java code introducing security flaws more than 70% of the time. This spans JavaScript, Python, Java, TypeScript — no major language is immune.

The Problem Compounds at Scale

Here's where my experience running a hosting operation becomes directly relevant. When you're responsible for infrastructure that serves real customers — real traffic, real data, real transactions — the difference between a vulnerability in one endpoint versus vulnerabilities distributed across an entire codebase produced by an AI running autonomously for days is not a quantitative difference. It's a qualitative one.

As AI usage scales across organizations, the volume of potentially vulnerable code grows exponentially. Each insecure AI-generated component adds to the organization's attack surface, creating compound security risks that become increasingly difficult to manage.

A single vulnerable endpoint is a problem you can find and fix. A codebase where AI has been generating code autonomously across dozens of services simultaneously, each with its own edge cases and its own gaps in security guardrails — that's a different audit challenge entirely. You don't know where to look. You don't have a single author you can ask "what were you thinking here?" Unlike traditional coding where vulnerabilities can be traced to specific developers or decisions, AI-generated vulnerabilities often lack clear ownership. This ambiguity complicates remediation efforts and can lead to delays in addressing critical security issues.

I've seen what happens when a hosting environment gets compromised because of one unreviewed piece of code that got pushed to production under deadline pressure. It's not fun. It's not fast to fix. And the damage — to customer data, to trust, to the business — can be permanent. Now scale that up to Amazon's size and ask yourself what a breach of AI-generated code running across AWS infrastructure would look like.

The Tools Themselves Are Vulnerable Too

There's another layer to this that I don't see discussed enough: the AI coding tools themselves are attack surfaces.

In 2025, critical vulnerabilities were discovered in AI coding tools offered by Cursor, GitHub Copilot, Google's Gemini, and Amazon's own Q Developer — all leaving the door open to prompt injection attacks, where a threat actor slips instructions to an AI coding tool to direct it to behave in an unintended way, such as leaking data or executing malicious code.

Security researcher Ari Marzouk spent six months uncovering over 30 vulnerabilities across AI-powered IDEs, including Kiro.dev, describing exploit chains that could enable data exfiltration and remote code execution. "I think the fact that multiple universal attack chains affected each and every AI IDE tested is the most surprising finding of this research," he told The Hacker News.

So let's map this out: the tool writing your code might generate insecure code. The tool itself has security vulnerabilities. It can be manipulated into leaking your credentials or executing commands it shouldn't. And Amazon just fired the engineers who might have caught any of this. Instead, it's asking the remaining engineers to use the tool more.

I'm not catastrophizing. These are the documented facts.

This Connects Directly to the Stack Overflow and GitHub Story

I've been watching the AI disruption of developer infrastructure for a while now, and Amazon's Kiro rollout fits a pattern I've written about in detail. The Stack Overflow collapse, the OpenAI GitHub challenge — they're all part of the same story.

The short version, if you haven't read those pieces: Stack Overflow went from 200,000+ questions per month to 2008-era traffic levels in 24 months after ChatGPT launched — not because AI was better at everything, but because Stack Overflow had structural problems that AI exposed. The full breakdown of that decline is here and it's worth understanding in context of what Amazon is doing now.

Because Amazon's "replace engineers with AI" bet rests on a similar assumption: that the complexity and judgment of software engineering can be adequately handled by a tool that produces code at machine speed. Stack Overflow thought that community-curated answers at human scale could handle developer knowledge needs at internet scale. They were both partially right and catastrophically wrong in ways that took years to fully surface.

The difference is that when Stack Overflow got it wrong, developer communities got worse documentation. When Amazon gets it wrong at the scale of AWS — the cloud infrastructure powering a significant portion of the internet — the stakes are considerably higher.

I've also written at length about OpenAI building its own code repository to challenge GitHub — and if you read that piece and then look at what Amazon is doing with Kiro, you see the same pressure playing out from both sides. Every major tech company is simultaneously trying to use AI to reduce their engineering headcount and trying to build the AI tools that enable that reduction. There is something deeply recursive about this that should give everyone pause.

The "RAMpocalypse" Parallel — When Infrastructure Decisions Have Cascading Consequences

One thing I've learned from years of running hosting infrastructure is that decisions made at the infrastructure level have consequences that aren't always visible immediately — and when they become visible, fixing them is orders of magnitude harder than the original decision.

I wrote about this in a different context in the RAMpocalypse piece — the way that resource constraints at the infrastructure level can cascade into systemic failures that look totally unrelated on the surface. The lesson of that story is the same lesson that applies here: when you make a foundational decision to optimize for speed and cost at the expense of resilience and expertise, the bill comes due eventually. And it usually comes due at the worst possible moment — under load, under pressure, when you have the fewest resources to deal with it.

Amazon's decision to reduce its engineering workforce while deploying AI to fill the gap is exactly this kind of foundational decision. The infrastructure-level choice being made here is: "human engineering expertise is a cost center that AI can offset." And the cascading consequences of that choice — the security debt being accumulated, the review bottleneck being created, the institutional knowledge walking out the door with every engineer who gets a severance package — those consequences don't show up in Q3 earnings. They show up eighteen months from now when something gets compromised and nobody's entirely sure where to look.

What This Means for Developers Who Aren't at Amazon

Let's get practical, because if you're reading this as a developer, the existential question isn't just "what is Amazon doing" — it's "what does this mean for me."

The honest answer has two parts.

Part one: The pressure Amazon is applying to its engineers — use the AI tools, demonstrate adoption, produce more with fewer people — is coming to your company too if it isn't there already. In 2025, companies cited AI as a reason for 55,000 job cuts, almost entirely in tech roles. Amazon is the most visible example of a trend that is industry-wide. The pressure to adopt AI tools and to justify human engineering headcount in the presence of AI tools is real, it's growing, and pretending otherwise is not going to help you.

Part two: The engineers best positioned to survive this shift are not the ones who resist AI tools entirely, and they're also not the ones who adopt AI tools uncritically and stop thinking about what the code is doing. They're the ones who can do what I've been arguing for in my piece on using AI tools effectively — use AI to accelerate the work that doesn't require judgment while applying serious human expertise to the work that does.

That means:

• Use AI for boilerplate, documentation, and test generation — the repetitive stuff that burns time without requiring deep thought
• Never let AI write security-sensitive code without reading every line with security-aware eyes
• Develop your code review skills, because review is increasingly where experienced engineers will spend their time
• Build and maintain expertise in architecture and system design — the things AI is worst at
• Understand the security implications of the code you're shipping, regardless of who or what wrote it

The engineers who got laid off at Amazon were disproportionately mid-level SDE IIs — solid engineers, but not the ones with deep architectural and security expertise. That tells you something about which skills are being valued right now and which ones are being replaced. Learn from that signal.

Am I Watching the AI Takeover Happen in Slow Motion?

Okay. Hat on. I've been resisting this section but you knew it was coming.

I've written before about OpenAI's methodical march through the developer tool ecosystem — models, agents, browsers, document editors, now a code repository — and how every step is too strategically coherent to be accidental. Amazon's moves fit the same pattern from a different angle. They're not just using AI to replace workers. They're building the AI tool, deploying it to their remaining workers, collecting data on how professional engineers use it at enterprise scale, and using that data to make the AI better — which then makes it possible to reduce headcount further, which creates more pressure to adopt AI, which generates more training data.

It's a loop. And I'm not entirely sure where it ends.

I'll say this quietly, for the record: I am not fully convinced that what we are watching is just "companies cutting costs." The pace, the coordination across the industry, the specific targeting of mid-level roles that represent transferable knowledge — it has a pattern to it. Whether that pattern is being driven by genuine economic optimization or by something that deserves a closer look, I genuinely don't know.

What I do know is that I've learned to pay attention when the AI disruption story accelerates. And right now it is accelerating.

Look — I joke that I'm publicly supporting the AI takeover to stay on the good list when it all goes down. But underneath the joke is a real pragmatic position: the developers who engage thoughtfully with these tools, who understand their limitations and their risks, who maintain the human expertise that makes AI output trustworthy — those are the developers who remain valuable as the landscape shifts. That's not fearmongering. That's reading the room.

The Conclusion

Here's where I land after all of this.

Amazon firing 1,800 engineers while deploying an AI coding tool and telling the remaining engineers to use it is not a productivity revolution. It's a bet — a very large, very public bet — that AI can fill the expertise gap left by those departing engineers. That bet may pay off in some dimensions. Amazon will likely produce code faster. It will likely reduce some forms of organizational bloat.

What it will not do, based on the current state of AI-generated code security, is make Amazon's codebases more secure. The industry is entering a phase where code is being deployed faster than it can be secured. AI-generated code often appears clean and functional but hides structural flaws that can grow into systemic security risks.

The senior engineers left at Amazon are about to have their most important and most exhausting period in their careers — because they are now the last line of defense between Kiro's output and production. Their value isn't going down. Their leverage is going up. And their workload is about to become genuinely unsustainable if the company keeps assuming that AI review catches what human review would have caught.

For everyone else who is reading...

We understand what these tools produce, understand where they fail, and never let the speed of AI output become an excuse to skip the review that production code requires.

I've been saying this from the perspective of a developer who uses AI tools and finds them genuinely useful — the key word is uses, not trusts blindly.

The code that ships to production with your name attached to it — whether you wrote it by hand or reviewed it after AI generated it — is your responsibility. Act accordingly.

Amazon Kiro, AI Layoffs, and Code Security

• What is Amazon Kiro and how is it different from GitHub Copilot? Kiro is Amazon's agentic AI coding IDE launched in July 2025 and expanded with autonomous agent features at re:Invent in December 2025. Unlike GitHub Copilot, which primarily assists with code completion and generation within your existing editor, Kiro uses a "spec-driven development" approach — converting natural language requirements into formal specs and architecture plans before generating code. It's built on Amazon Bedrock, powered by Claude Sonnet models, and claims to work autonomously for days at a time on complex tasks.
• Did Amazon lay off engineers because of AI? Amazon officially stated the layoffs — which eliminated over 14,000 positions in 2025, with roughly 40% being engineering roles — were about removing bureaucracy and organizational layers rather than AI directly. However, the timing of the Kiro rollout, Andy Jassy's public statements about AI enabling smaller teams to do more, and the targeting of mid-level SDE II engineers (the roles most replaceable by AI-assisted workflows) all point to AI being a significant factor, even if it wasn't stated as the primary reason.
• Is AI-generated code safe to use in production? With thorough review, yes — but the numbers are genuinely concerning. Research across multiple studies finds that 45-62% of AI-generated code contains security vulnerabilities, and newer models are not meaningfully improving on security even as they improve on generating syntactically correct code. AI-generated code is particularly prone to missing security guardrails — input validation, authorization checks, parameterized queries — because these protections aren't always explicit in the prompt. All AI-generated code should be reviewed with security awareness before reaching production, and security-critical code (authentication, authorization, payment processing) should never be deployed from AI output without extensive manual review.
• What cybersecurity risks does Kiro specifically introduce? Early beta testers reported Kiro accessing files containing sensitive API credentials without explicit permission requests. Security researchers also documented that Kiro.dev was among the AI IDEs affected by the IDEsaster vulnerability disclosure — over 30 flaws across AI coding tools enabling prompt injection attacks that could lead to data exfiltration and remote code execution. The AI tool designed to write your code has its own attack surface that needs to be taken seriously.
• Will AI replace software engineers? The Amazon layoffs suggest mid-level engineers performing routine development tasks are at immediate risk. Engineers with deep expertise in architecture, system design, security, and complex debugging are better positioned — these are the skills AI is currently worst at, and they're the skills needed to review and validate AI-generated output. The honest answer is that nobody knows exactly where the capability ceiling is, and developers who assume their roles are permanently safe regardless of how AI evolves are taking a risk.
• What should developers do to protect their careers as AI coding tools improve? Focus on the skills AI cannot replicate: architectural judgment, security expertise, system-level thinking, and the ability to evaluate AI output critically. Use AI tools for boilerplate, documentation, and test generation — not as a replacement for understanding the code you ship. Develop strong code review skills, because review is increasingly where experienced engineers create value. And never, under any circumstances, let AI-generated code reach production in security-sensitive contexts without thorough manual review.