这是十五年前的事情（请耐心点，我从90年代末就一直在这个行业，至今大部分好故事都是这样开始的），你在一家SaaS公司有两名高级开发人员。其中一位写的代码行数比另一位多40%。那位开发人员更好吗？对业务更有影响力吗？另一位应该开始润色自己的简历吗？当然不是。你想知道的是真正发布了什么。它给客户带来了什么，对收入、可靠性做了什么。代码行数、PR计数……我们花了几十年时间学习这两者通常是衡量开发人员的糟糕方式，以至于今天提出这些建议听起来简直可笑。那么……今年行业在公告牌上显示了什么：谷歌：75%的新代码是AI生成的。Anthropic：大约80%的合并生产代码是由Claude编写的，工程师每季度交付“8倍的代码”。OpenAI：同样大约80%，显然如此。Cursor：“每天编写超过1亿行企业代码”。每一个都是一个数量声明。“AI编写代码的百分比”不过是代码行数有了更好的宣传者。（我在编辑这个草稿时心存怀疑，想要指出所有这些情况并非偶然，因为它们都是某种形式的AI供应商，所以推动采用对他们来说相当重要。）我们过去声称成果 rewind 几年前，头条数字在性质上有所不同，而不仅仅是规模。GitHub的旗舰声称是，开发人员在使用Copilot时任务完成速度快了55%。无论你对那项研究有什么看法（很多人都有），但它是一个结果声明。大胆、可证伪，关于价值。如果是错的，你可以证明它是错的。2026年的声明无法失败。这就是它们的天才所在；“我们75%的代码是AI编写的”可能是真的，并且无论是否有所改进（更快的交付、较少的事故、更快乐的客户等）都会持续上升。一个数量数字只有在采用停滞时才会令你失望，而采用是我们大多数人都认为是真实的唯一一件事。 📈 所以这些声明变得更大，却开始说得更少。那么，在此之前发生了什么？没有人会在公告牌上放的事情。成果证据变得复杂，这就是发生的事情。支持采用的最强结果仍然是Cui等人的研究；近5000名开发人员，任务完成率提高了26%，而初级开发人员的收益最大。没有实质性争议。但随后GitClear显示代码变更率上升，重构下降，因为Copilot的采用逐渐加深。然后，METR进行了许多人引用的研究：经验丰富的开源开发人员在自己的代码库中使用AI时的速度慢了19%，而他们认为自己快了20%。但是！等等……在2026年2月，METR实际上推翻了这个结果：他们的后续估计翻转为加速（误差范围宽到足以让人骑着配有尾箱的摩托车穿行！），并且他们完全放弃了研究设计——因为开发人员现在拒绝在没有AI的情况下工作，无法可靠地自我报告自主工作的时间。他们的最新立场：AI在2026年可能会加快开发人员的速度，而我们无法再明确测量加快了多少。同时，在公司层面，一项对约6000名高管的NBER调查发现69%的公司在积极使用AI，约90%报告没有可测量的生产力影响。跨研究共识大约在10%的组织收益。不是没有收益！仍然非常有用！但是，也不是“你再也不需要开发人员”的地盘。如果你还是一个引用“慢19%”的怀疑论者，你也在选择性引用。研究不断更新；行业只是改变了它所计算的内容。虚荣指标，现在都是AI味道。不仅仅是AI供应商的声明，公平地说。卡内基·梅隆大学的SEI和埃森哲几天前推出了一个AI采用成熟度模型：五个级别，八个维度，基于95%的组织没有回报的数据进行市场推广。斯蒂夫·耶奇的“8级AI辅助开发”根据您使用的工具和给它们的监督程度进行排名。而且每个工具供应商现在都会发布一个成熟度阶梯，其最高级别通常是“更多地使用我们的产品”。这些阶梯衡量采用强度，并称之为成熟度。同样的替代，更漂亮的包装。在整个类型中我最喜欢的数据点：Augment对219位工程领导进行了调查，询问他们如何定义“AI原生工程”。他们得到了219个不同的答案。🫠 而在这一切中，持有绳子两端的奖项颁给了Anthropic，他们给我们带来了“8倍交付的代码”声明和年度更为严格的研究之一：一项随机对照试验发现，使用AI辅助的开发人员在刚刚交付的代码理解上得分低17%，而没有统计学上显著的生产力收益。我每天都在使用Claude（它推荐了我为这篇文章阅读的半数链接，所以我并不失去讽刺），这些产品确实很优秀，而他们的研究部门在更新时，他们的市场部门在计算数量。这两者同时成立，这正是要点。为什么我真的关心 因为这些数字并不是装饰性的。它们移动预算、绩效期望和员工计划。