你的编程智能体悄然打破的内部循环

关于编码智能体（coding agents）提高生产力的说法是，它们消除了打字瓶颈。但在实践中，工程师真正遇到的瓶颈却截然不同。工程师再也无法在脑中掌握整个系统，因为智能体修改文件的速度快于工程师阅读的速度，编写测试的速度快于工程师推断覆盖率的速度，重构抽象的速度快于工程师在设计层面（而不仅仅是编译器层面）验证类型检查的速度。

那个紧凑的内环——假设、更改、观察、优化——定义了胜任的工程工作，但它正悄然瓦解为另一种循环。工程师现在是在审查智能体的输出，而不是建立对系统的直觉。2025 年中期的一项 METR 随机对照试验发现，经验丰富的开源开发人员在使用 AI 助手处理熟悉的代码库时，速度慢了 19%，但他们却报告感觉快了 20%。认知感知的生产力与实际生产力之间这 39 个百分点的差距并非测量误差。这是为了吞吐量而默默牺牲理解力的代价。

内环与打字无关

有着十年系统交付经验的工程师都知道，内环不是击键周期，而是认知周期。你形成一个关于某种状态如何流经三个模块的假设。你做一个微小的改动。你观察系统的行为是否符合你心智模型的预测。如果符合，你的模型就得到了强化。如果不符合，你就学到了关于系统的一些新知识，并更新了你的模型。

内环的产出不是 diff。而是那个现在能以一小时前还无法达到的水平来推导系统的工程师。diff 只是副产品。

编码智能体加速了 diff，却减慢了认知。改变仍在发生，但“假设-测试-更新”的循环消失了，因为工程师被隔开了一个层级：他们不再是形成假设的人，而是在审查智能体的假设；他们不再是观察行为的人，而是在阅读智能体对行为的总结。原本可以更新他们心智模型的信号，被一个拥有自己模型且没有义务保持工程师模型完整的解释器过滤掉了。

几个月后，工程师会发现他们仍然可以交付功能，但再也无法回答关于他们所负责模块的架构问题。他们并没有停止学习，而是再也没有什么可以学习的了，因为那个教导他们的循环已经消失了。

没有理解的吞吐量是一种替代，而非收益

关于编码智能体的标准论调是它们是力量倍增器。而诚实的说法是它们是一种替代。它们用一个单位的理解力换取一个单位的吞吐量。这种交换是否划算，取决于你下周需要这位工程师做什么。

这个数学计算让人感到不安。如果一个团队只衡量速度——合并的 PR 数量、代码行数、故事点——那么这种替代看起来就像是纯粹的双赢。2025 年卡内基梅隆大学的一项研究报告称，开发者在样板代码上花费的时间减少了 28%，而审查 AI 针对复杂逻辑建议的时间增加了 19%。这种转变是从“创作”转向“评估”，而评估在短期内认知成本更低，在长期内认知价值更贫乏。你可以评估一千次某个东西，却永远无法建立起能让你从零创造出类似东西的结构化模型。

如果不计算这种替代成本，团队就会在庆祝仪表盘数据的同时，导致工程能力的衰退。六个月后，代码库增长了，但团队对它的掌握程度却缩水了。最具体的症状是当工程师再也无法引导新员工入职时，因为他们自己也解释不清自己交付的模块。智能体无法转移它的模型，因为它从未拥有过一个可供转移的模型——而工程师从一开始就不是模型的来源。

仪表盘无法衡量的工程师损失

加载中…