当代码变便宜，瓶颈就会转移

承诺与实测结果

承诺很简单：开发者写代码更快，软件就交付得更快。DORA 第十份软件交付报告专门去找这个结果，却没有找到。2024 年 DORA 报告（调查）询问了近 3,000 名从业者的 AI 使用情况和所在团队的交付表现。它估计，AI 采用率每提高 25%，交付吞吐量降低 1.5%，并称这一影响「很小，但很可能是负面的」；它还指出「对交付稳定性的负面影响更大（AI 采用率每提高 25%，估计降低 7.2%）」。

真正引人注目的是同时改善了什么。同样是采用率提高 25%，文档质量提高 7.5%，代码质量提高 3.4%，代码评审速度提高 3.1%，审批速度提高 1.3%，代码复杂度降低 1.8%。DORA 称这一组合出人意料，因为从历史上看，这些过程指标「会带来软件交付的改善」。这一次却没有。局部指标变好了，系统整体却变差了。

DORA 给出了一个机制，并明确标注为假设：「由于 AI 让受访者能在同样时间内产出多得多的代码，变更列表很可能、甚至极有可能正在变大。DORA 一贯的研究表明，更大的变更更慢，也更容易造成不稳定。」

一年之后，图景有所变化，但只是部分变化。2025 年 DORA 报告（调查）基于 2025 年 6 月 13 日至 7 月 21 日期间的 4,867 名受访者，在报告开篇这样写道：「AI 采用现在会提升软件交付吞吐量，这是相对去年的一个关键转变。然而，它仍然会增加交付的不稳定性。这表明，团队虽然在为速度做调整，但其底层系统尚未演进到能够安全地承载 AI 加速开发的程度。」

此时的采用已接近普及：90% 的受访者在工作中使用 AI，超过 80% 认为 AI 提高了自己的生产率。对这两年的数据要仔细读。它们是针对不同人群的两次横截面调查，所以吞吐量符号的变化不是一种趋势，本书也不这样称呼它。两年都成立的是不稳定性这一发现。这才是做规划时要依据的结论：无论 AI 对速度有什么影响，迄今为止它都与更不稳定的交付相关联。

不稳定不是速度的代价。最常见的辩护是：为了更快，付出一些不稳定是可以接受的。DORA 检验了这个说法。针对「速度能抵消不稳定」的观点，2025 年报告写道：「我们没有发现这种调节效应的证据……不稳定仍然会对产品表现和职业倦怠等关键结果产生显著的不利影响」（第 41 页）。更快的交付并没有把不稳定的代价赚回来。

摩擦去了哪里：决策与核验

如果 AI 让代码的生产成本降低了，那么省下的力气流向了哪里？DORA 2025 的回答，是对本章论点最清楚的一句表述：「对个人而言，摩擦与其说消失了，不如说是转移了：它从手工苦活转向了决策与核验（deciding and verifying），形式可能是反复迭代提示词、审查结果，以及评估那些看起来与正确代码极其相似的代码」（第 40 页）。同一页还警告：「如果变更量增加，却没有相应演进出护栏、角色和『黄金路径』，核验与协调成本可能会上升。」

DORA 还有两句话点出了问题所在。第一，AI 的收益落在敲代码的地方，而不是集成的地方：「目前，AI 往往出现在键盘前，这或许能解释为什么代码质量和生产率受益，而摩擦、倦怠和不稳定却没有。后者可能超出了个人的掌控范围，更直接地取决于组织是如何搭建的」（第 39 页）。第二，收益会流失：「没有这个基础，AI 只会制造出局部的生产率孤岛，而这些收益往往消失在下游的混乱之中」（第 3 页）。

DORA 还点名了把局部收益变成不稳定的那个机制，这次是在关于版本控制的分析中：「AI 的使用还与更高程度的软件不稳定相关。我们的假设是，这很可能部分是因为更大批次的代码更难评审」（第 57 页）。更频繁地使用回退，会放大 AI 对团队绩效的作用，但报告明确指出，「依赖回退并不能直接降低不稳定」。回退能帮团队撤销已经漏过去的东西，却挡不住它漏过去。

在调查数据出来之前，实践者就已经描述过同样的形态。Google 研究博客在 2024 年 6 月介绍内部工具时写道：「代码作者越来越多地变成了评审者」（Google Research，T3）。Thoughtworks 技术雷达连续三期把「对 AI 生成代码的自满」放在「暂缓」环。2024 年 10 月，它质疑报告中合并率的上升究竟是不是好消息，还是说「人们因为过于信任 AI 的结果，而更快地合并了更大的拉取请求」。到 2025 年 11 月，它把结论推广为：「加快工作流的某一环，会增加其他环节的压力。」这是实践者的观点，不是测量结果，但诊断是一样的。

