企业正在向AI投入巨额资金，但收效甚微。这在一定程度上可能是因为，领导变革的人选并不合适。

正如我之前所言，AI不太可能消灭开发者，而是会改变我们对开发者的需求。举例来说，我们一直在追问，在一个大语言模型能够以更低成本、更快速度编写代码的世界里，初级开发者是否还有存在的必要。这种讨论忽略了一个现实：这些年轻开发者以及他们相对缺乏的经验，可能恰恰是我们改写软件开发规则所需要的。

这个想法是在我读到James Governor对Ben Griffiths观点的引申时产生的，Ben Griffiths谈到了我们行业将年龄与权威混为一谈的习惯。Griffiths回忆起在一次技术会议上，一位演讲者试图羞辱年轻听众不认识那些曾塑造计算领域的老一辈人物。Ben指出，讽刺的是，那些"老前辈"完成改变世界的工作时，比台下被训话的听众还要年轻。Bill Joy在22岁时编写了vi，John Carmack在23岁时创造了Doom，Linus Torvalds在22岁时启动了Linux——这些例子不胜枚举。我们行业的许多巨擘都是在积累数十年经验之前就做出了最大的贡献。

这里的关键不是说年轻人更聪明。他们并不更聪明。重点也不是说AI成功的关键在于忽视更有经验的开发者。那很愚蠢。更确切地说，Griffiths更宏大的观点是正确的：在重大变革的初期，经验可能是一把双刃剑。它可以帮助你看到风险，但也可能让你对旧方法过于自信。最成功的企业将找到方法，在年轻的创新精神与经验的护栏之间取得平衡。

工厂不会自我重新设计

Zara Zhang最近引用了Paul David 1990年的经典论文《发电机与计算机》，以此来解释为什么这么多公司"采用"了AI却没有多少成果。David的论点可以简化为：电力并没有立即改变工厂。在很长一段时间里，工厂只是用电动马达替换了中央蒸汽机，同时保持相同的布局、相同的工作流程和相同的假设。

电力是新事物，但我们却将它强行塞入旧的工厂体系，在很大程度上扼杀了它的潜力。

真正的生产力飞跃来得更晚，当工厂不再将电力视为更清洁的蒸汽机，而是开始围绕分布在整个工厂中的小型马达重新设计工作时。一旦每台机器都能拥有自己的马达，工厂就不再需要围绕一根传动轴来组织。工作可以围绕生产流程来重新组织。

这在很大程度上描述了当前许多企业使用AI的现状。企业正在批量采购Copilot许可证，将智能体接入现有应用等，然后困惑为什么结果如此不平衡。这相当于用电动马达替换蒸汽机，然后宣布AI现代化工作已经完成。事实并非如此，还差得远。

真正的回报不会来自让AI以稍快的速度编写相同的工单。相反，它将来自改变团队定义工作的方式以及开发者构建什么、如何构建。"工厂"必须改变。

那么，一个不太令人舒适的问题是：谁最有可能建造新工厂？

经验是把双刃剑

将青春浪漫化存在一个明显的危险。许多糟糕的软件都是由信心无限但见识有限的开发者编写的。企业需要能够真正工作的软件，但"能够工作"也意味着它要合规、可扩展、尊重安全边界等等。

这正是资深开发者发挥重要作用的地方，而且非常重要。

正如我最近指出的，智能体时代让工程判断力变得比以往任何时候都更加重要。毕竟，AI让生成代码变得更容易，但更容易的代码生成也可能变成更容易的技术债务生成。因此，限制因素不再是"我们能创造什么"，而是"我们能否在正确的位置、以正确的约束条件创造正确的东西"。换句话说，品味是必需的。

资深工程师通常更善于看到这些约束，因为他们的经验赋予了"品味"。他们知道为什么那个奇怪的验证规则存在，他们记得依赖那个未记录行为的客户。他们理解为什么一个简单的模式变更可能变成数周的迁移。

