Synthesia AI 代码审查揭示更快生成的代价

尽管拉取请求增长了 120%，Synthesia AI 代码审查正揭示一个尖锐矛盾：更快地生成代码并不会消除工程工作，只会将其转移至下游。

Synthesia 表示，其如今 95% 的拉取请求都包含 AI 生成代码，但绕过人工审查的变更不足 5%。这些数字概括了大规模采用编程智能体的工程组织正在面临的问题。

新的瓶颈不再是编写代码，而是判断生成的代码是否符合预期设计、是否适配现有系统、能否处理异常情况，以及部署后是否依然安全。

这种变化迫使工程负责人重新设计整个审查流程。Amazon、AWS、Bonterra、IBM、Making Sense 和 Temporal 都在测试同一理念的不同变体：自动化应处理常规检查，而人仍应保留对重要决策的最终权力。

这种分工听起来很高效，但也带来了一个棘手的问题：如果一个 AI 系统编写代码，另一个 AI 系统审查代码，负责该变更的工程师凭什么证据才能信任其中任何一个？

Synthesia AI 代码审查揭示新的瓶颈

AI 生成代码提升生产能力的速度，已超过企业提升验证能力的速度。

Synthesia 的 118 名工程师于 2025 年 11 月在整个工作流程中采用了 AI 编程工具。根据 CTO Peter Hill 的说法，到 2026 年 8 月，拉取请求数量较上年增长了 120%。

拉取请求是指在合并到主代码库之前，由另一名工程师或自动化系统检查的拟议变更。更多拉取请求可能意味着更高产出，但每项请求也会带来测试、审查、协作和维护工作。

Synthesia 的变化并不只是由自动补全工具完成的小型建议。Hill 在接受原始报道时表示，公司 95% 的拉取请求包含 AI 生成代码。

这一规模暴露出反复出现的弱点。编程智能体可能创建一个函数，却没有意识到代码库其他位置已经存在相同能力。有限的上下文随后会让一个实现演变为多个相互竞争的版本。

据报道，Synthesia 曾发现同一函数多达 10 个版本。工程师必须找出重复项，决定哪个实现应保留在产品中，移除其余版本，并教会智能体不要重犯同样的错误。

单独看时，每个生成的函数都可能显得合理。只有理解更广泛系统的人，才能发现其中的缺陷。这一区别解释了为何通过表面检查的代码，仍可能增加技术债务。

技术债务是当前软件中的捷径、不必要复杂性或薄弱设计选择所造成的未来工程工作。AI 无需生成错误语法就能制造技术债务；模型只需生成在局部看来合理、却与整体架构冲突的代码即可。

Hill 将在公司规模下获得预期输出形容为一项极其庞大的工作。他还质疑，团队是否能真正完全信任智能体生成的代码。

这种怀疑并未阻止 Synthesia 使用编程智能体。相反，公司会根据风险分配人工注意力。修改错误提示信息所受的审查会少于涉及客户数据或核心业务规则的变更。

即使经过这种分级处理，超过 95% 的变更仍会接受人工审查。公司在获得生成能力的同时，仍在绝大多数部署环节保留人工关卡。

同样的紧张关系也出现在整个行业。Sonar 调查了超过 1,100 名专业开发者，发现受访者认为其已提交代码中有 42% 来自 AI。

不过，根据这项开发者调查，96% 的受访者并不完全信任 AI 生成代码能够正确运行，只有 48% 表示自己总会在提交前验证 AI 辅助生成的代码。

不信任与持续验证之间的差距，比原始采用率更值得关注。这表明，一些组织生成代码的速度可能已经超过其控制机制的评估能力。

38% 的受访者表示，AI 生成代码所需的审查工作多于同事编写的代码。61% 表示，生成的代码经常看似正确，却并不可靠。

这些发现并不能证明每一项 AI 生成的变更都更差。Sonar 销售代码验证产品，其调查反映的是受访者报告的经验，而非受控生产环境中的测量结果。

尽管如此，这些数字与 Synthesia 及其他公司的运营经验相吻合。代码生成加速了，但信心并未以同样速度提升。

更快编程将工作推向下游

当组织衡量的是生成的代码而非交付给用户的可靠软件时，生产力承诺就会减弱。

编程智能体可以在数分钟内生成数千行代码。然而，代码行数几乎无法说明这项变更是否应该存在、能否正确集成，或是否解决了所提出的问题。

