What happened
Amazon published an update from Terk Terkowitz, VP and Distinguished Engineer for Worldwide Amazon Stores, describing a revised role guideline for software development engineers (SDEs). The guideline was developed by Distinguished and Senior Principal Engineers across Amazon, drawing on observations of the company’s most successful SDEs. The public post presents the memo shared with SDEs and software development managers (SDMs), rather than a product launch or a new engineering tool.
The memo says Amazon’s leadership debated whether AI should be named explicitly in a role guideline that has historically avoided specifying technologies, even as cloud computing, microservices, and serverless systems changed engineering work. Its conclusion is that AI is changing software engineering more quickly and fundamentally, but that defining current best practices too tightly could make the guideline obsolete. Instead, the document emphasizes what leadership believes remains durable: impact on customers, businesses, and teams. The post calls the engineer who combines AI tools with human judgment and domain expertise a “Renaissance Developer.”
The memo advises engineers to learn and apply AI in daily work, while stating that neither the developer role nor a developer’s output is defined by AI use. It distinguishes long-term outcomes from input measures such as token usage or adoption of AI tools, and throughput measures such as code changes and reviews. Amazon calls those measures deeply flawed when used as targets: token-maximizing can conflict with frugality, while measuring lines of code can conflict with simplicity. The post also says these measures correlate with important outputs in some cases, and that teams adopting AI most effectively—called “frontier teams”—are seeing increased productivity and delivery. It provides no numerical size for those increases.
For leaders, the memo recommends examining the 10th and 90th percentiles of AI adoption. The stated purpose is to understand why some teams are not embracing AI effectively and whether teams with heavy use are seeing delivery increases to match. It also says that if current AI tooling does not benefit a particular kind of work, that is a finding rather than a failure: engineers should document why, share it with peers, and discuss solutions with managers. Leaders, meanwhile, should use the tools hands-on in production work, be able to identify tasks where they help and do not help, and balance experimentation with investment in approaches already working. The source announces no new software, access terms, prices, or rollout schedule.
What the archive adds
A prior channel discussion described engineering work as shifting toward orchestration, evaluation, and control as coding agents become more common. That provides context for Amazon’s emphasis on judgment and outcomes, but the updated role guideline is a new company-specific statement, not evidence that Amazon has adopted any particular external operating model. The archive’s related Field Notes on SageMaker and Bedrock cover separate Amazon products and cases, not this role guideline.
Trend signal
The memo supports AI-native organizations move toward review and orchestration: it frames engineering leadership as understanding work, judging where AI helps, and measuring delivery rather than simply counting activity. The source is a leadership statement, however, not evidence that review and orchestration have already replaced individual production across Amazon.
Why it matters
For a team introducing coding assistants or agents, the choice of success metric can shape behavior as much as the tool itself. If engineers are rewarded for tokens, adoption rates, or code volume, they may optimize those visible inputs whether or not they improve a customer outcome. Amazon’s warning gives leaders a reason to treat such figures as diagnostic signals, not standalone goals.
The percentile suggestion is also useful because an organization-wide average can hide opposite problems: teams that have not found a productive use and teams that have high adoption without matching delivery gains. Looking at both tails invites investigation rather than a uniform mandate. This is especially relevant where workflows differ and AI’s usefulness is uneven.
The memo does not resolve how to measure long-term outcomes or attribute changes to AI. It instead argues for hands-on understanding, careful judgment, and learning from concrete work. Teams can take that as a management principle without assuming Amazon’s internal practices or results will transfer unchanged to their own context.
Limits and uncertainty
The source describes Amazon leadership’s guideline and beliefs; it does not publish the guideline’s full text as a separate artifact in the supplied material, explain how performance reviews will change, or specify enforcement. It gives no headcount, adoption rate, cost data, productivity measurements, or comparison between AI-using and non-using teams. “Frontier teams” is not defined with a threshold, and the claimed correlation between input measures and outputs is not quantified. The memo explicitly acknowledges that best practices and metrics are still emerging. It therefore cannot establish that more AI use causes higher delivery, that the percentile approach is already in operation, or that the same measures will work for other organizations.
Reader takeaway
Amazon’s leadership is telling engineers and managers to learn AI, but not to confuse using it with delivering value. Adoption and throughput figures may help reveal where to investigate; they are poor substitutes for outcomes when turned into targets. For builders, the useful question is not how much AI activity a team can report, but where it demonstrably improves work—and where it does not.