Amazon has put its position on AI and software engineering in writing: the job is defined by what an engineer delivers for customers, not by how much AI they use. In a memo shared with its engineers and published on Amazon's news site, a VP and Distinguished Engineer describes a revised role guideline for Software Development Engineers (SDEs), and admits that the usual ways of counting AI use, such as tokens and code changes, are "deeply flawed".
That candor is the interesting part. Most companies announcing AI-first engineering push adoption numbers. Amazon's memo pushes outcomes, then tells leaders to watch both ends of the adoption curve. Below is what it says, how it fits with other recent evidence on AI and developer work, and what a builder can take from it.
TL;DR: what the Amazon memo says
| Question | Short answer |
|---|---|
| Who wrote it? | Terk Terkowitz, VP and Distinguished Engineer, Worldwide Amazon Stores, with engineering leaders including Distinguished and Senior Principal Engineers |
| What changed? | A revised SDE role guideline that now addresses AI directly |
| Is AI use the definition of the job? | No. Neither the role nor an engineer's output is defined by AI use |
| Is AI optional? | Not really. Engineers should learn and apply it "as soon as possible", but a tool that does not help is "a finding, not a failing" |
| How is adoption measured? | Token usage, tool adoption, code changes and reviews, all called deeply flawed but usable with care |
| What should leaders do? | Use AI hands-on in production work and watch the 10th and 90th percentile teams |
| Layoffs announced? | No |
What does Amazon call the "Renaissance Developer"?
The memo describes the current era as that of the "Renaissance Developer": an engineer who blends AI tools with human judgment and domain expertise. The framing matters because it rejects both extremes. It does not say AI replaces the SDE, and it does not say AI is optional polish.
Amazon says its role guidelines avoided naming specific technologies through two decades of trends, including cloud, microservices and serverless. Leadership debated whether AI is different. The conclusion, according to the memo, is that AI changes software engineering faster and more fundamentally than those earlier shifts, so it had to be addressed. Even so, Amazon says it is early, and the guideline expects the role to keep evolving as AI's effect becomes clearer.
To keep the text from going stale, Amazon chose to describe what stays constant: impact on customers, the business and teams. It leans on Jeff Bezos's argument that "what's not going to change" matters more than what will, citing his 2012 interview with Werner Vogels and his 2016 letter to shareholders. The memo's closing line is that the constants remain an obsession with customers and a long-term focus on delivering results, and that the opportunity for software and software engineers "has never been larger".
Why does the memo call its own metrics "deeply flawed"?
Dashboard tiles showing the kind of input and throughput metrics Amazon says it tracks for AI use among engineers
The measurement section is the most practical part. Amazon says it uses two families of numbers:
- Input metrics: token usage and AI tool adoption.
- Throughput metrics: the number of code changes and reviews.
The memo then says both are deeply flawed because they are disconnected from what matters. Used as targets, they could drive bad outcomes. It names two direct conflicts with Amazon's own leadership principles: maximizing tokens clashes with frugality, and counting lines of code clashes with "invent and simplify".
Still, Amazon does not throw the numbers away. It says they correlate well with important outputs, so they can be used "with care and judgement". That is a restrained position, and it echoes a pattern we have tracked across other companies. When usage becomes a target, people optimize the usage, not the result. We saw the cost side of that in the Accenture report on capping central Claude funding and the output side in research on coding agents producing more code, not more software.
What is the 10th percentile and 90th percentile guidance?
Rather than ranking individuals, the memo tells leaders to look at the tails of the distribution:
- The 10th percentile: teams that are not embracing AI effectively. The question is why. It may be a tooling gap, a poor fit, or a lack of learning time.
- The 90th percentile: heavy AI users, which Amazon calls frontier teams. The question is whether delivery actually rises to match their usage.
The second check is the one most adoption dashboards skip. If a team burns far more tokens and ships no faster, the number is a cost, not a win. That is the same concern raised by the "verification tax" findings in our survey roundup: time spent checking and redoing AI output can eat the gain.
"A finding, not a failing"
A mechanical gripper handing a green bead to a human hand, a picture of AI output passing to human review
One sentence will be quoted often: if AI does not help an engineer's work, that is "a finding, not a failing". Engineers are told to document it, share it and bring it to a manager. For an employer that also says engineers must adopt AI quickly, this gives a safe channel for negative results. Whether it works that way in practice depends on how managers react, and the memo cannot answer that.
The memo also asks leaders to practice what they preach. They should use AI hands-on with production work and be able to name one task where it helped and one where it did not. It says leaders who double down on learning and curiosity have the most impact, with disproportionately large returns.
Finally, the memo says the engineers who get the most from AI and agentic development are those closest to customers and products. It wants individual contributors at every level, and software development managers, to reconnect with customers. In other words, AI is expected to raise the value of knowing what to build, not only how to build it.
How does this fit with Amazon's other AI moves?
Amazon's engineering culture has been in the news this year for reasons beyond tooling. Our July 2026 coverage of Amazon's AGI and Nova pretraining shake-up and layoffs covered the reorganization on the model side. This memo is a different layer: it addresses how the company expects its engineers to work day to day, not which models it trains. The memo does not mention layoffs, and we do not read job cuts into it.
Other employers are drawing the lines differently:
| Company | Public stance | Our coverage |
|---|---|---|
| Amazon | Role defined by customer impact, AI use is a means; metrics flawed but usable | This post |
| Ramp | Built a cloud coding agent and reported how much merged code it writes | Ramp Inspect launch |
| Microsoft | Large workforce changes alongside Copilot push | Microsoft buyout claim check |
| India IT services | Entry-level hiring pressure reported | India IT hiring claim check |
The contrast is useful. Ramp markets a measured share of merged code. Amazon explicitly warns against turning that kind of share into a goal.
What should a builder or team lead take from it?
You do not need to work at Amazon to use the framework. A few things to copy:
- Define the role by outcomes first. Write down what customers get from your team, then ask where AI shortens the path.
- Track inputs, but never target them. Token spend and tool adoption are diagnostic. If you reward them, you will get more of them.
- Look at both tails. Ask why the slowest adopters struggle, and whether the heaviest users really deliver more.
- Make negative results cheap to report. A team that hides "AI did not help here" will also hide the cases where it caused damage.
- Keep a review habit. Faster generation moves the bottleneck to review; see the Ask HN playbook on shipping AI-written code you do not understand.
If you want to build the skills behind this, our workshops cover agent-assisted development.
What the memo does not tell us
Be careful not to over-read a single internal guideline. The page (dated October 27, 2026) gives no list of the tools Amazon engineers use, no adoption figures, and no description of consequences for engineers who do not use AI. It does not say how the percentile checks feed into performance reviews. The Hacker News thread for the post had one comment and five points when we checked, so there is no meaningful outside reaction to cite yet.
It is also a guideline, not evidence. It states what Amazon believes and intends. It does not show that the approach improves delivery. Treat it as a statement of policy and watch for follow-up numbers or engineer accounts.
Bottom line
Amazon's memo is notable less for what it demands than for what it concedes: the numbers a company can easily count are poor proxies for good engineering, and a role should not be defined by a tool. The message to engineers is still urgent, learn AI now, but the message to managers is to measure results. That balance is likely to be copied, because it avoids both token-count theater and the claim that nothing has changed.
Details are accurate as of October 28, 2026, based on Amazon's published memo. We will update this post if Amazon adds figures or the guideline changes.
Related reading
- Accenture caps central Claude funding: what the report says
- AI coding agents make more code, not more software
- The AI verification tax: surveys and how to cut it
- Shipping AI-written code you do not understand
- Amazon AGI and Nova pretraining changes, July 2026
- Ramp Inspect cloud coding agent
- Amazon's memo on the SDE role (official) · Hacker News thread