Amazon 在现代化其移动购物应用背后长达 17 年的代码时，遇到了这种区别。高级首席工程师 McLaren Stanley 与一个 70 人团队合作，该团队为超过 1,000 名开发者提供支持。

Stanley 描述过这样一个案例：智能体使用错误版本的 Swift——Apple 的编程语言——生成了 25,000 行代码。转换这份输出后出现了 600 个错误，智能体无法一并解决。

团队没有逐行修复，而是丢弃了生成的代码。Stanley 更新了规格说明，即定义智能体应构建什么、应如何运行的详细计划。

据报道，在这一修正后，智能体在 15 分钟内正确重新生成了代码。这一事件展示了生产力论点的两面。

智能体恢复的速度快于人工重写 25,000 行代码。但由于遗漏了一项重要约束，它起初还是生成了一项庞大却无法使用的变更。

生成速度放大了计划本身的质量。不完整的规格说明以异常规模造成失败；修正后的规格说明则迅速产出了可用结果。

这种关系改变了高级工程师投入时间的方式。在智能体开始实现之前，他们必须定义架构、约束、接口、验收标准以及禁止行为。

工作从用编程语法表达每一条指令，转向构建并维护一份可执行的计划。即使编辑器中的按键更少，这仍然是软件工程。

关于整体生产力的独立证据仍然不一。一项 2025 年的 METR 随机试验研究了 16 名经验丰富的开源开发者，他们在熟悉的代码库中完成了 246 项任务。

根据这项生产力试验，当可以使用 2025 年初的 AI 工具时，这些开发者完成任务的时间反而增加了 19%。参与前，他们预计 AI 会让自己快 24%。

事后，他们仍认为 AI 让自己的工作提速了约 20%，但测量结果指向了相反方向。

这项研究样本较小，聚焦于在熟悉、成熟代码库中工作的资深开发者。METR 明确警告，不应将结果推广到所有开发者、工具或编程环境。

在陌生系统中工作的开发者，可能从 AI 的解释和代码库导航中获得更多价值。更新的模型和更好的智能体工作流程也可能改变结果。

METR 承认，后续工具很可能带来更大收益。这项研究仍有价值，因为它区分了感知到的速度与实际测得的完成时间。

当开发者看着智能体产出可见结果时，可能会感觉自己更快了。提示和审查也可能比手动完成同一变更更不令人疲惫。

但这两种感受都无法保证正确的变更会更早进入生产环境。等待、纠正误解、阅读生成内容和清理不必要代码所花的时间，同样应被计算在内。

一项较新的企业现场研究给出了更乐观的结果，但附带重要限定。研究人员考察了 2024 年 1 月至 2026 年 4 月期间的 802 名开发者和 196,212 个拉取请求。

在所研究的公司中，每位开发者的吞吐量最终达到采用前基线的 2.09 倍。研究人员提醒，采用并非随机分配，因此他们无法将全部收益直接归因于 AI。

更重要的是，该组织的审查系统也随着生产发生了变化。每位审查者的负载大致翻倍，自动化审查超过了人工审查，而合并率和回滚率保持稳定。

这些证据支持一个比“AI 将工程生产力翻倍”更狭窄的结论：当组织重新设计审查流程，并积累使用工具的经验时，高产出才能变得可持续。

价值的核心单位不是生成的代码，而是能够经受审查、交付给用户、避免事故并保持可维护性的变更。

计划与审查智能体成为控制层

应对 AI 代码杂乱问题的最有力方式，始于生成之前，并贯穿分层、基于风险的审查。

企业正在围绕编程智能体构建控制层。这一层结合了规格说明、自动化测试、安全检查、策略执行、置信度信号和人工升级处理。

规划必须先行，因为单靠审查无法高效挽救一个框定不当的任务。精确的规格说明会在智能体生成大型变更之前收窄其选择范围。

规格说明应明确预期行为、相关组件、架构限制、数据约束和验收测试，也应描述失败条件和异常输入。

这种方法不只是改进提示词。它还创建了一个自动化审查者和人工审查者都可用于评估结果的参照依据。

没有获批计划时，审查者必须在阅读实现的同时推断作者意图。当名义上的作者是一个在当前上下文之外没有稳定理解的智能体时，这项工作会更加困难。

有了计划，审查问题就变得更具体：实现是否符合已达成一致的设计，还是智能体另行编造了一种解决方案？

