An update from Amazon engineering leadership on the role of the developer in the age of AI

One of the biggest shifts our leadership teams are seeing right now is how AI is changing the way software development engineers (SDEs) do their work, while balancing that the important elements of being an SDE are the same.

Engineering leadership, including Distinguished and Senior Principal Engineers, from across Amazon recently came together to reaffirm what it means to be an SDE at Amazon. Based on key learnings and observations from the most successful SDEs at the company, they developed an updated role guideline.

Our most prolific engineers have demonstrated that neither the developer role nor their output is defined by the use of AI. We're now in the era of the Renaissance Developer, blending AI tools with human judgment and domain expertise to build entirely new things.

As a leader in agentic AI with thousands of SDEs, Amazon believes sharing our vision for the SDE role of the future can serve as a model for our customers. The following is a memo shared with software engineers across Amazon.

-Terk Dear SDEs and SDMs, As we developed the new version of the role guideline for Software Development Engineers (SDEs) at Amazon, we faced an important question: how much do we focus on AI?

Historically we have tried to avoid having the SDE role guidelines be explicit about technology, reflecting the diversity of businesses that Amazon is in, and the work that our SDEs do. We have held to that approach as two decades of technology trends (the cloud, microservices, serverless, etc.) have reshaped the work that SDEs do.

In the Senior Principal and Distinguished Engineer communities, we have deeply debated whether this time is different. AI is changing the work of software engineering both more quickly and more fundamentally than these previous trends. What it means to be a software engineer, and what software engineering even is, is changing quickly and durably.

Despite the speed of change, we believe that it is still early. We all need to embrace this change and take the time to learn, or we risk being left behind. We’re just seeing the beginning of AI’s effect on software engineering. While we have a vision for what the future looks like, there’s a lot that’s still emerging.

We are certain that whatever future best practices are, AI will be at the center of software engineering practice. If you haven’t already, you should take the time to learn and apply AI into your daily work as soon as possible. If you’re already using AI, keep investing in finding better practice, and keep learning. The pace of change is high.

It is difficult to define, in a way that will stand the test of time, what good AI powered engineering practices look like. Any definition we write now will likely look antiquated by this time next year. Antiquated definitions run the risk of slowing our progress, freezing our engineering practices in amber while the world moves on without us.

To solve this problem, we have decided to focus on what is not changing as we evolved the SDE roles. Specifically, impact on our customers, our businesses, and our teams. The outcomes that matter aren’t changing, even if the inputs, tools, and techniques are changing faster than ever. “What’s going to change in the next five to ten years?”

But I very rarely get asked “What’s not going to change in the next five to ten years?” That second question is actually the more important of the two.

Jeff Bezos 2012 interview with Werner Vogels This conclusion made it easier to write the role guideline, but likely leaves you, our SDEs and SDMs, with an important question about how you should be using AI, and how you should be measuring AI usage in your teams and organizations. We believe that it is best to measure, and be measured by, long-term outcomes.

But these outcomes can be time delayed, difficult to measure, and hard to isolate from other trends. In some cases, we have tackled those problems by using input metrics instead, like token usage or adoption of AI tools, or throughput metrics like code changes and reviews.

We are all aware of how deeply flawed these metrics are, primarily because they are disconnected from what matters.

We know that using these metrics could, if used as a target instead of a measure, drive negative outcomes, increasing costs (tokenmaxxing is at odds with frugality ), and increasing complexity (measuring LOC is at odds with invent and simplify ).

We believe that this community, with your strong ownership and focus on delivering results, will help us avoid these negative outcomes. More positively, we have found that these input metrics correlate well with the outputs that matter and expect they will continue to do so for some time.

This effect is driven both by increasing productivity and delivery on teams that have embraced AI the most (we call them frontier teams ), and that teams and individuals who are not adopting AI or increasing output metrics are falling behind. Using these input metrics, with care and judgement, as you think