Amazon's New Guidance on the Software Engineer's Role in the AI Era: What Changes for Developers
Amazon rewrote its SDE role guideline for AI: outcomes over tools, no token targets. What it says, what changes, and what it means for interviews.
Amazon has rewritten its official role guideline for software development engineers (SDEs), and the short version is this: AI is now expected at the centre of how Amazon builds software, but you will be judged on outcomes for customers, not on how much AI you use.
The update was published on Amazon's own news site, aboutamazon.com, as a note from engineering leadership introduced by Terk Terkowitz, VP and Distinguished Engineer for Worldwide Amazon Stores. It says Distinguished and Senior Principal Engineers revised the SDE role guideline because AI is changing engineering work faster than earlier shifts like cloud, microservices and serverless.
Below: what Amazon actually said, what changes for its developers, what it means if you are trying to get hired, and what it does not say.
What did Amazon say about the software engineer role and AI?
The post makes five points that matter.
1. Outcomes over tools. The line most people will quote: "what matters most is the outcome, not which tools are used." The guideline is deliberately built around impact on customers, the business and teams, because Amazon expects today's AI best practices to go stale quickly.
2. AI is not optional in direction, but it is not the definition of the job. Leadership writes that "neither the developer role nor their output is defined by the use of AI." In the same post it says: "We are certain that whatever future best practices are, AI will be at the center of software engineering practice."
3. Leaders must use AI hands-on. Managers and senior engineers are asked to learn AI by using it in real production work, so they understand where it helps and where it does not.
4. Careful with metrics. Input metrics such as token usage, tool adoption, and code changes and reviews can be used, but the memo warns they cause harm if treated as targets, for example higher costs or more complexity. Leaders are told to look at teams at the 10th and 90th percentiles of AI adoption and check whether heavy usage actually delivers more.
5. "Not a failing." Engineers whose work does not benefit from current AI tools are asked to write down why and share it. In Amazon's words: "If your work does not benefit from current AI tooling, that is a finding, not a failing."
The post closes on familiar Amazon ground: customer obsession and long-term results. Leadership says "it is best to measure, and be measured by, long-term outcomes."
Does the guideline mention Kiro or Amazon Q Developer?
No. The post does not name any product. It talks about "AI tools", "agentic AI" and agentic software development in general terms.
That matters because Amazon has separately pushed its own tools internally. Reuters reported on an internal memo directing engineers to standardise on Kiro, Amazon's agentic coding IDE, rather than adopt new outside AI coding tools (as covered by The Independent Singapore and People Matters). That is a different document. The new role guideline does not mandate any tool.
Before vs after: the Amazon SDE role, per the new guideline
This table is our reading of the guideline. The "before" column is the general state the memo describes moving away from, not a quoted older document.
| Area | Before (pre-AI framing) | After (per Amazon's guidance) |
|---|---|---|
| What defines the job | Writing, reviewing and shipping code | Outcomes for customers, business and team; AI "at the center" of how work gets done |
| Tools | Engineer's choice of standard stack | AI expected in daily work, but "the outcome, not which tools are used" is what counts |
| Leaders and senior ICs | Could manage without coding | Expected to use AI hands-on in production work |
| Metrics | Velocity, code output | Token use, adoption and code-change counts are inputs only; never targets |
| When AI doesn't help | Unspoken | Document it and share it: "a finding, not a failing" |
| Customer contact | Varies as teams grew | Stay close to customers and product direction to use AI better |
| How you're judged | Delivery and Leadership Principles | "Measured by long-term outcomes" |
What changes day to day for Amazon developers?
Reading the memo plainly, three things shift.
- You will be expected to know where AI fits in your work. Not just use it, but be able to explain where it saves time and where it does not.
- Activity dashboards should not drive your review. The memo explicitly warns against treating token counts or tool adoption as goals. If your manager does, you now have an official Amazon document to point to.
- Negative results count. If AI tooling doesn't help your codebase, writing that up is legitimate work, not an admission of falling behind.
Editor's opinion: This is a more careful memo than many feared. Plenty of companies have quietly turned "AI adoption" into a performance metric. Amazon's leadership wrote down that this can backfire. Whether every manager follows it is another question, and we will be watching what employees report.
Is this connected to Amazon's layoffs?
Not according to the post. It does not mention layoffs, headcount, hiring or interviews. We have not found Amazon or major press directly tying this guideline to job cuts, so we won't.
What is fair to say: it lands in a month when Amazon's workforce is under scrutiny. For the facts on cuts, see our Amazon layoffs October 2026 timeline. For investors, Amazon reports Q3 results on 29 October; our earnings preview and why the stock is down cover that side.
What does it mean for job seekers and Amazon interviews?
Amazon has not said its interview loop is changing. Our full guide to the Amazon and AWS hiring process and interview loop still applies: online assessment, coding, system design, and heavy Leadership Principles questions.
But the guideline tells you what Amazon values, and interviewers tend to probe what the company values. Reasonable inferences (ours, not Amazon's):
- Expect behavioural questions about how you used AI and what the result was, not whether you used it.
- A story where you decided AI was the wrong tool and explained why may land as well as a success story.
- Customer impact is still the frame. Tie every AI story to a customer or business outcome.
Skills to build now
Based on what the guideline rewards, here is our list for anyone working at, or aiming for, an Amazon SDE role anywhere in the world:
- Agentic coding workflows. Learn to drive an AI coding agent through a real change: spec, plan, review, test. Amazon's own Kiro is one example; the skill transfers.
- Reviewing AI-written code. Spotting subtle bugs, security gaps and needless complexity in code you didn't type.
- Measuring outcomes. Latency, cost, defect rates, customer metrics. Be able to show a before and after.
- Cost awareness. The memo flags higher costs as a risk. Know what model calls cost. Our guide to Claude Haiku 5.5 on Bedrock pricing is a practical start.
- Writing it down. Amazon runs on documents. Clear write-ups of what worked and what didn't are now explicitly valued.
- System design and fundamentals. AI changes how code gets written, not whether systems need to scale, stay secure, and respect rules like data residency.
- Customer understanding. The memo says staying close to customers helps you use AI better. Learn the product, not just the ticket.
What are Amazon engineers saying?
We looked for public reactions on Reddit (r/cscareerquestions, r/amazonemployees, r/aws) and in press reports of Blind posts. At the time of writing we have not found a verifiable public reaction to this specific guideline that we can quote and link, so we are not quoting anyone. We will update if that changes.
The bigger picture
Amazon is spending heavily on AI infrastructure, from its Anthropic partnership to custom chips (see TorchNeuron and Trainium) and power deals like the X-energy nuclear plan. The SDE guideline is the people side of that bet: AI everywhere, but judged by results.
FAQ
What is Amazon's new software engineer AI guideline?
A revised role guideline for SDEs, published by Amazon engineering leadership on aboutamazon.com. It puts AI at the centre of engineering practice but says engineers are judged on outcomes, not tool use.
Does Amazon require engineers to use AI?
The guideline expects AI to be central and asks leaders to use it hands-on, but says the role is not "defined by the use of AI." Engineers whose work isn't helped by AI should document why.
Will Amazon measure developers by AI usage or tokens?
The guideline says metrics like token usage and tool adoption can be inputs, but warns against treating them as targets.
Does the guideline mention Kiro or Q Developer?
No. It names no products. Separate reporting covered an internal push towards Kiro.
Is this guideline linked to Amazon layoffs?
The post does not mention layoffs, and we have not seen Amazon or major outlets link them.
Does this change the Amazon interview process?
Amazon has not said so. Expect interviewers to care about outcomes and judgement around AI, which fits the existing Leadership Principles.
Who wrote the update?
It is introduced by Terk Terkowitz, VP and Distinguished Engineer, Worldwide Amazon Stores, on behalf of engineering leadership including Distinguished and Senior Principal Engineers.
Does this apply outside the US?
The guideline is for Amazon's SDE role generally. The post does not limit it to any country.
Sources
- Amazon: An update from Amazon engineering leadership on the role of the developer in the age of AI
- The Independent Singapore (citing Reuters): Amazon directs its engineers to use Kiro over rival AI coding tools
- People Matters: Amazon memo reveals push for employees to use Kiro
Featured image: Amazon Day 1 tower, Seattle. Adamajreynolds, CC BY-SA 4.0, via Wikimedia Commons. Source
