AI 编程成本激增,工程团队生产力指标难题再度浮现
来源标题:Engineering Fought Productivity Metrics. AI Ended the Fight
Uber 四个月花光 2026 全年 AI token 预算,Salesforce 的 Anthropic 账单据称每年约 3 亿美元,Meta 内部排行榜按 token 消耗为约 8.5 万人排名、单月记录超 60 万亿 token。但投入难以对应到实际交付的功能,Uber COO 表示无法说明产出就让成本难以合理化。工程团队长期回避的硬性生产力衡量问题因此重新成为焦点。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
Uber在四个月内花光了2026年全年的AI token预算。据报道,Salesforce的Anthropic账单每年约为3亿美元。Meta员工做了一个内部排行榜,按token消耗量给大约8.5万人排名,单月记录到的token超过60万亿。 然后有人问了那个显而易见的问题:我们从中得到了什么? Uber的COO Andrew Macdonald说得很直白:“如果你无法真正把token成本与你们向用户交付了多少有用的特性和功能对应起来,[这些成本]就很难站得住脚。” 大多数工程组织今天画不出这条线。这正是我想梳理的问题。 很长一段时间里,软件工程在硬性生产力衡量上一直享有豁免。2023年麦肯锡发布《是的,你可以衡量软件开发者的生产力》时,业界强烈反弹。Kent Beck称它“如此荒谬和天真,以至于详细批评它都没有意义”,他和Gergely Orosz写了两部分的反驳,认为它弊大于利。 在方法上,他们是对的。衡量个人投入和产出会招致钻空子。但主张别去碰工程的那个论点,前提是工程成本主要是人力,而人力是财务本来就能理解的数字。 AI改变了这一点。token支出是新出现的、可变的、且快速增长的。它每个月都出现在账单上,财务想知道它买到了什么。2026年6月,Linux基金会成立了Tokenomics Foundation,旨在标准化企业衡量AI支出的方式,Google Cloud、Microsoft、JPMorganChase和Salesforce都是支持方。FinOps Foundation的说法是:“token成本和效率已成为CEO层面的关切。” 工程不再免于衡量。问题在于,是我们把它衡量好,还是让别人把它衡量得很糟。 人们想要一个简单的答案。AI有用吗?是或否。给我那个数字。 并不存在这样的数字,DORA和SPACE多年前就解释了原因。DORA在速度(部署频率、前置时间)与稳定性(变更失败率、恢复时间)之间取得平衡。SPACE范围更广,加入了满意度、协作和心流。两者都表达了同一个观点:生产力贯穿整个软件开发生命周期,推动某一项指标会带动其他指标。 AI已经证明他们是对的。2025年DORA报告发现,AI采用率越高,交付吞吐量越高,同时不稳定性也越高。Faros称之为加速鞭打效应(acceleration whiplash)。他们2026年的报告基于2.2万名开发者的遥测数据,发现个人产出大幅上升,同时每位开发者的bug数上升了54%,每个pull request的事件数上升了242.7%。 工作也在评审环节堆积。在Faros 2025年的数据中,高采用率团队的开发者合并的pull request多了98%,但这些pull request大了154%,评审时间上升了91%。在他们2026年的数据中,评审时间上升了441%。Eliyahu Goldratt在《目标》中提出了这一点:加速一个并非瓶颈的环节并不会让系统更快,只会在瓶颈前面堆起更大的堆。AI加速了写代码。评审成了瓶颈。 问开发者也不能解决问题。Yegor Denisov-Blanch在斯坦福的研究团队研究了600多家公司近10万名开发者。他们发现,把返工计算在内,净生产力提升为15–20%,而问开发者自己感觉生产力如何,几乎和抛硬币差不多。 如果你只看合并的pull request,或者只问你的团队,你会把这称为胜利。这就是DORA和SPACE依然重要的原因。它们迫使你同时看所有方面。 DORA最犀利的发现是,AI是一个放大器。它让好的团队更好,让差的团队更差,而且更快。一个测试扎实、小批量、评审快速的团队能把AI产出转化为交付价值。缺少这些的团队则把它转化为事故。 我相信这一点。但在你能用数字说明自己属于哪种团队之前,这没有用。 研究开始提供这些数字。在2026年8月的一项研究中,Denisov-Blanch与斯坦福和卡内基梅隆的同事考察了441个采用coding agent的代码仓库。每一组都变快了,提交数多了28–38%。但没有提交AI配置文件的仓库——也就是告诉agent代码库如何工作的AGENTS.md和CLAUDE.md文件——代码复杂度上升幅度约为前者的两倍(53%对27%),静态分析警告上升幅度多1.7倍。同样的工具,同样的提速,截然不同的代码库。而那些配置文件中有73.8%提交过一次后就再也没被碰过。 这就是被测量出来的放大器。把自己的系统如何运作写下来的团队,获得了速度,却没有那么多混乱。 DORA和SPACE是为了把软件交付作为一门学科来衡量而建立的。它们没有把交付与业务或金钱连接起来。DX Core 4增加了业务影响维度,而现在DORA自身也在演进。 2026年5月,由Nathen Harvey领导的Google Cloud DORA团队发布了《AI辅助软件开发的ROI》。它给权衡取舍标上了美元价格。采用遵循J曲线,在收益到来之前有一段生产力下滑。评审AI生成的代码要承担验证税。不稳定性要承担不稳定性税:在他们的样本模型中,变更失败率从5%升到6%,会造成34.4万美元的停机损失。他们的总结是我见过的对整个论点最好的一句话概括:“我们不是用AI写的代码来衡量AI,而是用它清除的瓶颈来衡量。” 这是正确的方向。DORA正在补上缺失的业务和财务层面。但ROI模型是一个规划工具。它告诉你该期待什么。它无法告诉你你的组织上个季度实际发生了什么。要做到这一点,你需要你自己的数据。
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。