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 about your career and your organization’s performance is appropriate. We recommend paying special attention to the 10th percentile (finding those teams who aren’t embracing AI effectively and understanding why) and the 90th percentile (finding those teams who are heavily using AI and understanding whether they’re seeing delivery increases to match) of AI adoption. Working together, over time, we will find better metrics and set smarter goals.

“Good inventors and designers deeply understand their customer. They spend tremendous energy developing that intuition. They study and understand many anecdotes rather than only the averages you’ll find on surveys.”

Jeff Bezos

2016 Letter to Shareholders

To paraphrase: Good leaders deeply understand their team's work. They spend tremendous energy developing that intuition. They study and understand many anecdotes, and carefully track outputs, rather than only surface-level metrics.

If your work does not benefit from current AI tooling, that is a finding, not a failing. Document why, share it with your community of peers, bring it to your manager, and work to find solutions. An engineer who can explain where AI does not yet help their work is demonstrating the judgement we are asking for.

As a technical or organizational leader, part of your job is making sure that your team or organization is using AI to the best effect to improve delivery for customers and your business. That requires deeply understanding these technologies yourself, working with them hands-on rather than relying on what you hear, and understanding how others are using them. Sufficient understanding means you have used these tools on your production work, can describe a task where they helped and a task where they did not, and can explain that judgement to your team. Deploying AI in your organizations requires carefully balancing between exploring new and better ways to do things and investing in doubling down on the ones you already have. Judgement and care are key. As a leader, we expect you to be taking ownership of connecting the inputs and outputs in your team or organization.

As we have looked across our organizations, we have found that the leaders who are having the most impact are those doubling down on learn and be curious. Both spending the time they need to learn AI and making time for the people they lead to do the same. We have seen that the returns on this investment in our organizations are disproportionately large, with teams who have followed their curiosity (appropriately balanced with deliver results and insist on the highest standards) seeing the most positive impact from AI adoption.

We have also found that SDEs and SDMs who are closer to their products and businesses are able to take the most advantage of AI and agentic software development. As Amazon has grown, we’ve seen some of our ICs and SDMs become less connected to their customers and business. We want to reverse this trend. We recommend that ICs of all levels find ways to become deeply connected to your customers, and your team or org’s product direction. As always, the scope and depth of this ownership will increase as you become more senior. For SDMs, we also recommend spending time making sure you’re close to your customers and business, and you’re helping the ICs in your organization to do the same.

This is a time of change for our industry, and a time of change for what it means to be a software engineer. We believe that the opportunity for software, and for software engineers, has never been larger. We’re more excited about the future of software development, and of our role as engineers, than ever before. Partnering with you as strong, curious, customer-obsessed owners, we will invent the future of software development together.

We will continue to evolve the SDE role over the coming years, as AI’s effect on our business and engineering practices becomes clear. But we believe that’s unlikely to change what really matters: obsession with our customers, and a long-term focus on delivering results.

¹_{Jeff Bezos, in a 2012}_{interview with Werner Vogels}
²_{Jeff Bezos, in the 2016}_{letter to Amazon shareholders}