据高级首席工程师 David Yanacek 介绍，AWS 使用专门的智能体执行早期检查。这些智能体会测试代码是否正常工作、将其与原始计划比较，并在人工审查前寻找安全问题。

这种分层工作流程将 AI 审查视为过滤机制，而非最终权威。机器处理重复阅读和结构化比较；人则判断模糊的权衡，并承担责任。

Bonterra 在审查工作量急剧增加后采用了类似模式。这家非营利软件提供商拥有约 290 名工程师。

据 CTO Tanuja Korlepra 表示，采用 AI 后的三个月内，拟议变更数量增长至原来的三倍。进入审查的代码量增加十倍，而审查时间增加三倍。

这些数据说明，传统的逐行审查无法无限吸收生成式输出。新增一个编程智能体，带来的产出增长速度可能快于企业招聘资深审查人员的速度。

Bonterra 的审查智能体会将拟议代码与已批准的设计、安全要求、编码标准和无障碍规则进行比对，同时给出置信度评估。

较低的置信度评分或被标记的问题，会将变更转交给人工处理。涉及支付、个人信息或其他敏感系统的代码始终需要人工审查。

这种方法将风险作为分配稀缺注意力的依据。它并不宣称自动化审查能让每一项低风险变更都完全正确。

基于风险的分流机制关注的是：故障会在哪些地方造成最严重的损害。团队随后便可将有限的人工注意力投入最需要上下文和责任承担的环节。

关于智能体编写的拉取请求的研究表明，结构性信号可能有所帮助。一项 2026 年的审查工作量研究分析了 2,807 个代码库中的 33,707 个由智能体生成的拉取请求。

研究人员发现，28.3% 的拉取请求在一分钟内完成合并，反映出这些变更范围较窄、几乎不需要互动。其他请求则进入了更长的审查周期，智能体有时会停滞，或不再回应反馈。

研究人员构建了一个模型，用于在拉取请求创建时识别其中工作量最高的 20%。该模型利用结构性信号，在这一审查预算内捕捉到了总审查工作量的 69%。

该模型在基于时间的评估划分中取得了 0.957 的曲线下面积得分。该得分衡量分类器区分高工作量变更与低工作量变更的能力。

文本描述带来的额外预测价值很有限。智能体实际改动了什么，比它们如何描述自己的工作更重要。

这一发现进一步支持尽早审查变更结构。文件数量、代码量、配置变更、依赖影响范围和架构扩散程度，都可以在任何人讨论代码风格之前揭示风险。

不过，有效的控制层需要让生成与评估彼此独立。让同一个模型批准自己引入的假设，可能会重现原有的盲点。

除基于模型的审查外，团队还需要确定性测试、静态分析、安全扫描器、代码库策略以及人工领域知识。每一种控制手段都能捕捉不同的失效模式。

文档也成为了运营基础设施。编程智能体无法遵循仍然分散在会议记录和个人记忆中的架构决策、所有权规则或过往事故经验。

工程知识库可以帮助团队保留这些上下文。它应当支持审查流程，而不是取代权威测试或代码库控制机制。

人工审批不能沦为表演

当工程师在不理解生成代码底层设计的情况下，仅凭功能可用就予以批准时，审查便会失效。

软件咨询公司 Making Sense 的首席 AI 架构师 JD Raimondi 将这种结果称为“表演式审批”。审查者确认某项功能看似可用，粗略浏览实现后便予以批准，却不了解背后的决策。

这个问题在生成式 AI 出现之前就已存在。大型拉取请求、交付期限压力、所有权不清晰和表面化测试，长期以来都在削弱审查质量。

编程智能体提高了风险，因为它们能以不同寻常的速度产出颇具说服力的实现。整洁的格式和自信的解释，可能让薄弱的假设更难被发现。

智能体可能通过可见测试，却无法正确处理罕见输入。它也可能引入与公司政策冲突的依赖，或复制大型代码库中其他位置隐藏的逻辑。

它还可能在不引发明显功能故障的情况下削弱安全性。授权边界、数据保留规则、竞态条件和不安全的默认设置，需要的不只是一次快速演示。

Temporal 的做法是要求提交代码的工程师为智能体生成的工作辩护。根据其“Send Back”政策，工程师必须用自己的话解释设计选择。

他们还必须说明代码如何处理异常情况。如果做不到，审查者将拒绝该提交。

