AI编程提速了，为什么工程效率没有？

我们很高兴你在这里。你可以期待 TNS 最好的内容从周一到周五每天送达，让你紧跟新闻、保持最佳状态。

查看收件箱中的确认邮件，在那里你可以调整偏好设置，甚至加入其他群组。

在你最喜欢的社交媒体上关注 TNS。

在 LinkedIn 上成为 TNS 粉丝。

在等待你的第一封 TNS 时事通讯时，看看最新的精选和热门故事。

AI 非常擅长让个体变得更快，但周围的系统却把所有事情拖慢回来。这个结果——或者说缺乏结果——随着公司规模和 PR 规模的增大而放大。到目前为止，尽管大多数公司的 AI 投资增长了 28 倍，尤其是那些拥有超过 99 名工程师的公司，但速度指标却停滞不前甚至下降。

这是 DX 最近发布的《工程领域 AI 影响现状》中的一项发现，该报告从速度、效率、质量和影响四个维度衡量工程组织。

DX 副 CTO Justin Reock 告诉 The New Stack：“这很令人担忧，因为当成本增加了 28 倍——实际上，唯一呈指数级增长的指标就是成本——而速度并没有呈指数级增长时，我们并没有在 exponential 地交付更多。”

尽管 AI 支出持续飙升，但创新比率——用于新功能工作的工程精力与维护、琐事和运营开销之间的分配——仍然持平。这意味着 AI 并没有解放工程师的时间去处理有趣的业务解决方案，报告指出。

行业在 agentic 和 AI 开发者工具上投入了多得多的资金，同时也进行了裁员，却没有看到效果？继续阅读，我们将深入探讨这些令人不安的指标。

开发者体验趋势在下降吗？

“有可能我们仍处于这个拐点，很多节省下来的时间仍然花在技术债务、积压的事情上，这些可能不一定会被标记为新功能，”Reock 说，他仍然乐观地认为 AI 成本和收益之间的差距只是成长的痛苦。

“但话说回来，在开发者体验方面，报告中代码可维护性和变更信心之间的特定张力也让我感到担忧。”

这两个驱动因素构成了开发者体验指数（DXI）基准：

• 代码可维护性 – 我对修改代码感到舒适。我能理解摆在我面前的代码。
• 变更信心 – 我有信心，当我向生产环境发布代码时，不会破坏任何东西。

Reock 解释说，传统上代码可维护性和变更信心是正相关的，因为前者让工程师更放心地将后者发布到生产环境。

“AI 让理解你面前的代码变得更容易，甚至修改它也更容易。但变更信心现在处于负面区间，”他说。“我们更害怕发布代码了。所以我们能理解代码、维护代码、查看代码，更容易地对代码做出修改。但我们对自己发布的内容信任度降低了。”

这正在造成更多损失。他解释说，每提高一点 DXI，每个工程师每年可以返还十个小时。这是 DX 首次目睹该指标在全行业范围内下降了两点。

AI 是企业圆孔中的方钉吗？

DX 发现，较小的组织在 AI 上投入更多并从中获得更多，而遗留软件组织正在努力看到任何投资回报。

微咨询公司 a2bic.ai 的 CTO Martin Davidson 将这一点发挥到了极致：他和他的联合创始人，加起来大约 80 年的经验，可以驾驭 AI 代理团队来完成 100 名初级到中级工程师的工作。

“小型组织不必支付随组织规模恶化的非线性协调和沟通税。记住《人月神话》：沟通渠道增长为 n(n−1)/2，所以一个 10 人的团队有 45 个沟通开销渠道，”Davidson 向 The New Stack 解释道。“这三个人实际上只是为了保持一致。但一旦你只有一到两个人，沟通成本就消失了。随着中层管理被削减，组织各层级的月度全体会议变得不再需要。”

在人员、流程和技术方面，中大型组织正在试图将 AI 融入或塞入现有系统。AI 是一场根本性的技术和运营范式转变。这就是他所说的改造问题，其中一些结构已经不再适合目的。

“你无法进行改装。我们有一些流程和结构是在编写代码成本高昂的年代设计的。这已不再是事实——编写代码现在基本上是免费的，但我们仍然坚持旧的结构。而它们并不便宜，”Davidson 继续说道。“公司结构就像建筑——在某个时刻你意识到它们不再适合目的，需要从零开始拆除重建。”

当然这不是一个新问题。这与阻碍绝大多数企业全面迁移到云的推理相同。

正如 Davison 所写：“也许获胜的公司不会是那些成功转型的公司。也许赢家将是那些全新起步、不受束缚的公司。如果你身处一个遗留组织中，这很不舒服。如果你正在经营一个，那可能更不舒服。”

值得庆幸的是，AI 非常擅长模式识别，使其在揭开遗留系统的神秘面纱、将它们迁移到云端以及用 AI 思维重写它们方面非常有用。

AI 加剧了代码膨胀

当然，许多团队——以及他们的 prompts——正在以 AI 的速度忽略普遍接受的成功模式，包括较小的批次规模如何有助于更稳定的发布。

DX 报告发现，2025 年 7 月，中位 PR 规模为 42 行代码，而一年后为 72 行代码。

此外，在过去一个季度测量的所有 DXI 指标中，增量交付——工程师报告他们可以从事小的增量工作——受到的冲击最大。

“这带来了各种前瞻性好处——回滚、更少的审查、更易理解的文档、更好的单元测试用例，就像所有这些东西，”Reock 说。“我认为，这与 PR 规模的关联，对质量来说也令人担忧。”

而且不仅仅是 DX 发现了这些令人担忧的趋势。LinearB 的 AI 工程生产力差距报告将 253 个组织按 AI 使用情况分为四个类别。本周发布的这项研究发现，较小的 pull request 规模直接关系到更成功的 AI 采用。位于前 10% 的“精英组织”的平均 pull request 少于 100 行代码，而处于底层、需要重点关注的组织，其 pull request 超过 228 行代码。

你能改进你无法衡量的东西吗？

DX 和 LinearB 的研究都利用了他们自己的数据，这些数据来自使用他们产品衡量定量和定性开发者体验的组织，所以两种结果都不是全貌。对于行业其他部分来说，情况可能实际上要糟糕得多。

根据 LeadDev 的《2026 年 AI 影响报告》的研究（将于今年 8 月晚些时候发布），只有 31% 的受访团队在衡量 AI 的影响。LeadDev 将这些衡量定义为：

• 实际生产力提升
• 核心工程技能的保留
• Agentic AI 治理
• 初级招聘和培训

在实际上已经开始采用 AI 驱动的开发者工具的组织中，LeadDev 报告发现 70% 现在自描述为已“广泛或完全”采用，只有 26% 报告 AI 提升了工程生产力超过 25%。该报告的作者、LeadDev 主编 Michael Hill 澄清，这 26% 包括仅凭直觉而非确认数据的受访者。

“生产力乐观主义——26% 看到巨大收益——和衡量差距——只有 31% 实际在追踪——是来自两个不同问题的两个独立发现，”Hill 告诉 The New Stack，这意味着“大多数报告收益的人不是能够证明它的人。”

众所周知，工程是一门科学，所以你无法改进你无法衡量的东西。但即使对于那些正在衡量的公司来说，结果也令人担忧。

Reock 指出 DXI 分数在上个季度首次下降：

“我们真的应该密切关注这一点，因为我们的客户群趋势是上升的，对吧？数据有严重偏差，因为他们（DX 客户）正在投资开发者体验，比如积极地。他们购买了产品，所以这个数字往往对我们的客户群呈上升趋势。所以看到这个实际上下降是非常令人担忧的。”