核验的负担也体现在开发者对产出的感受上。在 DORA 2025 中，30% 的人对 AI 生成代码的质量几乎不信任或完全不信任。在 Stack Overflow 2025 开发者调查（调查，约 49,000 名自选样本，其中约 33,000 人回答了信任度问题）中，46% 的人不信任 AI 工具的准确性，「高度信任」的只有 3.1%。被提及最多的困扰是「AI 给出的方案几乎正确，但又不完全正确」，占 66%；45.2% 的人表示「调试 AI 生成的代码更耗时」。几乎正确的代码，恰恰是最难核验的代码。生成变便宜时，这部分成本不会缩水；每多生成一行，它就多一分。

遥测数据里的队列

调查告诉我们摩擦去了哪里；读取客户版本控制和工单数据的工程分析厂商，则让我们看到队列是怎么形成的。他们的数据是汇总的厂商遥测，只有相关性，所以本书只采信其方向，不采信其幅度。Faros 的三份报告和 LinearB 的基准数据指向同一方向：拉取请求更多、更大，等待评审的时间更长；而在 Faros 的数据里，完全未经评审就合并的也更多。

这个方框能支撑的是一个方向，而这正是 DORA 的假设所预测的方向。生成量上去了；到达评审环节的工作变大了；它在那里等待的时间变长了；而越来越多的变更完全没经过评审就通过了。这些报告都没有测量评审的深度，所以无法说明有多少评审被推迟、被草草了事或被直接跳过。完全未经评审就合并的变更在增加，这至少说明有一部分评审被跳过了。

等待时间和实际评审时间是两个数字。并不是每家厂商都看到评审变慢。另一家分析厂商 Jellyfish（2025 年 6 月；来自 259 家公司的 216 万个已合并 PR，仅限 Copilot 用户，T3）发现，2025 年第二季度平均周期时间从 95.5 小时降到 83.8 小时，其中编码节省 8.6 小时，评审节省 5.1 小时。LinearB 自己的表格也显示，在第 75 百分位，AI 辅助（而非智能体）的 PR 比无 AI 辅助的 PR 更快通过评审，分别为 3.2 小时和 4.2 小时。

两种观察可以同时成立。队列时间和接手时间会随着智能体 PR 的数量和规模增长，而评审者在每个 PR 上实际花费的时间却可能下降，尤其是在 AI 辅助而非智能体完成的工作上。浅层评审或跳过评审是第三种解释，而未评审合并的数据表明，至少「跳过」并非假想。实际的结论是：「评审时间」不是一个指标。如果你只测量实际评审投入，你可能看着它下降，而它前面的队列却在变长。要把等待时间和实际评审时间分开测量，把智能体 PR 和 AI 辅助 PR 分开测量。第 7 章《代码评审》在设计评审流程本身时会回到这一点；本站关于智能体产出的评审队列的笔记讲解了队列的运作机制。

阿姆达尔算术

编码提速之所以无法单独撑起交付，有一个结构性原因，而且不需要任何调查来证明：编码只占从想法到发布这段时间的一小部分。贝恩 2025 年技术报告（咨询公司，基于调查）说得很直白：「编写和测试代码只占从最初想法到产品发布这段时间的约 25% 到 35%」。Atlassian 2025 年开发者体验调查（厂商调查，自报）覆盖 3,500 名开发者和管理者，发现「开发者只有 16% 的时间在编码，而编码并不是开发者的摩擦点」。同一份调查还直接呈现了抵消效应：68% 的受访者说 AI 每周为他们节省 10 小时以上，而 50% 的人说每周有 10 小时以上耗在非编码事务上，报告把这主要归因于组织低效。在键盘前赢回的时间，又在别处花掉了。DX（厂商，T3）援引微软研究院的一项研究，估计编码约占开发者时间的「14% 左右」。这几个数字测量的东西不同（占交付周期的比例，还是占开发者一周时间的比例），也都不精确，但说的是同一件事：大部分时间花在编辑器之外。

阿姆达尔定律把这一点变成了一个上限：如果某一段只占总体的一部分，那么只给这一段提速，能省下的时间永远不会超过这一部分。下面的算例是示意性算术，背后没有任何真实组织：交付周期为 100 个单位，其中编码（贝恩所说的「编写和测试」）占 30，评审占 10。

