（来源：清晨领导力）
10月27日，亚马逊官网发布关于开发工程师的新要求《An update from Amazon engineering leadership on the role of the developer in the age of AI》。（文末有链接和全文）
文章由亚马逊副总裁、杰出工程师Terk Terkowitz署名发布。
亚马逊多个业务部门的技术领导者共同参与更新了软件开发工程师（SDE）的岗位准则，并公开了一封面向内部工程师及软件开发经理（SDM）的信。
这封信既讨论了AI如何改变工程师的工作，也对技术管理者提出了明确要求，包括亲自使用AI、重新审视AI绩效指标、推动团队学习，以及让工程师更加贴近客户和业务。
虽然此次更新并非修改亚马逊原有的Leadership Principles（领导力原则），核心主要是针对软件开发人员，但从中能够看到，AI时代对人才与管理者的要求正在发生哪些变化。
一、AI技术变化越快，越要明确什么是不变的
亚马逊首先提出一个问题：新的工程师岗位准则，应该在多大程度上强调AI？
过去20年，云计算、微服务和Serverless等技术不断改变软件开发方式，但亚马逊一直避免把具体技术要求直接写入岗位标准。
但这一次，亚马逊认为AI带来的变化更加深刻。
AI is changing the work of software engineering both more quickly and more fundamentally than these previous trends.
亚马逊认为，AI正在比过去的技术浪潮更快、更深刻地改变软件工程。未来，AI将处于软件工程实践的中心，所有工程师都需要积极学习并应用AI。
但另一个问题也随之出现：今天制定的AI实践标准，很可能明年就过时。
于是，亚马逊决定将岗位准则聚焦于长期不变的结果。
The outcomes that matter aren’t changing, even if the inputs, tools, and techniques are changing faster than ever.
具体来说，就是工程师对客户、业务和团队产生的影响不会变。
这里还引用了贝佐斯2012年的一个经典观点：相比讨论未来五到十年什么会发生变化，更应该关注什么不会变化。
这个思路对企业AI转型很有启发。当前很多企业正在强调AI工具使用率、员工使用频次等指标，但随着AI成为日常生产力，更重要的问题会逐渐变成：员工借助AI究竟创造了多少价值，是否改善了业务交付和客户体验？
AI工具使用能力会越来越普遍，能否利用AI创造业务价值，将进一步拉开人才之间的差距。
二、重新审视AI绩效：Token用得多，不等于价值创造得多
这封信中最有现实意义的部分，是亚马逊对AI使用指标的反思。
过去，亚马逊也使用过Token消耗量、AI工具采用率、代码修改量和审查量等指标，衡量工程师和团队的AI使用情况。
但亚马逊明确指出：
We are all aware of how deeply flawed these metrics are, primarily because they are disconnected from what matters.
这些指标存在明显缺陷，因为它们与最终需要创造的价值之间存在距离。
例如，为了追求Token使用量而增加不必要的AI调用，会推高成本；为了增加代码行数而生成更多代码，可能反而增加系统复杂性。
这也与亚马逊长期强调的Frugality（节俭）和Invent and Simplify（创新与简化）原则相冲突。
不过，亚马逊并未因此否定AI使用指标。根据内部观察，AI使用程度与业务产出之间仍存在较好的相关关系。积极拥抱AI的Frontier Teams（前沿团队），在生产效率和交付方面表现出更积极的变化。
因此，亚马逊建议管理者特别关注两个群体：
AI采用率处于第10百分位附近的团队： 为什么没有有效使用AI？是能力不足、工具不合适，还是工作场景存在限制？
AI采用率处于第90百分位附近的团队： 大量使用AI之后，是否真的产生了相匹配的交付改善？
有意思的是，亚马逊在这里还引用了贝佐斯2016年致股东信中的一段话：
贝佐斯认为，优秀的创新者和设计者需要深入理解客户，研究大量具体案例，而不能只依赖调查中的平均数据。
这也解释了为什么亚马逊建议管理者同时关注AI使用率最低和最高的团队。数据可以帮助发现问题，但要理解背后的原因，仍然需要管理者深入业务和团队。这点也跟字节在7月底发布的新领导力原则中“深入一线”的导向是一致的。
三、让工程师重新靠近客户和业务
公开信中还谈到一个值得组织管理者关注的问题。
亚马逊发现，那些更贴近产品和业务的工程师与软件开发经理，往往能够更有效地利用AI和Agentic Software Development（智能体式软件开发）。
但随着组织规模扩大，一部分工程师和管理者逐渐远离客户和业务。
We want to reverse this trend.
亚马逊希望扭转这种情况，鼓励各级工程师深入理解客户需求和产品方向，并要求管理者帮助团队建立更紧密的业务联系。
这一变化也与亚马逊提出的Renaissance Developer（复兴型开发者）理念相呼应。
随着AI越来越擅长代码生成、测试等执行性工作，工程师能够投入更多精力理解业务问题、设计解决方案，以及判断最终结果。
未来，更有价值的工程师可能需要同时具备技术能力、AI应用能力、业务理解和专业判断。
从组织角度看，这也为企业探索更加端到端的工作方式创造了条件。工程师不再局限于接收需求和完成开发任务，而有机会更深地参与问题定义、产品设计与业务价值创造。
四、对技术管理者提出明确要求：必须亲自实践AI，还有懂得判断
相比工程师岗位要求，我认为这一部分更值得关注。
亚马逊明确提出，技术领导者和组织管理者需要确保团队有效使用AI，改善客户和业务交付。
要做到这一点，管理者自己必须理解和实践AI。
原文特别强调：
That requires deeply understanding these technologies yourself, working with them hands-on rather than relying on what you hear.
亚马逊进一步给出了具体判断标准：管理者应该实际使用AI工具完成过生产工作，能够讲清楚某个AI发挥作用的任务、某个没有发挥作用的任务，以及背后的判断依据。
这对管理者提出了比了解AI趋势、参加AI培训更高的要求。
例如，研发经理如果自己没有体验过AI辅助开发，就很难准确判断AI如何改变工作流程，也难以识别AI生成代码带来的质量和维护风险。
但亚马逊同时强调，不能为了使用AI而使用AI。
If your work does not benefit from current AI tooling, that is a finding, not a failing.
如果某项工作目前没有从AI工具中受益，这是一项值得研究的发现，并不代表员工做得不好。关键在于能够解释原因、分享经验并寻找改进方式。
这背后体现出一种重要的管理能力：既要积极探索AI，也要具备判断AI能力边界和应用价值的能力。AI能做什么以及不能做什么都很重要。
亚马逊还特别强调了Learn and Be Curious（学习与好奇心）这一领导力原则。
根据内部观察，那些在AI应用方面产生较大影响的管理者，往往不仅自己投入时间学习AI，还会主动为团队成员创造学习时间。
这也提醒企业，AI转型不能仅依赖统一的培训与工具部署。管理者需要亲自参与实践，为团队创造探索空间，并推动AI融入真实工作流程。
五、最后
回顾这封内部信，有意思的是，亚马逊并没有因为AI出现就重新发明一套领导力原则。相反，它把AI时代的新要求与长期坚持的Customer Obsession（客户至尚）、Ownership（主人翁精神）、Learn and Be Curious（学习与好奇心）、Deliver Results（达成结果）等原则连接起来。
虽然这次更新首先面向软件工程师和技术管理者，但对产品、运营、人力、财务以及其他知识工作团队同样具有参考价值。
未来，管理者既要能够领导人，也需要学会组织人与AI协同完成工作；既要关注团队是否积极使用AI，也要能够判断这种使用是否真正创造价值。
这也是我们一直关注AI原生管理者能力建设的原因，也开发了《极简AI领导力》课程，欢迎大家报名参加，先成为AI原生管理者，然后推动团队和组织的AI转型。
附公开信全文：
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 (tokenmaxxingis 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 resultsand 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.
原文来源
Amazon，2026年10月27日
An update from Amazon engineering leadership on the role of the developer in the age of AI
链接：https://www.aboutamazon.com/news/company-news/amazon-software-engineer-role-guideline-ai
