Laurie Voss：AI 编程智能体之后的产品工程师

我是 Laurie Voss，Arize AI 的开发者关系负责人，此前联合创立了 npm。三年前，Swyx 认为交付 AI 产品既需要研究者，也需要工程师。我认为，现在的变化已经超越单独的 AI 工程师角色：各种工程岗位都可能受到影响。

编程智能体让代码产出相对于过去所需的人力时间变得非常便宜，尽管 token 仍有成本。代码生成之后的所有环节却没有同时变得免费。我的论点是，瓶颈会先转向代码审查，随后随着每个约束得到解决，转向其他环节。

最终，我预计会遇到智能体难以轻易消除的约束。如果我们能找出剩下的工作，也需要弄清如何培养下一代工程师来承担它。Voss 提醒，演讲将大量研究压缩成数字和幻灯片引用。

Voss 引用一项分析称，使用自主编程智能体的开发者代码产出增加 741%，而发布量增加约 30%。他认为这一差距说明审查正在限制交付。这些数字来自他引用的分析，本身不能证明对每个团队都存在普遍的因果效应。

他还引用较早的 Cisco 和 SmartBear 审查研究，称审查速度超过每小时约 450 行后，准确性会下降。他用这一例子说明，审查智能体生成的大型差异可能需要大量人工关注。准确的安全审查速度取决于变更和条件；引用数字不是普遍阈值。

Voss 认为，产生看似合理代码的成本已经下降，但判断代码是否值得信任仍然困难。自动审查是一种应对方式。他引用 GitHub Copilot 的采用和公司审查政策等例子，但认为这些工具目前尚不够可靠，不能假定生成的变更无需审查就是安全的。

Voss 描述了一项对四个 AI 审查工具的评测：每个工具都发现了真实问题，但发现的内容没有重叠。他认为，单独运行一个审查工具可能遗漏缺陷。他还讲述了一位工程师在遇到严重问题后放弃不审查代码的经历，以及公司事故案例；这些说法应放在各自背景下理解。

编程基准可以问测试是否通过，而维护者还要决定是否合并变更。Voss 引用两种分数之间据报道存在的差距，其中维护者接受度更低。他将差距归因于风格、副作用、外部系统和项目历史等因素，这些因素未必记录在测试套件中。

按照他的解释，维护者贡献了对特定项目中什么算好的判断。他认为，这是智能体目前还没有掌握的信息或判断力，也成为他在演讲后续部分的核心观点。

Voss 引用 Eliyahu Goldratt 的约束理论：改善非限制性环节未必能改善整个系统，解决一个瓶颈后会暴露另一个。他预计，如果审查加速，运营和随后安全可能成为重要约束。

他更长期的思想实验假设，能力不断提高的智能体也会处理部署、扩展和安全。他不预计这些问题会在一年内解决，并提出五到十年的时间范围。这一时间表和这些任务可以自动化的假设是他的预测，并非已证明的结果。

他的论点还假设软件需求实际上极其巨大。Voss 指出小企业、政府和银行中没有得到很好满足的需求：人们知道如何构建更好的工具，但时间和成本限制了产出。他问，如果软件需求和生产能力都大幅扩张，什么会变得稀缺。

Voss 将编写、审查、交付和扩展，与决定构建什么、定义好结果和让产品真正有用区分开。他预测智能体会承担更多前一类任务，而后一类仍然困难。这是他的预测，并不保证任何特定任务不会被自动化。

客户可能说自己需要跟踪订单，但这对面包店、汽车零件商店或制造商意味着不同的事。工作在于发现特定企业的需求及解决方案必须做到什么。Voss 认为，这些知识存在于实际工作的人那里，因此开发者必须与他们交谈。

即使关系密切的产品，对好的定义也可能不同：日历和日程安排工具解决的问题有重叠，但需求不同。Voss 认为，高度可配置的产品仍可能无法满足用户的具体需求。他押注描述问题及成功解决方案会成为持久的约束。

