AI 写代码之后，工程师还剩下什么？

三年多以前，Swyx 写了一篇文章，题为《AI 工程师的崛起》。他的观点是，开发 AI 产品需要的是工程师，而不是研究人员。我想这句话引起了很多人的共鸣，尤其是来参加这场大会的人。于是，“AI 工程师”这个职位名称出现了，此后公司也一直在招聘这个岗位。

我今天想说服大家的是：他其实还没有把话说到位。发生变化的不只是 AI 工程师这个岗位，而是所有类型的工程师。所有工程岗位都在被一种新型工作取代，而且并不是每个人都会喜欢这个消息。

我的判断是，这不会止步于此。我们会找到自动化代码审查的方法，让审查速度跟上智能体，然后又会遇到另一个瓶颈、再一个瓶颈、再一个。最终我们会碰到一道无法跨越的坎。人类剩下要做的，就是智能体无法突破的那个瓶颈。我打赌自己能想到一件智能体确实做不到的事。等我们走到那道瓶颈前，还得想办法培养下一代工程师去做那份工作，因为我们现在并没有在这样培养他们。

先提醒一下，也算道个歉：我只有 18 分钟，因为 Swyx 给演讲安排的时间就是这么长。我为这次演讲做了大量研究，手里有一大堆数据，却没时间一一讲完，也没时间逐条引用来源。所以我会直接报一些数字，幻灯片上会放很多引文，大家就先信我吧，兄弟。（笑）

我们卡在代码审查上，原因是人类没法单纯靠加快速度来审查。思科二十年前做过一项大型研究，考察代码审查的速度和准确性。结果发现，人类理解代码内容的能力，在每小时审查大约 450 行之后就会急剧下降。因此，如果智能体给你生成了一份一万行的差异代码，要合理地审完它大概要花一周。可现实是没人真的这么做，因为如今大家都在随手扔出一万行的差异代码。

我之前在一届 AIE 上专门讲过这个现象，那场演讲叫《代码审查之死》。想了解细节可以去看那场演讲。但我这次要解决的问题有所不同：生成看起来合理的代码的成本已经崩塌，而判断这些代码是否值得信任的成本却原封不动。

问题在于，机器审查者现在还不够好。我找到的一项研究让四种 AI 审查工具接受测试，它们都找出了不少 bug，但找出的并不是同一批 bug；它们对任何一个具体 bug 都没有达成一致。它们确实都发现了代码里的真实问题，只是各自发现的问题不同。因此这些工具值得运行，但如果你认真对待代码审查，就不会只用一个，因为它们目前还不够可靠。

有些人走得更远，干脆说：“我不再审查代码了，就假设我的智能体一次就能完美完成。”Dexter Horty（他可能在现场，也可能不在）曾花六个月劝大家别读代码；六个月后他上台承认：“我错了。完全跳过代码审查行不通。我们试过，结果是一场灾难，不得不把整个系统推倒重做。”这不是可行选项。智能体还不够好，没法一次就把代码写对。

亚马逊经历了一连串故障，并在复盘后认为，原因是他们的编码智能体生成了一堆粗糙代码，团队没有仔细思考就把它们发布了。现在他们不再允许这么做，亚马逊的代码审查必须由资深工程师签字。Anthropic 也发布过复盘，讲述一些 bug 如何同时绕过了所有人工和机器审查者。问题是，我们迄今搭建的代码质量自动检查机制本身还不够好。

Claude Fable 5 在标准编码基准的测试中有 80% 能通过。Cognition，也就是 Devin 的开发商，做了一个不同的基准测试：不问代码是否通过测试，而是问你作为这个仓库的审查者和维护者，会不会合并这个 PR。换成这个问题，成绩就从 87% 降到了 54%。因为判断是否合并还需要很多额外信息：代码风格、副作用、外部系统，以及没有写进代码库、只存在于维护者脑中的历史。

维护者确实带来了智能体尚未获得的信息和技能，那就是对“什么才算好”的判断。这是智能体目前缺少的关键能力，我稍后会再谈到。

Eliyahu Goldratt（如果我没念错的话）是一位后来成为管理学大师的物理学家。他在 1984 年写了一本关于经营工厂的小说。听起来像是一本有趣的小说吗？书名叫《目标》。他提出的核心思想就是约束理论：每个系统都有一个瓶颈；除非你加速的正是瓶颈，否则加速其他环节并没有用。这正是我们的代码审查问题：代码写快了，审查却没有跟上。

他的第二个观点与今天更相关：解决瓶颈并不会让它消失，它只会转移，然后在另一个瓶颈前堆积。尽管我刚才说了现在的代码审查工具有多糟，我们还是先假设最终能把自动化审查做到更高水平，把这个瓶颈移开。那么接下来会撞上什么？

这场演讲有一个很大的跨越：我先假设这些问题我们也都会解决，因为人类已经积累了大量相关经验和数据。如果我们能用越来越先进的智能体解决运维、扩容和安全，最终还剩什么要人做？那种情况下，人类扮演什么角色？