Illustrative arithmetic. Lead time = 100 units.

Scenario                               Coding  Review  Rest   Total  Change
A. Baseline (coding = 30%)              30.0    10.0   60.0   100.0     --
B. Coding 2x faster                     15.0    10.0   60.0    85.0  -15.0%
C. Coding infinitely fast                0.0    10.0   60.0    70.0  -30.0%
D. As B, review time +91%               15.0    19.1   60.0    94.1   -5.9%
E. As D, but coding = 16% at baseline    8.0    19.1   74.0   101.1   +1.1%

Review +91% = 10.0 x 1.91 = 19.1 (the Faros 2025 review-time figure,
used here only as an illustrative input).

B 行是厂商的推销话术：编码速度翻倍，交付周期缩短 15%。C 行是上限：即使编码速度无限快，交付周期最多也只缩短 30%，因为另外 70 个单位纹丝不动。D 行假设更大的批次让评审时间增加 Faros 2025 年报告的高采用率团队的 91%——这个厂商数字在这里只作为输入，而不是测得的结果。评审就从 10 个单位涨到 19.1，多出的 9.1 个点吃掉了 15 个点收益中的大半。E 行把编码占比换成 Atlassian 报告的 16% 再算一遍（这是把占一周工作时间的比例当作占交付周期的比例来用，两者其实并不相同）：编码只省下 8 个点，评审增长仍是 9.1 个点，整个系统反而比引入 AI 之前略慢。

这些数字故意取得很简单，真实系统还有更多环节（测试、CI、发布、等待决策）也可能变长。但无论输入怎么取，形态都不变：只在少数环节内的提速有硬性上限，而它下游任何环节的增长，都要从这个上限里扣除。Faros 在自己的报告里也引用了同一定律。贝恩得出了同样的结论：「如果 AI 加快了编码，那么代码评审、集成和发布也必须同步加快，才能避免瓶颈。」本站关于人工评审成本的页面讲解了这笔下游开支如何定价，而经济性、风险与度量一章会搭建完整的成本模型。

阶段层面的证据：当生成不再是约束

调查和遥测描述的是整个组织。约束发生转移的最有力证据，来自那些在单一阶段内大力推动 AI 生成、并记录下是什么限制了自己的团队。下面两个公司案例的答案都是评审，而 DX 的跨公司数据显示了同样的上限。

Google 的迁移主动给生成限流。Google 工程师用一条 LLM 流水线把测试代码从 JUnit 3 迁移到 JUnit 4：三个月内完成 5,359 个文件、超过 149,000 行代码（Nikolov 等，2025，T2）。团队生成变更的速度超过了人工评审的速度，于是限制了每周提交的变更列表数量，以免压垮评审者。作者也明确指出，模型并不等于整个系统：「仅靠 LLM 和简单的提示词，除了最简单的迁移之外，什么都做不了。」决定节奏的，是模型周围的流水线和评审其产出的人。案例研究一章会完整解读这次迁移。

Spotify 直接把话说了出来。Spotify 工程博客回顾其首席架构师 2026 年 6 月一场大会演讲的文章，直接以本章的论点为题：《编码不再是约束》（Coding is no longer the constraint）。超过 99% 的 Spotify 工程师每周使用 AI 编码工具，94% 表示自己生产率更高了（截至 2026 年 6 月）。拉取请求频率提高了 76%，文章用一句话点出了后果：「另一面是：我们现在要评审的 PR 多了 76%。」（The flip side: we now have 76% more PRs to review.）文章没有说评审能力相应增加了；进入评审的工作增加 76% 而评审能力不变，这正是上一节的队列，只不过是从一家公司内部看到的。Spotify 还拥有公开记录中最有力的 L3 维护案例之一，即其后台编码智能体 Honk（本站在后台编码智能体中介绍了这一模式）。即便是走到这一步的公司，它报告的约束也是评审，而不是生成。

DX 的纵向数据显示，跨公司也存在同样的上限。另一家工程分析厂商 DX 从 2024 年 11 月到 2026 年 2 月追踪了 400 多家公司。AI 使用量增长了 65%，PR 吞吐量的中位数增长了 7.76%。它自己的解读是：「AI 是一个局部优化器」，并且「全局优化需要修复代码周围的人和系统流程」。

