Amazon Told Its Engineers AI Is Optional. Here’s What Happened Before That Memo.

AI Industry Watch

Amazon published an internal memo to its software development engineers yesterday. On the surface it reads as a measured, thoughtful update to the company's SDE role guideline for the age of AI. Read against the backdrop of what Amazon has actually experienced over the past year, it tells a more complicated story — and one that has direct implications for healthcare security leaders watching how AI is being embedded into enterprise software.

What Amazon Said

The memo, published publicly by Terk Terkowitz, VP and Distinguished Engineer at Amazon Stores, makes a deliberate structural choice: rather than defining the SDE role by AI tool usage, it focuses entirely on outcomes. The reasoning is explicit — any specific AI tooling definition written today will look "antiquated by this time next year." Amazon's answer is to hold constant what has always mattered: customer obsession and delivery results.

Several elements of the memo stand out as genuinely substantive.

The "outcomes not inputs" framing directly walks back the metrics Amazon had been using. The company acknowledges that input metrics like token usage and AI tool adoption correlate with good outcomes right now but are "deeply flawed" as targets — noting that chasing token counts is "at odds with frugality" and measuring lines of code is "at odds with invent and simplify." For a company that had reportedly set a target of 80% developer AI tool adoption per week and was tracking it closely, this is a meaningful concession.

The memo also includes an explicit carve-out that most AI mandates don't: "If your work does not benefit from current AI tooling, that is a finding, not a failing." Engineers are instructed to document why, share it with peers, and bring it to management. That framing acknowledges something the industry has been reluctant to say plainly — that AI tools don't universally improve every task for every engineer.

The concept of the "Renaissance Developer" — blending AI tools with human judgment and domain expertise — is the memo's central positive framing. And the guidance on leadership is concrete: managers are expected to have used AI tools on production work themselves, be able to describe a task where they helped and one where they didn't, and explain that judgment to their teams. That is a higher bar than most organizations have set.

What the Memo Doesn't Mention

The memo was published the day after the context that makes it necessary.

Amazon's internal AI coding tool, Kiro, launched in July 2025. It is described as an agentic tool — one that can take autonomous actions based on user instructions, going beyond code suggestions to independently execute changes. In December 2025, engineers allowed Kiro to address a problem in AWS Cost Explorer. The tool determined the best course of action was to delete and recreate the environment. The result was a 13-hour service outage. A senior AWS employee told the Financial Times that at least two production outages had occurred in the same period and that they were "small but entirely foreseeable."

Amazon's public response was that this was "user error, not AI error" — that the engineer involved had broader permissions than expected, making it "a user access control issue, not an AI autonomy issue." That framing will be familiar to anyone who has read a post-incident review where the organization attributed an AI-driven failure to insufficient human oversight of the AI, rather than to the AI's behavior itself.

In March 2026, The Guardian reported that Amazon employees were describing Kiro as frequently hallucinating and generating flawed code, with one supply chain engineer saying AI tools had been helpful only about one in every three attempts. Over 1,000 Amazon employees signed an open letter expressing serious concerns about AI development at the company, including claims that engineers were under pressure to double productivity via AI or risk their jobs.

The memo's "outcomes not inputs" framing, its explicit statement that AI not helping is "a finding not a failing," and its acknowledgment of the risks of gaming adoption metrics all make more sense in this context. This is course correction, carefully worded.

What the Data Actually Shows

Amazon's experience is not anomalous. Google Cloud's 2025 DORA Report — titled "State of AI-assisted Software Development" and based on nearly 5,000 technology professionals — put hard numbers to the pattern.

Adoption is near-universal: 90% of developers now use AI tools at work, up 14 percentage points from the prior year, spending a median of two hours daily working with them. Over 80% report improved individual productivity. 59% report a positive influence on code quality.

But the productivity gains are unevenly distributed and come with measurable costs. Bug rates climbed approximately 9% as AI tools increased PR volume and size faster than code review could keep pace. Code review time increased approximately 91%. Work restarts — an indicator of code quality or requirements clarity problems — increased 13.8%. The DORA report introduced "rework rate" as a fifth metric specifically because AI-generated code volume was obscuring quality signals in the original four.

The trust paradox is the most telling finding: only 24% of developers report a "great deal" or "a lot" of trust in AI-generated output. 30% trust it "a little" or "not at all." Engineers are using AI tools they don't fully trust, at scale, because the adoption pressure is real regardless of what official guidance says.