CEO Samar Abbas 直截了当地概括了这一政策：“我们拒绝让代码审查成为未经核查的模型输出的倾倒场。”

这项规则改变了调用智能体者面对的激励。生成更大的补丁，不再意味着可以把所有理解成本转移给别人。

提交者必须建立足够的理解，才能回答问题并对结果负责。这一要求抑制了投机性的代码堆量，也鼓励更小、更经得起辩护的变更。

它也保留了责任归属。AI 智能体无法参加事故电话会议、解释监管违规，或决定高风险部署是否应继续进行。

即使机器完成了大部分阅读工作，人的责任仍然不可或缺。问题在于，组织是否给予审查者足够的时间、上下文和权限来履行这一责任。

Google 的交付研究发现，采用 AI 与更高的软件吞吐量和更大的交付不稳定性同时相关。该报告将 AI 描述为周边系统的放大器。

强大的测试、清晰的平台、快速反馈和健全的文档，可以将增加的生成能力转化为有价值的产出。薄弱的控制则可能让同样增加的代码量成倍放大缺陷和混乱。

这种框架避免了两种常见的夸大说法。AI 生成的代码并非天然不安全，自动化审查也并非天然足够。

结果取决于围绕这两套系统设计的工作流程。只衡量被接受的建议或生成代码行数的团队，可能会忽略后续返工。

更强的衡量体系会追踪变更合并之后的表现。有效指标包括逃逸缺陷、部署失败、安全发现、回滚频率、审查时间和维护工作量。

团队还应区分低风险自动化与影响重大的产品逻辑。更新自动生成的文档，与修改支付授权所承担的风险并不相同。

风险分类仍可能失效。对共享认证辅助工具的一项小改动，可能比对独立工具的一次大规模更新带来更广泛的后果。

这就是为什么不能仅凭代码行数决定审查力度。审查系统需要所有权地图、依赖信息、历史事故数据，以及对敏感边界的理解。

自动审查者也会引入自身的噪声。如果智能体用低价值警告淹没开发者，人们可能会逐渐习惯性地忽视警报。

警报疲劳会将技术控制变成另一种形式的表演。审查系统看似严密，重要发现却消失在日常评论中。

因此，公司需要衡量自动化发现的准确性和实用性。审查智能体应降低人工搜索成本，而不是制造一个无人能够负责任清理的新队列。

审慎的结论很直接。AI 辅助审查可以帮助管理 AI 生成的代码量，但现有证据并不支持从高风险变更中移除人工责任。

初级工程师培养体系面临另一种风险

如果智能体吸收了原本用于培养初级工程师的工作，公司就必须有意识地重建从新手到可信赖审查者的成长路径。

初级开发者传统上通过实施工作培养判断力。他们追踪现有代码，进行范围可控的变更，获得详细反馈，调试故障，并逐步开始处理更大型的系统。

其中许多任务都很适合交给编程智能体。它们边界明确、重复性高，也便于资深工程师描述。

自动化这些工作可以改善短期产出，但也可能剥夺新人学习抽象如何失效、规范为何存在，以及生产系统将复杂性隐藏在何处的实践机会。

初级工程师无法仅靠批准自己尚未理解的代码，成为可靠的审查者。阅读生成式输出会有所帮助，但被动检查无法完全取代构建、破坏和修复软件的过程。

据报道，Making Sense 在初级工程师群体中观察到了一些最大的 AI 生产力提升。这家咨询公司也担心，当智能体处理实现工作时，这些员工将不再学习什么。

其应对方式是，让初级工程师继续参与决定客户为什么需要某项功能，以及该功能应如何运作。他们参与问题定义，而不是只接收一个待检查的 AI 生成结果。

IBM 正在尝试另一种方式。据该公司自动化与 AI 总经理 Neel Sundaresan 介绍，新工程师会更早获得难度更高的任务。

AI 协助完成实现和测试。当系统失败时，初级工程师必须先诊断问题并修正它，之后才能获得资深工程师批准。

Sundaresan 估计，AI 可以帮助初级工程师完成过去通常与资深开发者相关的部分任务中的 70% 至 80%。这一数字是高管估计，并非独立的生产力测量结果。

关键在于随之而来的责任。初级工程师仍要调查故障，而不是把智能体当作不容置疑的来源。