把这三个案例放在一起，模式是一致的。在大力推动生成的地方，最先饱和的是必须阅读结果的那个人。使用量增长 65%，换来的是个位数的吞吐量中位数增长；一次本可以跑得更快的迁移，被压在评审速度上；一家几乎全员采用 AI 的公司，把新问题报告为评审量。生成侧的收益是真实的，系统侧的收益却受制于核验——这正是本站概念页生成-核验落差讨论的主题。

一次看起来成功的试点

如果约束在下游，那么只统计上游产出的试点，就会在系统原地踏步时报告成功。公开记录中有一个案例恰好展示了这一点。

斯坦福大学软件工程生产率研究组展示了基于 600 多家公司、10 万多名工程师 git 历史的研究结果（Denisov-Blanch，2025 年 9 月演讲幻灯片，T3）。数据中的一家匿名公司引入了 AI 编码助手。它的拉取请求数量增加了 13.6%。但按该研究组经质量调整的指标衡量，「有效产出」只增加了 1%。代码质量下降 9%，返工增加到原来的 2.6 倍（p < 0.01）。幻灯片提出了每个试点负责人都该问的问题：「这是一次失败的 AI 编码助手试点吗？」

这个案例是匿名的，方法也未公开，所以它只能作为示例，而不是统计结论。它示范的正是本章所预言的度量陷阱。按 PR 数量评判，这次试点会被宣布为一次 13.6% 的胜利并推广开来；按经质量与返工调整的产出评判，同一次试点几乎打平，还要背上 2.6 倍的返工。两种结论之间，工具没有任何不同，不同的只是指标。

同样的落差也出现在大公司的最高层。在 2025 年 6 月的一次访谈中，Google 首席执行官把使用 AI 生成建议的代码占比（按 Google 此前的说法约为 30%），与他所说的「最重要的指标」区分开来：工程速度，估计提升了 10%，他称之为「很难衡量的指标」，此外没有公布任何定义（Lex Fridman 播客文字稿，T4）。数量指标和流动指标回答的是不同的问题。本书从不拿前者作为后者的证据。第 17 章《衡量成效，以及何时回退》会说明，你每改变一个阶段，应当把哪些流动指标和稳定性指标配对使用。

约束接下来会去哪里

本章的证据有力支持一个论断：一旦生成变得便宜，约束就落在核验上。首先是评审，其次是测试，再次是更大批次的集成与发布。DORA 把摩擦放在这里，厂商遥测在这里看到了队列，迁移团队也在这里碰到了极限。

下一个候选约束就没那么确定了，本书如实说明这一点。决定做什么——即需求、规格和产品判断——被认为是紧随核验之后的约束。DORA 的能力模型为这一观点提供了最有力的支持：「在缺乏以用户为中心的情况下，AI 采用会对团队绩效产生负面影响」（2025 年报告，第 60–61 页）。前面那句关于摩擦的引文，也把「决策」与「核验」并列。但在本书的证据库中，没有任何研究测量过需求在 AI 辅助组织中是决定性约束。请把它当作一个有道理的预期，而不是一项发现。

DORA 给出的对策，是在决定把 AI 用在哪里之前，先找到真正的约束。它的价值流一章直接举了例子：一个团队「可能通过价值流映射发现，代码评审是一个重大瓶颈。有了这一洞察，他们就可以决定用 AI 来改进代码评审流程，而不是用 AI 去单纯生成更多代码——那只会让瓶颈更加恶化」（第 74–76 页）。这句话就是本章论点的实践版本：给非约束阶段提速并不能提高产出，只会让真正的约束阶段前面的队列更长。

DORA 自己的能力模型也指向同一方向。小批量工作放大了 AI 对产品表现的益处，并降低了摩擦，但它有一个明确的代价：「在以小批量方式工作的团队中，AI 采用对个人效能的益处会略有降低。」这笔交换值得做。个人收益略微变小，是让每一次变更都保持可评审的代价。

下一章的成熟度模型把这一点变成一条经验法则，并在那里标注为本书的提议：编码阶段的级别最多比评审和测试两者中较低的那个高一级（见成熟度模型的规则）。支撑它的是上文那些相关性遥测数据和 DORA 的批量大小机制，所以它是一条启发式规则，而不是定律。但它的逻辑就是本章的逻辑：跑在核验前面的编码阶段，会带来更多的 PR、更大的 PR、更长的评审、更多的未评审合并，以及更多的不稳定。第 7 章《代码评审》和第 8 章《测试与验证》会说明如何先把核验类阶段提上来。本站的文章AI 原生 SDLC 的产物链梳理了每个阶段的产出如何成为下一阶段的输入。