编码从来不是瓶颈

我的工作是开发者生产力。我已经在开发者基础设施领域工作了六年，因此我对此有切身利益。我希望AI生产力故事成真——更多的产出、更短的时间线、更快乐和更高效的工程师。谁不希望呢？但我不断审视实际研究，再看看现实世界中发生的情况，却无法让它们相互吻合。或者更确切地说，我可以让它们吻合，但前提是我愿意承认“高效”并不意味着最近大多数讨论所认为的那样。

最令人不安的发现

2025年初，研究组织METR对开源开发者进行了一项对照实验。他们发现（与行业预期相反），使用AI工具的工程师比不使用的工程师花费的时间多19%，置信区间为+2%到+39%。这种放缓在统计上是稳健的。那是行业的一个不同时期：Claude尚未发布其Opus模型，行业正在摸索AI能做什么和不能做什么。但这一发现引人注目的不是放缓本身，而是工程师们相信他们大约快了20%，而数据却显示相反，揭示了感知与现实之间的显著差距。

这一发现值得我们先消化一下，然后再堆砌其他证据，因为它改变了你阅读其他一切的方式。

METR试图从2025年8月开始进行一项后续研究，而这项研究的结果可以说比最初的结果更具揭示性。2026年2月，他们发布了一篇文章，解释了为何放弃实验设计。问题在于，太多开发者拒绝参与，除非他们可以在所有任务中使用AI。30%到50%的剩余参与者报告有选择性地回避提交他们不想在没有AI的情况下完成的任务。样本变得系统性地偏向于那些最不可能显示AI价值的开发者和任务。

2025年末的研究数据显示了趋势的改善。对于返回的原始开发者子集，估计效应转变为速度提高18%（置信区间：-38%到+9%）。在新招募的开发者中，速度提高了4%（-15%到+9%）。但METR指出这些数字可能是一个下界，因为许多人自我选择退出。他们的结论是：自2025年初以来，AI工具变得更加有用，但选择效应现在已经如此严重，以至于近乎无法进行对照测量。最热衷于AI的开发者将不再在没有AI的情况下工作以作为对照组。

这不是METR方法论的失败。这是一个信号，表明我们身处何处以及我们将走向何方。

另外三个数据点

2025年末和2026年初还发布了若干其他研究。

Anthropic在2025年末调查了其内部132名工程师，进行了53次访谈，并分析了20万份Claude Code记录。员工报告生产率提高了50%。随着工程组织和Claude使用的增长，他们声称每位工程师每天的拉取请求增加了67%。Anthropic工程师在60%的日常工作中使用Claude，且Claude执行更多自主任务。

CircleCI分析了跨数千个团队的2800万个CI工作流。工作流吞吐量增加了59%，但中位数团队的主分支吞吐量下降了7%。构建成功率降至70.8%，为五年低点。存在的代码比以往任何时候都多，但到达生产的更少，CI正在成为瓶颈。

哈佛商学院研究人员研究了78名使用AI执行非专业领域任务的工人。AI帮助所有人平等地进行头脑风暴，但在执行上，技能与领域相差甚远的工人比领域专家表现差13%。AI似乎在规划中缩小的差距在交付中再次出现。

METR在2026年5月对349名技术工作者的调查——这是在实验设计崩溃后进行的——发现自我报告的生产力价值增益为1.4到2倍。但METR自己的研究人员，即最了解他们在2025年记录到的感知偏差的人群，报告了该调查中任何子组中最低的增益。

实践中的情况

这是一个对某些读者来说会很熟悉的场景。

工程师活动指标在表面上看起来很棒。拉取请求在增加，代码提交量上升，速度点在以团队多年未见的步伐被关闭。领导团队很高兴，工程师们感觉更高效了。然后有人——很可能是项目经理——问为什么六周前标记为“进行中”的路线图项目仍然在进行中。

每个人都同时意识到：功能时间线实际上没有改变。

发生的情况是，AI大幅降低了开始工作的成本，但生产就绪的打磨仍然是一个挑战。初稿函数、样板代码、脚手架、以及为不熟悉的代码编写测试解释都变得显著便宜。但交付的瓶颈从来不是这些任务。它们是产品决策、设计审查、QA、合规、基础设施、发布流程。当你加快编码速度时，你最终会将更多进行中的工作塞到相同的下游瓶颈处。CircleCI关于2800万个工作流的数据在某种程度上就是这种情况在大规模下的写照：功能分支上大量活动，而主分支的吞吐量持平或下降。

这不仅在汇总数据中是一种模式。Anthropic Claude Code的一名工程总监在2026年6月的一次演讲中明确指出了这一点：编写代码、编写测试和重构在她的团队中已经很少成为瓶颈，但瓶颈并没有消失。验证、代码审查和安全取代了它们的位置。她特别指出了CI。随着团队生成更多代码，构建系统和CI管道可能难以跟上。这是一个运行着世界上AI加速程度最高的工程组织之一的团队，却遇到了与CircleCI数据描述的相同的约束墙。天花板不再是代码编写速度，而且实际上从来就不是。

