“AI 会取代我的工作吗？”
在走访亚马逊遍布全球的客户时，每个国家、每个城市的客户都会提出这个问题。确实，一些任务会被AI自动化，一些技能也会因此过时。也许，我们应该重新表述这个问题——“AI 会让我过时吗？”
答案是：只要你始终保持进化，就绝对不会。每一次技术变革，无论是编译器的发展、结构化编程的兴起，还是面向对象编程的普及，都要求开发者主动适应和进化，Agentic AI时代自然也不例外。
那么，AI时代需要什么样的开发者？我的答案是，具备五种核心特质的“文艺复兴式开发者”（the Renaissance Developer）。
永葆好奇心
我遇到的每一位开发者，都有一种本能：拆开某样东西，探究其工作原理，始终渴望理解、改进与构建。我们必须守护好这种本能，永葆好奇心，因为它是学习与发明的核心驱动力。
对创新而言，学习有两件同等重要的事：敢于实验，以及愿意接受失败。如果一项实验的结果早已确定，那它就不能称之为实验，实验的核心价值在于驱动学习。达芬奇设计的飞机从未成功起飞，但如今，飞机已成为十分常见的交通工具。
愿意接受失败也至关重要。当我学习一门新语言时，无论是英语、葡萄牙语还是德语，都会先学习语法；学习编程语言时，我也会采取同样的方式。但最有效的学习，往往源于犯错后得到温和的纠正。你可以熟记所有语法知识，但对话时的结结巴巴，会开启真正的重新学习过程。这就像你可以阅读无数文档，但真正的成长，来自于亲手完成的项目、被验证的假设，以及被证伪的猜想。
有些能力，只能通过实践来学习和掌握。阅读、观察、倾听只能带你走到一定阶段，真正的学习，发生在你深度参与任务、承受适度压力且结果至关重要的时刻。耶克斯-多德森定律（Yerkes-Dodson Law）描述了压力与表现的关系：这是一条钟形曲线——压力过小，你会懈怠；压力过大，你会不堪重负；最佳状态处于曲线上升的斜率上：好奇心与挑战相匹配，适度的挑战能让大脑保持高度警觉、专注，并做好成长的准备。但你无法在安逸中达到这种最佳状态，必须主动将自己置于有考验的环境中。
学习不仅是一种认知行为，更是一种社会性活动，需要人与人之间的交流与碰撞。你需要不时“触碰玻璃”——走出日常的舒适区，比如加入一个音乐小组，或参加像re:Invent这样的行业会议。根据我的经验，保持思维敏锐的最佳方式之一，就是与其他正在创造新事物的人互动交流。
今年年初，海洋清理项目（the Ocean Cleanup Project）的Boyan Slat在播客《节俭》中告诉我，海洋中发现的塑料垃圾，80%都来自于1000条河流，而全世界共有300万条河流。为了清理海洋中的塑料污染物，他们不仅要解决存量垃圾问题，还要阻止新的塑料垃圾流入海洋。他们是如何做到的？他们将带有标记的假塑料和GPS装置投入河中，追踪这些“垃圾”的最终流向。通过桥梁、船尾的AI摄像头以及无人机等设备构建河流模型，预测塑料垃圾的流向与分布，从而将清理系统部署在最佳位置，发挥最大效用。
这正是开发者将技术技能应用于真实人类挑战时所能创造的价值。联合国预计，到2050年，全球人口将增加20亿。我们该如何养活这些人？如何确保他们拥有经济前景和医疗保健？这是我们的责任——通过开发技术，帮助解决世界上的一些重大难题。作为技术人员，我们拥有这样的能力。我很认同这句话：“我们的价值，不在于我们已知的知识，而在于我们愿意学习的态度。”
系统思考
1970年代，美国系统思想家、环境科学家Donella Meadows（多内拉·梅多斯）开始研究复杂系统。她并非计算机科学家，但她的洞见完美描述了软件世界的本质。她写道：“系统是一组相互连接的元素，无论这些元素是人、细胞、分子还是其他事物，它们都会随着时间的推移，产生自身特有的行为模式。”这是一个非凡的定义。每个工程师最终都会明白，我们所构建的系统，都有其自身的“生命”。
一个经典的例子来自生态学。20世纪初，黄石国家公园将狼“驱逐”出园区。从表面上看，这一做法合情合理。捕食者减少，意味着麋鹿数量会增加，生态系统中的生命会更加丰富。但结果却截然相反：麋鹿种群过度膨胀，疯狂啃食山谷中的植被，导致树木消失，河流开始侵蚀土地。这种现象被称为“营养级联”（the Trophic Cascades）。2010 年，狼被重新引入公园后，生态系统开始慢慢恢复：植被重新生长，河狸回归，甚至河流的走向也发生了改变。并非狼群直接改变了河流走向，而是它们改变了整个生态系统的运行方式 ——捕食者与猎物的反馈回路，重塑了整个系统的平衡。当系统结构发生变化时，行为模式也会改变；当反馈机制发生变化时，最终结果也会改变。这就是所谓的系统思维。
类似地，在软件世界中，每一项服务、每一个API、每一个队列，都是更大系统的一部分。你不可能只牵一发而不动全身：修改或重写策略会影响系统负载，添加缓存会改变流量分布，调整团队所有权则会影响项目交付进度。
每一次变化都会产生新的模式，有些稳定，有些则不稳定。每个动态系统都由反馈回路塑造：正反馈回路（有时也称为“增强回路”）会放大变化，平衡回路（或负反馈回路）则会抵消变化，将系统推回平衡状态。Donella Meadows指出，一旦你识别出这些模式，就会发现，微小的变化可能会改变整个系统的行为。Donella Meadows将这些关键节点称为“杠杆点”。在这些点介入，就能整合所有要素，推动系统发生根本性改变。具备系统思维，在更大的视野中审视自己的工作，有助于构建更具弹性的系统。
有效沟通
文艺复兴式开发者的第三个核心特质，是强大的沟通能力。如果你有过跨国交流的经验，或具备跨国视野，就会明白，清晰表达自身想法的能力至关重要。
我始终认为，工程师或技术领导者为职业生涯能做的最重要的事，就是锤炼并培养出色的沟通技巧。开发者需要向业务方清晰地阐明系统架构、功能特性，以及技术所能带来的业务机会。
开发者一直通过编程语言与机器沟通。编程语言具有高度精确性，因此开发者可以明确地告诉机器自己想要它做什么。
但在当今AI辅助编码的时代，我们越来越多地使用自然语言与机器交流，而自然语言本身具有模糊性。举一个极端的例子，“Let's eat Grandma” 这句话，对机器来说，到底是“让我们吃掉祖母”，还是“祖母，我们来吃饭吧”？因此，我们需要开发能够减少语言模糊性的机制，降低人类表达的歧义，以便机器生成逻辑清晰、规范严谨的代码。
早期的结构化编程环境建立在形式化规范的基础之上，能够在代码执行之前验证程序的正确性。阿波罗导航系统就依赖于这套精密的规范体系，它如同精准无比的蓝图，引导着14.5万行代码的编写，最终助力人类成功登月。
我在大学学习计算机科学时，有一门课程名为“访谈技巧”。这门课并非教我们如何成为记者，而是教我们如何与客户沟通，真正理解他们的核心需求。客户可能对技术一无所知，却会向你寻求技术解决方案，这种情况屡见不鲜。
如今，很多客户问我：“我该如何使用AI？” 在回答这个问题之前，我需要先问他们：“你为什么会有这个问题？”大多数人的答案是“害怕错过”。了解客户真正想要解决的问题是什么、他们看到的机会是什么，是我们工程师必须具备的核心能力。
成为工作的主人
过去，我曾提出“谁开发，谁运维”（You build it, you own it）的理念。今天，我想强调其中的一个核心部分：开发者对软件的质量负最终责任。
AI让我们能够构建更庞大的系统，探索更多的创新想法，以更快的速度前进，帮助我们构建“更坚韧、更好、更快、更强大”的软件。但部分开发者使用这些工具的方式，却暗藏风险。“氛围编码”（Vibe Coding）本身并无不可，但前提是你必须密切关注自己正在构建的内容。不要指望仅在集成开发环境（IDE）中简单操作，就能自动产生优秀的成果——这不是软件工程，而是像老虎机一样的赌博。
请记住，这项工作是你的，而不是AI的。在医疗保健、金融服务等受监管的领域，你必须遵守相关法规要求。如果AI生成的代码违反了监管规定，你不可能对监管机构说：“这是AI做的。”你仍然需要承担责任，因为工作成果是你的，而非AI的。
有了AI，你需要编写的代码会减少，因为代码生成的速度很快；但你需要审查的代码会更多，因为理解这些代码需要时间。当你自己编写代码时，理解与创作是同步进行的。但当机器替你生成代码后，你必须在审查过程中重新构建对代码的理解。这就是所谓的 “验证深度”（Verification Depth）。
这其中存在两个主要挑战。第一，AI生成代码的速度远超人类理解的速度，如果在尚未真正验证代码功能之前，就将其部署到生产环境，后果将不堪设想——“天知道它会惹出什么麻烦。”第二是幻觉问题：模型可能会生成一个看似自信、实则与系统架构背道而驰的设计；一些API交互和大语言模型还会编造不存在的属性，生成完全不适用、过度设计或忽略系统自身模式的解决方案。这些输出看似合理，却缺乏现实依据。
不过，我们在这一领域正在取得进展，通过各种方法与机制，将良好的意图转化为实际成果。科技行业的方法与机制多种多样，每个团队都会根据自身工作的规模与性质，构建适合自己的解决方案。
例如，规范驱动开发可以显著提高软件质量。亚马逊云科技杰出科学家、自动推理领域权威Byron Cook展示了如何使用自动推理技术，确保Agent的可靠性。还有许多开发者正在优化他们的CI/CD管道，构建更多的自动化测试。
Amazon S3团队使用了一种名为“持久性评审”（Durability Reviews）的方法：当工程师提出可能影响数据持久性的更改时，团队会暂停开发，对风险进行建模，记录所做的更改，列出所有可能的威胁，并绘制保护数据安全的防护措施。这是一种效果强大的机制，它将代码的持久性从一种技术属性，转变为整个团队的工作习惯。它促使工程师思考失败模式，而非仅仅关注理想情况，也展示了机制的重要性——将良好的意图转化为可持续的成果。
仔细想想，同行代码审查也是一种重要的机制。我们都讨厌代码审查，但它作为一种机制却至关重要。因为它创造了一个意图与实现相遇的时刻：另一位工程师可以质疑代码中的假设，发现原作者已经无法察觉的问题。
在AI驱动的世界里，代码审查比以往任何时候都更加重要。模型生成代码的速度太快，而人类的理解能力却难以跟上。因此，审查成为恢复平衡的控制点：人类的判断被重新引入开发流程，确保软件真正按照人们的期望运行。我鼓励大家坚持并加强同行代码审查。而且，资深工程师与初级工程师协作审查代码，是一种极其高效的学习机制。资深工程师的优势在于模式识别能力和更高层次的判断，而初级工程师则能带来全新的视角，常常发现他人忽略的细节。知识正是这样传承的，我们也正是这样成长的。下一代建设者们，AI将改变许多事物，但技术的手艺仍将通过口传心授的方式传承下去。
做个博学者
博学者（Polymath）意味着，既拥有深厚的领域专业经验，又具备跨学科的知识广度。达芬奇大概是博学者的最佳典范，他既是画家、工程师，也是解剖学家和发明家。我们不可能都成为达芬奇那样的天才，但我们也应该扩展自己的知识边界，而不仅仅是成为我所说的“I型开发者”，即某个领域的专家。
我曾经的良师益友Jim Gray，是图灵奖得主、数据库“事务处理”（Transaction Processing）的发明者。如今，人们所进行的每一笔电子交易，都应该感谢Jim的贡献。但他的兴趣领域远不止数据库。他有一个著名的挑战：“给我 20 个你想从数据中找到答案的重要问题，我将为你设计一个系统。”
Jim早期参与的项目之一，是著名的“斯隆数字巡天”（Sloan Digital Sky Survey），这是最早出现的大规模数据集项目之一。在开发天域服务器（Sky Server）的过程中，Jim做出了开创性的贡献：他作为数据库专家的深厚知识，为天文学中的计算带来了革命性的影响。
这期间有一个非常有趣的故事。有一次，Jim前往巴尔的摩，因为那里有一个开发小组。他走进服务器机房，30秒后就走了出来，告诉团队：“数据库的布局是错的。” 所有人都惊讶地看着他，问：“你怎么知道？”仅仅通过听磁盘运转的咔嚓声，他就判断出系统存在过多的随机访问。这种直觉或者说“第六感”，源于他数十年的行业经验。他建议团队重新设计架构，系统性能果然得到了显著提升。
Jim完全不是我所说的“I 型开发者”。他对数据库以外的许多领域都充满好奇，不仅懂技术，还懂人性、懂商业，以及广泛的技术领域。我将他称为“T型人才”——在某一领域有深厚的造诣，同时拥有广泛的知识涉猎。
想要在工作中取得成功，你需要一套独特的技能组合，包括个人技能、专业深度和行业知识。一位了解前端性能或成本优化的数据库开发者，能够做出更好的架构选择，因为他能看到自己的工作如何影响整个系统。知识的广度能给你提供改进所构建事物的全新视角，因为你懂得如何进行权衡与取舍。
T型开发者兼具深度与广度，既能深入研究具体问题，也能理解该问题如何融入更大的系统。因此，你们既要在自己的领域深耕细作，也要扩展视野，连接多个学科与理念。
顾客只需点击一个按钮，包裹就能送达。他们会想到维护商品目录的人吗？会想到负责供应链的团队吗？不会。顾客永远不会告诉你：“你的数据库设计得真棒！我们喜欢你们所做的工作。” 只有你们自己，能够理解其中的付出与努力。对我们的工作感到自豪，对那些整夜运转、顺利部署却不为人知的系统，以及我们所构建的大多数事物感到自豪，这一点至关重要。其他人看不见它们，但我们心中清楚，因为这是我们的工作。卓越的运营，是我们的职业勋章，它定义了什么是最佳构建者。就算没有观众，我们也能保持专注、全情投入，把事情做到极致！
Werner Vogels是亚马逊（Amazon.com）副总裁兼首席技术官