Synthesia 主要招聘中级和高级工程师。经验较少的员工会与一名资深同事及一个 AI 智能体协作，同时负责项目中界定明确的部分。

Bonterra 也改变了初级工程师的发展方式。智能体如今承担了许多过去作为培训任务、定义清晰的工作。

该公司转而要求初级工程师与有经验的同事共同对结果负责。他们学习如何指挥智能体、质疑结果，并继续对交付行为负责。

Korlepra 直白地概括了长期担忧：“如果行业停止招聘初级人才，行业就会停止培养高级人才。”

这一培养体系问题不会立刻出现在交付仪表盘上。公司可以减少初级岗位招聘，同时在若干个季度内仍提高产出。

成本会在之后显现：当公司需要理解遗留系统、生产事故、客户约束和架构历史的工程师时。这些能力需要通过长期积累的实践接触来发展。

因此，组织需要在吞吐量指标之外设置培训信号。他们应追踪初级工程师能否解释变更、诊断故障、编写测试，以及处理日益模糊的任务。

审查参与也需要结构化安排。让初级工程师在缺乏上下文的情况下审查一个庞大的智能体生成补丁，培养的是耐力，而非判断力。

更小的变更能形成更好的学习循环。清晰的规范、有限的范围、可观察的测试和来自资深工程师的直接反馈，可以让新人将意图与实现联系起来。

事故复盘则提供了另一种重要课堂。工程师会了解那些看似无害的决策为何会造成运营故障，以及防护措施应如何调整。

公司可以将这些经验纳入培训和智能体上下文。不过，人的学习目标应当保持明确，而不应沦为工具部署的副产品。

未来的高级工程师可能会花更多时间指挥和评估智能体。这使基础知识变得更重要，而不是更不重要。

判断力需要对系统形成心智模型。没有构建这一模型的经验，审查者只能评估生成代码看起来是否熟悉。

因此，初级工程师培养体系也是 AI 代码审查问题的一部分。公司必须同时培养可靠的软件，以及能够识别自动化何时出错的人。

三个信号将表明新工作流程是否有效

下一阶段将取决于生产稳定性、评审经济性，以及人类专业能力的发展。

第一个信号是，更高的拉取请求量是否能在不增加故障的前提下提升交付效率。企业应公开发布或在内部跟踪部署频率，并将其与回滚、遗漏缺陷、事故和安全问题并列衡量。

稳定的回滚率令人鼓舞，但它并不能反映所有维护成本。重复逻辑和架构漂移可能在生产环境中长期存在，直到引发可见事故才会暴露。

如果吞吐量提升，而可靠性和维护成本保持稳定，重新设计的工作流程就更具可信度。如果评审队列和返工持续扩大，生成式 AI 只是转移了约束环节。

第二个信号是，基于风险的评审是否能在不削弱问责机制的情况下减少人工投入。Bonterra 和 Synthesia 正根据变更敏感度进行分流，而 AWS 则使用智能体执行初步检查。

有价值的证据应包括：工程师采纳了哪些自动化发现、哪些缺陷最终漏过，以及所谓低风险变更后来需要修复的频率。

评审延迟之所以应当下降，是因为自动化消除了常规工作，而不是因为人们在未充分理解代码的情况下批准了更多改动。Temporal 对说明理由的要求，提供了一项检验真实理解程度的方法。

如果工程师能够为生成的设计辩护，同时减少机械式检查所花费的时间，那么 AI 代码评审就在发挥实际作用。如果批准流程沦为例行仪式，工作流就是失败的。

第三个信号是，初级工程师是否仍能成长为能够独立承担技术责任的人才。企业应关注晋升准备度、调试表现、事故参与情况，以及初级工程师能够负责任地完成的任务复杂度。

短期产出增长无法弥补资深评审者供给的萎缩。每一项被自动化替代的培训任务，都需要有具备真实后果和反馈机制的学习闭环作为补充。

Synthesia 的 AI 代码评审表明，编码智能体本身只是其中一个组成部分。规格说明、代码库上下文、自动化检查、升级政策、人类解释以及职业发展，共同决定最终结果。

工程领导者现在应提出一个比“AI 生成了多少代码”更困难的问题：有多少经过验证、可维护的软件真正交付给了用户？团队评判下一项变更的能力是否也得到增强？

能够回答这两个问题的组织，才拥有生产力提升的证据。无法回答的组织，则会继续更快地产出代码，同时在下游不断积累不确定性。