AI生产力陷阱：更多的产出

AI使得生成代码、草拟工单、总结会议和撰写提案变得极为便宜。但更便宜的生成并不意味着工作实际上完成得更快。更多的原始产出意味着更多的审查、更多的验证和更多的下游清理，这是不可避免的趋势。如果获得正确的拉取请求合并或合理工程决策的总时间没有改善，那么引擎只是在产生更多噪音。实际交付速度并未改变。

我们必须区分产出、吞吐量和成果。产出是我们生成的原始工件。吞吐量是通过交付系统成功移动的经过验证的工作。成果是正确的决策或安全的生产变更。AI增加了个人产出，但往往使吞吐量和成果保持平坦。

这一差距在最近一项关于经验丰富的开源开发者的METR研究中得到了凸显。当开始使用这些工具时，开发者预测AI会将他们的任务时间减少近四分之一。即使在研究之后，他们仍然主观上感觉节省了时间。但现实世界中的测量结果恰恰相反：当开发者被允许使用AI工具时，任务耗时增加了19%。研究人员表示，标准的产出衡量可能具有误导性。生成式工具往往产生冗长但等效的代码，或者将任务分解成更多部分，而不实际减少总认知努力。因此，一个错误报告变成了五个工单、三个拉取请求和一个迁移说明。这导致更大的差异需要审查，更多的生成测试需要运行，以及更多的人工制品需要分类，增加了错过关键细节的可能性。

有趣的是，开发者的体验仍然非常积极。AI擅长消除空白页面的摩擦，使工作感觉更加流畅。AI将人类劳动从创造转变为评估，因此主观速度和实际测量时间存在差异。检查他人的工作通常比自己编写更容易，尽管往往需要更长时间。下游的审查、清理和验证工作堆积起来，但开发者感到畅通无阻。AI仍然非常有用。使用Copilot等工具的对照实验表明，开发者可以更快地完成有界编程任务，如编写样板代码、生成API胶水代码或编写测试框架。

问题在于审查和验证需要更多时间，这进一步拖延了交付周期。年度DORA报告指出，AI采用增加了个人的生产力感，但AI采用可能成为软件交付稳定性和吞吐量的瓶颈。更快的代码生成增加了审查队列和合并风险，推动团队采用更大的批量规模。AI会放大它所进入的系统。大多数具有良好定义的软件所有权、严格审查流程和高度可靠部署管道的团队将从该技术中受益。但在弱激励、模糊的生产边界和糟糕验证的情况下，AI只会成为低质量输出的加速器。

当组织奖励大量AI令牌使用作为生产力的代理（例如代码行数或提交次数）时，测量是一个大问题。这些指标很容易被操纵，与实际业务价值几乎没有关系。

您在数千名开发者的遥测数据中可以看到这种模式。Faros对超过10,000名开发者的分析发现，虽然高AI采用率与完成更多任务和合并拉取请求相关，但也导致了更长的审查时间、更大的拉取请求以及每个开发者更多的错误。他们没有发现高AI采用率与公司层面交付指标或质量关键绩效指标之间存在有意义的关联。

这很明显。如果开发者编码速度加倍，但人工审查仍然是瓶颈，那么工作只会卡在审查中。AI生成的大差异大大扩展了审查者需要查看的搜索空间。在看起来几乎正确的生成代码中，微妙的错误需要比审查具有清晰人类设计的手写代码更多的专家关注。如果没有强有力的所有权或稳健的验证，那么可能产生的就是审查债务。

我们在代码之外也看到了这一点，以AI生成的“作品垃圾”形式出现。这些是看起来不错但并未真正推进项目的华丽东西。无休止的备忘录没有解决任何问题，会议记录掩盖了分歧，提案将尽职调查的负担推给读者而非作者。这为所有必须花时间阅读和处理低实质产出的人创造了真正的隐藏成本。

实际工作只是被推到了下游，那些需要验证声明、协调总结并确定提案是否可行的人。与其计数工件，不如衡量团队是否用了更少的总时间达到正确的合并、坚定的决策或已交付的结果。这需要更好的指标，如每次接受变更的审查时间、返工率、变更失败率、决策延迟和审查者负载。收集这些措施比收集简单的令牌计数或完成任务更困难，因此许多组织并不收集它们。良好的交付跟踪需要考虑已接受的工作和真实的交付成本。

AI是一个强大的工具，用于降低草稿、框架和初次运行的障碍。在那之后，瓶颈仍然是审查。

我正在构建什么

委托任务。获得软件。

给Vroni一个GitHub问题、错误报告、规格或粗略想法。它会读取仓库、计划变更、编写代码、运行检查，并朝审查就绪的拉取请求努力。

请访问vroni.com。