他将其与 Fred Brooks 对偶然复杂性和本质复杂性的区分联系起来：前者是工具、语法和实施的困难，后者是问题本身的困难。Voss 将代码产出加速与交付改善之间的差距视为符合这一区分，但数字本身并不能证明这种解释。

他还引用 Shawn Grove 的观点：代码是规格的有损投影，编写规格的人承担了程序员的角色。在 Voss 看来，把期望结果写进文字和测试正变得越来越有价值。

如果某件事可以低成本验证，模型构建者就可以针对该验证进行训练。Voss 描述了定义拉取请求是否可合并的工作，并引用了一个将反馈转化为规则的审查工具。他预计，随着维护者将原本隐含的知识明确表达出来，瓶颈会再次转移，包括运营和安全领域。

Voss 引用 Andrew Ng 对产品和工程角色融合的看法：一个理解用户、决定构建什么并亲自实施的工程师可以快速行动。他将其与较早的系统分析师角色相比，后者将业务问题转化为需求。

他提出的产品工程师负责发现人们的需求、定义好结果并交付解决方案，而智能体承担大量打字工作。他提到 Gergely Orosz 早先对具有产品意识的工程师的描述，并认为这种取向可能从优点变成必需。

Voss 引用前线部署工程师招聘信息的增长和一项报道的薪酬数字，作为市场重视类似技能的迹象。职位名称和样本各不相同，这些例子不能证明整个行业的发展轨迹或薪酬水平。他承认自己选择的名称只是众多叫法之一。

他意识到自己论点中可能存在偏差：讨论自动化的人经常认为，自己喜欢的工作恰恰是 AI 不能完成的部分。Voss 请听众对他的预测保持怀疑，包括他认为发现真正问题才是困难部分的观点。

接下来他关注初级开发者的成长路径。过去团队常通过分配明确的实施任务并审查结果来培养新人。如果智能体承担更多这类任务，他问组织将如何帮助新人获得成熟产品工程师所需的判断力。

Voss 展示一张使用 ADP 工资数据、以 2022 年 10 月为基准的美国软件开发者按年龄分组就业图。他说，最年轻组下降，而较年长组上升。图表描述的是展示的样本和时期；它本身不能证明 AI 导致了差异，也不能代表所有初级岗位市场。

他认为组织需要有意识地培养面向产品的工程师，而不是依赖偶然形成的人才管道。他引用 Google 的助理产品经理计划和类似项目作为例子，同时估计需要培养更多人。这些需求数字是他的估计。

他说，大学可能教授数据结构，训练营可能教授框架，但团队也需要能够与客户相处、理解业务并编写有用规格的人。他敦促工程负责人创造这种学习机会，而不是放弃一代新开发者。

Voss 承认，许多人因为热爱技艺而进入编程行业：简洁的抽象、解决难题的感觉，以及让机器按意图运行。他们可能不想要以采访客户为中心的工作，对这种失落他没有简单答案。

他提出，一部分创造性满足也来自理解问题并将其变成系统。他预计编程技艺会继续存在，就像家具工厂出现后木工仍然存在一样，但预测有偿岗位会越来越重视不同技能。这是他的预测，并非已确立的结果。

Voss 预测过渡会很艰难：初级岗位路径可能在新的培养方式出现前就减弱，热爱编程的人也可能不喜欢新角色。从更长远看，他预计软件行业会扩大，主要由产品工程塑造，薪酬与今天大致相当。时间和结果仍不确定。

对于现在采取行动的团队，他建议识别需要人关注的高影响变更，委派可以低成本检查的工作，并将经验丰富者的判断写进规格、评分标准和评测。他建议缩小人工审查范围，这是一项策略提议，并不能证明自动审查工具对所有较低影响变更都可靠。

他建议衡量交付情况、审查意见是否得到落实，以及测试通过与维护者愿意合并之间的差距，而不是将代码量当作目标。生产环境表现是另一个反馈来源。他最后将产品工程定义为发现需求、写下好的标准并创造人们重视的东西。