这是个大问题，也是个长期问题。我不是在预测接下来 12 个月会发生什么。我认为未来一年代码审查会取得实质进展，但 12 个月后，我们还不会解决运维、扩容和安全。我觉得这些需要 5 到 10 年。尽管有人喊着“2027 年实现 AGI”，现实中我们会在这些事情上逐步迭代。

我的论点还依赖另一个假设：我们对软件的需求实际上是无限的。这个论点要容易得多。想想你在生产环境中遇到过的各种网站，大概都挺糟糕。糟糕并不是因为我们不知道怎样做出好网站，而是没有足够的人手把所有网站都做好。无论是理发店、政府机构还是银行的网站，做得差都不是因为没人懂得如何做好。原因有两个：把它做好很贵，而且懂这些的人正忙着做别的事——也许是在交付 AI 智能体。

所以，假设我们几乎可以免费生产任意数量的软件，而人们对软件的需求也近乎无限。这是个很好的处境：需求无限，供给也突然变得无限。瓶颈最终会落在哪里？

剩下的工作，是弄清人们真正想要什么。每一款软件，都是把某个人想完成的事情形式化。客户说“我需要追踪订单”，市面上有一万种能追踪订单的软件，但如果你经营的是面包店，可能只有一种（如果幸运的话）真正好用。汽车零件店的需求又不同，大型制造企业则完全不同。仅仅说“追踪订单”还不够；工作在于弄清这对你的业务究竟意味着什么、软件要做什么、具体该怎么运作。

这些知识不在训练数据里，也不在模型权重里，而在经营者脑中。要把它挖出来，唯一办法就是和他们面对面交流：你动动嘴，他们也动动嘴。总之，你得跟他们谈。

这项工作有个重要特点：经验无法直接迁移。日历应用和排期应用解决的问题很相似，但它们是完全不同的软件，需求和“好”的定义都截然不同；而类似的使用场景还有无数种。你有没有用过配置选项多得不得了、却还是不能满足需求的软件？我说的就是你，Jira。这就是试图面面俱到的软件仍然处处不合用的问题。

因此，瓶颈会转移到描述问题，以及定义怎样才算解决问题上。这是我这场演讲、也是我对未来十年的核心判断：瓶颈会停在这里。

Brooks 的判断看起来相当准确：代码生成快了八倍，交付速度却没有快多少，因为困难的部分是本质问题。OpenAI 的 Shawn Grove 一年前也表达过类似观点：代码是规格说明的一种有损投影。无论规格说明是由产品经理、立法者、工程师还是营销人员写的，写规格的人就成了程序员。如今，价值就在于把“好”是什么写下来。

我快没时间了，这次时间安排得不太好。任何能够低成本验证的东西，模型开发者都可以拿来训练，直到模型达到或超越它。Cognition 因为自己的基准测试，尝试把“什么样的代码可以合并”写清楚：能不能把所有额外信息都纳入基准，再据此训练模型？Cursor 的审查工具 BugBot 会把团队给出的每个差评转成一条规则，他们现在已经有大约 44,000 条规则。

维护者一旦把脑中的知识写下来，让模型可以据此训练，瓶颈就又会移动。这就是我认为安全和运维终究可以交给智能体处理的原因：虽然现在还没做到，但我们最终能把这些知识写下来。

Google Brain 和 Coursera 的联合创始人 Andrew Ng 说，他团队里有人提议让产品经理数量达到工程师的两倍。他说这是他第一次听到这种建议，但他的应对方式不是多招产品经理，而是模糊这两个岗位的边界。用他的话说，工程师了解用户，能决定做什么并直接把它做出来，就能极快地执行。我认为，我们正开始找到答案。

这不再是 AI 工程师——他们不只是构建 AI，也不只是用 AI 开发，而是构建所有类型的软件。我把这个岗位叫作“产品工程师”：他们发现人们需要什么，定义什么才算好，再让智能体代替自己敲代码并交付产品。Pragmatic Engineer 通讯作者 Gergo Orosz（名字可能被我念错了）在 2019 年把“有产品思维的工程师”描述为一种可取的特质；而我现在的观点是，这已经从加分项变成了必需品：过去是资深工程师才需要的技能，现在每个工程师都得具备。

市场已经在为这种能力付钱。类似产品工程师的“前线部署工程师”岗位，在 2025 年的九个月里，招聘信息增加了 800%。他们到处都有人招。在场有谁正在招前线部署工程师？举个手看看。好吧，举手的人比我预期少。顺便说一下，这类工程师的平均薪酬是 24 万美元，也就是资深工程师的水平，因为他们本来就是资深工程师，而且非常有用。不过，这个岗位现在有上千种不同叫法，我只是随意把它叫作产品工程师。

你们中有些人也许会想，这不算编程，你们说得对，这不是编程，编程由智能体完成。但它显然仍是软件开发。我们必须接受这样一个想法：到了 2026 年，软件开发者和程序员已经不再是同一个概念。

