跨国深谈← 返回←20万工程师的真实数据：AI 到底给开发者提速了多少

20万工程师的真实数据：AI 到底给开发者提速了多少

关联

人物 Justin Reock

公司 DX

概念 智能体 · 开发者体验 · DORA · PR 大小 · METR · 代码生成

用 AI 写代码到底让工程师变快了多少？说这话有分量的人是 Justin Riach——开发者体验研究平台 DX 的副 CTO,他们的平台由做过 DORA 指标、Space 框架的那批人打造，这次分享基于约 20 万名工程师的数据。他的答案会泼一盆冷水：速度指标在涨，但中位数只有 7.7%,没有一家公司跑出 2 倍提升；而更麻烦的是，工程师感觉自己快了很多，实际数据却几乎没动。

速度：指标在涨，感知在虚胖

先看部署频率(DORA 四个关键指标之一，衡量交付速度的方向性指标)：稳步上升，虽然近期略有趋缓——早期一部分激增只是因为人们更频繁地提交 PR。这个指标只覆盖从创建 PR 到部署上线这一段，不反映回退率、缺陷率、变更失败率。分地区看，北美持续上行，欧洲最近一个季度有所回落，可能与 token 支出能力和监管差异有关。

但最扎眼的是「感知交付速率」：工程师觉得自己快了约 4.5%——考虑到一整年的巨额 AI 投入，这个数字低得反常。Justin 拿出那个出了名有缺陷的 METR 研究做参照：16 名工程师的实际生产率下降了约 19%,感知却上升了约 20%,感知与现实的差距高达 40%。

质量：波动剧烈，且出现一个反常的张力

变更失败率(DORA 质量指标，越低越好)变得非常波动：有的公司恶化了 2 个百分点——听起来不多，但行业基准约是 4%,等于多交付了 50% 的缺陷。Justin 强调这种分化模式在没有 AI 时也存在，根源在发布流水线和自动化测试；AI 改变的是振幅，把它推到了前所未有的极端。

更反常的是两个通常同步的定性指标分道扬镳了：代码可维护性感知上升了近 4%,而变更信心——「我相信我推上线的改动不会弄坏东西」——下降了 6%。张力就在这里：智能体和助手让我更容易理解和修改眼前的代码，但我更怕弄坏东西了，比一年前更怕。

原因之一是 PR 大小在可测量地膨胀：一年内平均从 44 行涨到 72 行，接近翻倍。多个因素叠加：模型被训练得倾向输出相对平庸的代码(平均律)；构建流水线要跑 45 分钟，没人愿意为四个函数开四个 PR 各等一轮，干脆全塞进一个。

但每多一行代码就多一个潜在 bug、一个潜在漏洞，还增加评审负担。连锁反应是：「我能做小的增量改动」这项开发体验驱动因素下降了 10%,是过去一年跌得最狠的之一——而增量交付恰恰是易回滚、易评审的基础。

谁在用，谁受益

初级工程师用 AI 最多——这不奇怪，新人需要忘掉的东西更少，一毕业就在用这类工具。但有意思的是：对同样的用例，初级开发者消耗的 token 明显更多(学习曲线)，而最终的时间节省，初级和 staff 级以上工程师基本持平——资深工程师更容易发现幻觉、理解改动周边的架构。小公司在时间节省上领先，因为组织复杂度更低、流水线更简单。

怎么度量：别扔掉老指标

「花了 1000 万 token 钱，我们的 10 倍生产力在哪？」——今年所有组织都得回答这个问题。

Justin 的核心主张：不要抛弃已建立信任的基础指标，AI 度量要做的是看 AI 如何影响这些指标。方法是把用户分组，在 PR 周期时间、PR 大小、评审推回这些基础指标上做组间对比。他给出一个三维度框架：使用率(日活/周活)→ 影响力(使用率上升后哪些业务指标在动)→ 成本(「上一次炒作周期过了 15 年我们还没搞清云成本，这次更贵，必须度量」)。

另外要度量平台的 AI 就绪度——「2024 年我们给每人配了编程助手，2025 年开始建智能体，现在才发现基础设施根本没准备好」。清单包括：清晰结构化的文档、关系直白的数据结构、模块化代码、可靠的本地 CI、不飘忽的测试套件。

听着耳熟？这就是过去的「良好开发者体验」——对人类有益的对智能体也有益，颇具悖论意味的是，我们可能终于要做那些欠了几十年的投资了。

代码生成从来不是瓶颈

为什么要把 AI 整合进整个软件交付生命周期？因为即使模型给出 100% 准确的即时代码——事实并非如此——你也只是在攻击整个价值流中约 14% 到 16% 的部分。

他们近期开展的一项研究：速度指标中位数增长仅 7.7%,平均 13%,最好的公司也只有 70% 上下。没有人达到 2 倍、5 倍、10 倍。 因为 AI 省下的时间，仍被会议缠身、上下文切换、开发环境摩擦这些非 AI 因素吃掉。

正如约束理论的 Ellie Goldratt 会说的：在非瓶颈环节节省的一小时毫无价值。得找到瓶颈、修掉瓶颈。几个正在这么做的案例：

• Zapier:用智能体生态处理站会摘要等行政开销，站会从每周五次减到两次，工程师入职缩到约两周(行业基准一个月以上)。最关键的是：每位工程师带来约 15% 的额外价值创造后，他们反而以公司史上最大规模在招人——单个工程师产能更高、回报更高，多招人就是竞争优势。Justin 点评：这是吞吐量和创新能力的故事，不是替换人头的故事。
• FAIR:每周约 3000 次由 PR 触发的自动化代码审查，只查表面问题，结果留在 PR 评论里，下一个人工审查者一眼知道智能体看过什么。
• Spotify:为 SRE 建了智能体，从 runbook 和事件上下文里汇总修复步骤推进沟通频道，事故发生时即刻有上下文，省掉几分钟的排查。