但经验也有阴暗面，因为它可能让当前的流程看起来不可避免。资深工程师可能会将AI助手视为更快的自动补全，因为这是将AI融入他们现有思维模型的最简单方式。初级开发者不那么受旧工作流程的束缚，可能会问出更有趣的问题：我们为什么非要做这个工单？为什么需求规格不能直接执行？为什么不能让智能体先生成测试框架？

这并不是说更有经验的开发者不知道这些问题，而是他们可能已经没有精力去与体制对抗了。

缺乏经验的价值

在AI时代，利用初级开发者最糟糕的方式是将他们视为更便宜的资深开发者版本。这一直是个糟糕的主意，但AI使其更加糟糕。如果工作内容是"接这个工单，生成一些代码，然后发给资深人员审查"，初级开发者就变成了编码助手的人工包装。这对任何人都没有帮助。初级开发者学不到什么，资深开发者被审查任务淹没，企业最终得到了更多代码——而正如我所说，这绝不是一件好事。

相反，应该给初级开发者探索新工作流程的空间，并辅以经验丰富同事的适当指导。这可能意味着给这些新开发者一些有趣的问题去回答，例如：

• 如果每个内部API都有AI可读的合约和实际可用的示例，我们该如何重新设计入职流程？
• 如果智能体在每次拉取请求中都生成变更摘要、测试证据、依赖风险分析和回滚计划，我们该如何改变代码审查？
• 如果产品需求被编写为可执行的验收测试，而不是含糊的散文，我们该如何构建功能？
• 如果智能体能够在明确定义的边界内安全地执行常规迁移、依赖更新或事件分类，我们该如何减少重复劳动？

这些不是玩具问题，也不是"初级工作"。它们正是企业需要但通常回避的那种流程重新设计，因为每个人都在现有的仓鼠轮上忙得不可开交。

找到平衡

那么，工程领导者应该做什么？首先，停止将AI采用视为个人生产力竞赛。我们似乎正在迅速摆脱"大量Token等于优秀工程师"的观念，但我们竟然曾经接近过这种想法这一事实本身就说明问题。我欣赏Santiago Valdarrama对这一虚荣指标的犀利批判："用编写的代码行数来衡量AI生产力是一个愚蠢的错误。总有一天，每个人都会声称自己从一开始就反对这种做法。"相反，我们应该问这样的问题："我们软件交付流程中的哪个部分已经不再合理了？"AI最大的收益将来自于我们如何改变需求定义、测试、审查和发布软件的方式。

其次，打散你的AI工作流团队。不，不是指委员会或那些只会生产PPT的卓越中心。我说的是将两三个已经精通AI原生工具的新开发者与两三个理解生产、安全、架构和组织约束的资深工程师组合在一起，然后给他们一个真正的工作流程去重新设计，比如依赖升级或测试创建。

第三，让资深工程师的工作变得不那么多说"不"，而更多是定义别人可以在其中说"是"的护栏。我一直认为，黄金路径是有效使用AI的关键。优秀的资深工程师应该定义铺好的道路：经过批准的开发模式、测试要求、可观测性标准等，然后让初级开发者和智能体在这些边界内快速行动。

第四，奖励删除。这可能是最重要的一点。回到工厂电力的比喻，如果我们只是添加AI而不移除过时的流程，AI现代化就会失败。

让所有人都参与进来

软件开发的未来不属于年轻人，也不属于年长者。它将属于那些将两者才能结合起来的团队。

新开发者往往带来不耐烦。他们不太可能接受现有的工作流程是神圣不可侵犯的。他们更有可能尝试奇怪的工具，以意想不到的方式组合它们，并质疑为什么企业软件开发感觉像是一种等待批准进行各种操作的仪式化练习。

经验丰富的开发者带来的是判断力。他们知道软件有用户、审计师、攻击者、预算、延迟、历史和后果。他们知道正确的答案往往是无聊的，而无聊是好事。

企业需要两者。他们需要那个问为什么工厂仍然围绕旧传动轴组织的开发者，也需要那个知道哪些机器如果被随意移动将造成严重后果的开发者。总之，每个开发团队都需要既了解旧系统存在原因的人，也需要那些不清楚为什么的人。