我说“难点是判断什么才算好”时，也意识到自己可能落入了 AI 圈常见的陷阱：所有事情都能被 AI 自动化，唯独我擅长的事情不行，因为那太难了。我前几天听一位风险投资人也这么说，心想：“朋友，别这样。总有一天你的工作也会被自动化。”所以请对我的判断持保留态度。软件开发中我喜欢的是找出问题；这会不会只是我觉得困难的部分？如果我错了，你们可以告诉我。

但我们仍然需要大量前线部署工程师，也就是产品工程师，而且得从某个地方培养出来。不能抛下新一代开发者不管；他们来问“这些工作该怎么做”，我们却回答“我不知道，因为我也不知道你的工作现在是什么了”。（笑）

这不是对未来的猜测，而是一张从 2023 年 1 月开始的真实劳动力统计图，按年龄分组。红线代表 22 到 25 岁的工程师，他们的就业正在急剧下滑。公司没有在招初级工程师。这不是我觉得将来会发生的事，而是已经持续两年的现实，他们的就业市场很糟糕。与此同时，41 到 49 岁工程师的就业大幅增加。资深工程师仍然非常有价值，甚至比以前更有价值；但初级工程师正在受损，我们这个行业必须解决这个问题。

如果我们要享受代码产出提高十倍的好处，并且解决软件供应链的其他环节、弄清人类该做什么，我们就需要很多人来做这些事。我说过，软件需求会趋向无限；我们需要无限多的人。上哪儿找？

到目前为止，我们只是无意间培养出了这类人才，现在得想办法有意识地培养。Google 的副产品经理项目每年培养出 50 人，他们的能力很像产品工程师；我们每年需要 10,000 人。把 Google 的 APM 项目广泛复制的其他公司也算进来，每年总共大约只培养 1,000 人，而我们的需求至少是这个数字的十倍。

大学教数据结构，训练营教 React，却没有人教“去面包店待一周，再带着规格说明回来”。我们需要的正是这种人。如果你领导工程团队，就得有意识地培养他们。IBM 已经在重新设计入门级岗位，让新人和客户交流、编写规格说明，而不是编程。你也得想办法培养产品人才，而且得尽快：我们两年前就该开始了。现在有整整一批很难过、失业中的初级开发者遇到这个问题，而我们没有雇用他们。我们必须有所行动，否则受害的不只是他们，我们自己也会陷入困境。

但我有个观察：很多以为自己爱的是敲代码的人，也许真正喜欢的是开始敲代码前的那一刻——想明白问题的时刻。那部分不会消失。你突然想到“我知道怎么把这件事变成一个可重复的系统”，脑中闪过创意火花的感觉也不会消失。

编程这门手艺会继续存在，就像木工在家具工厂出现后仍然存在一样。程序员编程，就像歌手唱歌：即使没人看、独自在空房间里，他们也会因为热爱而去做。这不会消失，只是它不再是别人每年花几十万美元雇你去做的工作。

这是我的预测：接下来的十年会很艰难，过去两年已经很艰难了。变化在工具准备好之前就涌来了；培养初级开发者的阶梯消失了，我们还没想出怎么培养新一代。许多热爱编程手艺的人，也得决定自己是否喜欢取代它的新工作。

不过，这种事以前发生过。编译器、框架、开源软件，都曾让一代人原本要敲的代码变得不再必要；每次之后，软件开发者反而更多了。只是软件开发的含义改变了。我认为这次也会如此。十年后，这个职业的规模会比今天更大，薪酬大致相当，工作形态则主要是产品工程。这就是我今天想提出的判断。

但这些都是很宏观的预测，我不喜欢这种说法。它们到底意味着什么？今天你们实际该怎么做？

然后，把所有容易验证的事情交出去。花时间想想，怎样建立自动方法来判断某件东西是否合格，再把这个方法交给智能体，而不是亲自琢磨审查流程。

最后，把最优秀员工的判断写进规格说明、评分标准和评估里。你们知道，我是 Arize 的人，总要在某个时候提到评估。把只存在于人脑中的知识变成代码。这就是产品工程师的工作：把对问题的感知转化成问题的规格说明，让智能体替我们构建产品。

还要衡量正确的指标。代码多了 741% 从来不是目标，要衡量实际交付了多少。衡量审查者的意见有多少被采纳，衡量“测试通过”和“维护者愿意合并”之间的差距。别忘了，最后的审查者是生产环境。观察产品在生产环境里的表现，再用另一个模型来评分，这本身就是评估。我不是在推销 Arize，这只是我们的工作，也是我们现在很受欢迎的原因。就说到这里。

三年前，Swyx 写了《AI 工程师的崛起》，讲的是工程师学习用模型构建产品。如今“产品工程师的崛起”，说的是模型负责构建之后还剩下什么：发现人们的需求，写下“好”究竟意味着什么，再把产品做成大家喜欢的样子。这就是现在的工作，也将成为在场每个人的工作，不管我们喜不喜欢。我们现在都是产品工程师了。

非常感谢大家的时间与聆听。（掌声）