本集带走

• 感知和现实差距巨大：工程师觉得自己快了，聚合数据几乎持平；METR 研究里感知与实际差了约 40%。度量 AI 收益必须看客观指标，不能靠问卷感受。
• 盯住 PR 大小：平均 44 行涨到 72 行，每多一行就多一个潜在 bug 和评审负担——这可能是今年最值得盯的单一指标。
• 度量方法：老指标 + 分组对比：不扔掉 DORA 等已验证的基础指标，把 AI 用户分组后在这些指标上做组间比较，三个维度依次是使用率、影响力、成本。
• 别只攻代码生成：它只占价值流的 14-16%;中位数提速 7.7%、无人到 2 倍的根因是会议、切换、环境摩擦这些真瓶颈没被碰。
• 平台就绪度 = 欠了几十年的开发体验债：好文档、模块化代码、稳定测试既利于人也利于智能体，现在是补课的理由。
• 学 Zapier 的态度：人均多创造 15% 价值后加大招聘——AI 是吞吐量放大器，不是人头替代方案。

即使工程师从模型那里得到的是 100% 准确的即时代码——事实并非如此——你仍然只是在攻击整个价值流中大约 14% 到 16% 的部分。
Even if engineers are getting like 100% accurate instant code coming from the models, which they are not, you would still only be attacking anywhere from maybe 14 to 16% of the overall value stream.
—— Justin Reock · [15:04]

没有人达到 2 倍，没有人达到 5 倍，没有人达到 10 倍。
Nobody hit 2x, nobody hit 5x, nobody hit 10x.
—— Justin Reock · [15:40]

正如约束理论、《目标》的作者、《凤凰项目》灵感来源的 Ellie Goldratt 会告诉我们的那样：在非瓶颈环节节省的一小时是毫无价值的。
And as Ellie Goldratt from the theory of constraints and the goal and inspiration for the Phoenix project would tell us that an hour saved on something that isn’t the bottleneck is worthless.
—— Justin Reock · [16:09]

我现在比一年前更害怕弄坏东西。
I’m more afraid now of breaking things than I was a year ago.
—— Justin Reock · [06:49]

这背后有多种原因，但确实值得一提：每多一行代码，就多一个潜在的 bug、一个潜在的漏洞。
So there’s multiple reasons for this, but it really bears mentioning that every extra line of code is a potential bug, a potential vulnerability.
—— Justin Reock · [08:00]

现在就像，好吧，现在先把东西弄出来，而被生成的代码本质上会是平庸的，因为这是平均律。
Now it’s like, well, now let’s get the thing out and the code that’s being generated is gonna be essentially mediocre because it’s law of averages.
—— Justin Reock · [07:34]

所以在感知生产率与实际生产率之间大约有 40% 的差距。
So there was like a 40% spread in perception of productivity versus actual productivity.
—— Justin Reock · [04:25]

但事实证明，对人类有益的东西对智能体也有益，所以颇具悖论意味的是，我们可能终于要做那些过去几十年我们就该做的投资了。
But it turns out that what’s good for humans is also good for agents, so we may finally, paradoxically, be making those investments that we should have been making over the last couple of decades.
—— Justin Reock · [14:09]

我喜欢这么说：在 2024 年，我们给每个人配备了编程助手。在 2025 年，我们开始构建智能体。现在我们意识到，我们的基础设施根本没为这些东西做好准备。
I like to say that in 2024, we gave everybody a coding assistant. In 2025, we started building agents. Now we’re realizing that our infrastructure wasn’t ready for any of this.
—— Justin Reock · [13:31]

有个挺合理的笑话是：距离上一次大型炒作周期已经过去 15 年了，我们仍在试图搞清楚云成本，但这些东西正变得相当昂贵。
It’s a fair joke that we’re 15 years after the last major hype cycle and we’re still trying to figure out cloud costs, but this stuff is getting pretty expensive.
—— Justin Reock · [12:35]

这是一个吞吐量的故事。这是一个创新能力提升的故事。这不是一个替换人力的故事。
This is a throughput story. This is an increased innovative capacity story. This is not a headcount replacement story.
—— Justin Reock · [17:36]

但这个故事里我最喜欢的部分是，他们看到每位工程师带来了大约 15% 的额外价值创造，所以他们的招聘规模超过了公司整个历史上任何时期，因为他们认识到了这里的真相：他们从单个工程师身上获得了更多产能，从单个工程师身上获得了更好的投资回报，而招聘更多工程师将提升他们的竞争优势。
But my favorite part about this story is that they’re seeing about a 15% additional value creation per engineer, so they are hiring more than they have in the history of their entire company because they realize the truth here, that they’re getting more capacity per single engineer, they’re getting a better return on investment per single engineer, and hiring more engineers will improve their competitive edge.
—— Justin Reock · [17:14]

所以就原始的时间节省和这方面的总体产出而言，在更多使用这项技术的初级工程师与更容易发现幻觉、理解所做改动周边架构的 staff 工程师之间，差距相当平。
So in terms of like raw time savings and the aggregate output of this, it’s pretty flat between junior engineers who are using the tech more and staff engineers who have an easier time spotting hallucinations, understanding the architecture around the changes they’re making and things like that.
—— Justin Reock · [10:04]