Anthropic发现27%的AI辅助工作本来不会发生，这有利有弊。有些工作确实有价值，比如原型探索为实际决策提供信息，文档得以真正编写。有些则是没有人优先考虑过的工作，因为它根本不重要。现在它正消耗审查周期和CI资源，因为构建它变得几乎免费，而审查、测试和维护它却没有。

能力-信心差距

HBS研究确定了一个值得精确命名的具体机制。在他们的框架中，AI缩小了新手和专家之间的信心差距。它让每个人平等地获得计划、解释和初稿。但它没有缩小能力差距。当一个后端工程师用AI辅助构建前端功能时，他们产出的东西看起来正确。问题隐藏在表面之下，在他们不知道要质疑的决策和他们不知道要测试的边缘情况中。

早期的METR结果表明，这甚至适用于在自己的领域内有经验的专业人士。AI并没有让他们变得无能，实际上让他们感觉比他们的产出所证明的更有能力。而正如METR后续研究的崩溃所表明的那样，一旦开发者将AI深度整合，他们就失去了在没有它的情况下工作的能力，正如研究人员所称的自动化偏见。

这是应该令工程领导者担忧的部分。你无法修复你看不到的问题。如果你团队中的每个工程师都真诚地相信他们的生产力提高了50%，而你的交付日期却没有变化，那就存在一个没有人认为存在的问题。

如何使人工智能原生开发可持续

使代码审查更严格，而不是更快。AI生成的代码轻松通过表面检查——干净的格式、一致的约定、没有检查器警告——这正是它危险的原因。问题在于审阅者浏览差异时不会发现的那种。

我一直称之为“合理怀疑审查”。做法是从怀疑而非信任开始。问题不是“这看起来正确吗？”而是“这里可能有什么问题是我从差异中看不出来的？”具体来说，模型做出了哪些在输出中不可见的假设？它在哪些边缘情况下会静默失败？哪里耦合了作者可能没有考虑到的东西？

这更慢。这正是关键所在，而且它也不是无限可扩展的，因此需要将自动化用于不需要判断的事情，并将人类注意力集中在需要判断的地方。

Claude Code团队的方法是一个很好的指示：让AI处理风格、检查、错误捕捉和测试生成作为第一遍，但将安全敏感代码、信任边界和任何涉及法律风险的内容直接交给领域专家。划分不是“AI审查较小/低风险更改，人类审查较大/高风险更改”，而是“AI处理表面正确性，人类负责重大判断”。这是一项有意义的区别。许多团队在做前者时以为自己在做后者。

调整你的CI以适应新的故障模式。CircleCI的构建成功率跌至五年低点，而吞吐量却激增，这表明大多数团队尚未更新其管道以捕捉AI生成代码的破坏方式。AI生成的代码失败方式与人类生成的代码不同。它更可能局部正确但架构不一致，通过单元测试但失败集成测试，尊重函数签名但违反这些函数所围绕构建的假设。集成测试、契约测试和架构适应度函数可以在管道中强制执行系统约束，它们会比检查器或类型检查器捕捉到更多此类问题。如果AI生成的代码违反你的模式，构建应该在审阅者打开差异之前捕捉到它。这解决的是你的审查问题和基础设施问题。

在功能标志后面发布并积极监控。接受你无法在部署前捕捉到所有问题。不要完全依赖于合并前质量——证据表明这比感觉上更难评估——而是部署给1%的用户，观察仪表板，并在出现问题时快速回滚。这种方法还迫使投资于可观察性，这独立于AI问题也会带来回报。

要求为AI辅助代码编写人工编写的测试（直到AI能够自信地生成确定性测试）。特别是针对边缘情况和边界条件的人工编写的测试。编写测试的纪律迫使开发者思考行为，而不是表面地接受输出。如果工程师无法编写测试，他们可能不够理解代码，不足以发布它。这是一个有用的信号，而不是失败状态。

保护有意的知识共享时间。Anthropic研究发现，导师制正在悄然侵蚀，因为Claude取代了工程师们曾经互相进行的对话。这是数据中的长期风险。架构决策记录、轮流系统演练、高级和初级工程师一起解决问题的结对会议——这些与询问AI相比感觉效率低下。它们正是团队建立共同理解的方式，这种理解可以防止同样的错误以更格式化的代码每六个月被重造一次。

测量问题

那么，这是否意味着我们停止使用AI？不。使用AI，并在它明显有助于繁琐任务、原型设计、探索性工作以及任何你可以快速验证的事情上积极使用。在范围良好、可独立验证的工作上，收益是真实的。

但如果你试图衡量生产率的实际提升，请谨慎对待自我报告的数据。实际结果——功能交付、事件数量、代码审查周期时间——才是最重要的。而迄今为止的数据表明，AI正在改变工作的性质，但尚未从根本上改变我们交付的速度。它改变了瓶颈的位置，但没有消除瓶颈。而忽视这一区别的团队最终会生成大量永远不会交付的代码。

解决方案不是更少使用AI，而是更聪明地使用它——并诚实面对我们仍然需要解决的瓶颈。