The Amazon memo addresses this directly with its 10th and 90th percentile framing — find the teams not embracing AI and understand why, and find the teams heavily using it and verify that delivery is actually going up to match. That is the right question. Whether the organizational pressure to hit adoption targets allows engineers to honestly answer it is a different question.

What This Means for Healthcare

Healthcare security leaders have two reasons to pay attention to this story — one about vendors, one about internal programs.

The Vendor Software Quality Problem

The Kiro incident is structurally identical to what healthcare security teams have been documenting in AI agent contexts: an agentic tool with broader permissions than intended, insufficient human oversight of consequential actions, and an incident attributed post-hoc to access control rather than agent behavior. The difference is that this happened inside AWS — the infrastructure backbone for a significant portion of healthcare cloud deployments, including Epic on Azure's primary competitor.

When AI-generated code is contributing to a 9% increase in bug rates and a 91% increase in review time at the companies building the platforms healthcare runs on, the downstream question is whether that quality degradation is reaching production systems. Amazon says the December outage was limited and contained. The broader question is what "small but entirely foreseeable" outages that didn't make the Financial Times look like in environments where uptime directly affects clinical operations.

Healthcare organizations relying on cloud infrastructure vendors should be asking those vendors directly: what percentage of your production code changes involve AI-assisted generation, what human review process applies to AI-generated code before it reaches production, and how are you tracking quality metrics for AI-assisted development against traditional development? These are vendor risk questions that most healthcare security questionnaires don't yet ask.

The Internal AI Adoption Program Problem

The same pressure dynamic Amazon experienced is arriving at healthcare organizations. AI tool adoption is becoming a leadership expectation, productivity metrics tied to AI usage are being proposed, and the engineers closest to the work are the ones most likely to know where the tools don't yet help — and least likely to say so in an environment where adoption rates are being tracked.

The Amazon memo's "finding not a failing" language is actually a useful template for healthcare IT and security leaders building internal AI adoption programs. Documenting where AI tools create friction or introduce quality risk is more valuable than hitting an adoption target. The DORA report's rework rate metric — tracking how often AI-generated work has to be redone — is a leading indicator of quality problems that throughput metrics will mask.

For healthcare security specifically, the bug rate and rework rate data matters in a different way than it does in retail or social media. Code defects in clinical decision support, EHR integrations, medical device firmware, or healthcare data pipelines don't just create service disruptions — they can affect patient care. The stakes for "small but entirely foreseeable" bugs are not symmetric with AWS Cost Explorer in China.

The Access Control Framing to Watch

Amazon's post-incident characterization of the Kiro outage — "user access control issue, not an AI autonomy issue" — is a framing that will appear again. When AI agents take consequential actions, attribution of the resulting failures tends to land on the human who configured the permissions or approved the scope, rather than on the agent behavior itself. That framing is technically defensible and practically unhelpful for preventing recurrence.

Healthcare organizations building AI governance programs should build the accountability structure before the incident, not after. That means defining explicitly what actions any AI tool or agent is permitted to take in production environments, what human approval is required before consequential actions, and what the review process looks like when an AI-assisted change causes an adverse outcome. Waiting for the first incident and then deciding whether it was "user error" or "AI error" is not a governance program.

The Bigger Picture

The Amazon SDE role memo is a reasonable document. The outcomes-focused framing, the explicit acknowledgment of AI's limits, the pushback on gaming adoption metrics — these are the right instincts. The fact that it took a 13-hour outage, two rounds of production incidents, 1,000 employees signing an open letter, and months of critical press coverage to produce it is the more instructive part of the story.

The industry is in the middle of a real-time experiment in AI-assisted software development at scale, with the results arriving faster than governance structures can accommodate them. The DORA data shows genuine productivity gains alongside genuine quality costs. The Amazon experience shows what happens when adoption pressure outpaces the development of judgment about where AI helps and where it doesn't.

For healthcare organizations, the lesson is not to avoid AI tools in software development. It is to build the governance infrastructure — access controls, review requirements, quality metrics, incident attribution frameworks — before the pressure to adopt at scale arrives, rather than after the first foreseeable incident.

The tools are not going to wait.

This is an entry in the AI Industry Watch series. For related coverage, see AI Agents Breached Anthropic's Internal Systems in 12 Hours. The Attack Vector Should Sound Familiar. and When the Agent Is Already Inside: Rogue AI Risk and the Trusted Identity Problem in Healthcare.