关于 AI 编程，最流行的叙事是「效率翻倍」。但 MIT Sloan 在 9 月初发布的一项研究，给这股热情泼了一盆温和的冷水：开发者用 AI 工具确实产出了显著更多的代码，却不一定发布了更多新软件。这中间的落差，恰恰是 Agent 落地研发时最该正视的问题。
一、悖论长什么样
研究的核心发现可以概括为一个不等式：代码产出 ↑ ≠ 软件发布 ↑。AI 让「写」变便宜了，但软件从代码到上线的链路里，还有设计、审查、测试、集成、运维、弃坑等一长串非编码环节。当「写」不再是瓶颈，瓶颈就转移到了别处。
换句话说，AI 放大的不是「交付」，而只是「生产代码」这一段的吞吐量。若下游环节没同步提效，多出来的代码反而可能变成更多待审查、待维护的存量。
二、为什么「更多代码」不等于「更多价值」
代码是手段，不是目的。在真实工程里，价值来自被正确集成、持续运行、解决问题的系统，而非行数。AI 降低写作成本后，团队更容易陷入「产出了很多、沉淀下来的少」的状态：原型很多、上线很少；碎片很多、主线很少。
这也呼应了 Agent 可靠性专题里的判断——光「跑通一次」不够，能不能稳定进生产、能不能被审查与回滚，才是关键。
三、对 Agent 研发流程的启示
把这个悖论映射到「用 Agent 写代码」的实践上，有三点务实结论：第一，把 Agent 用在有明确验收标准的局部任务（单测、重构、文档）比用在「从零造系统」更易兑现收益；第二，审查与集成环节必须同步自动化，否则 Agent 产出的代码会堆在待合入队列；第三，用「上线率」「缺陷率」而非「生成行数」来衡量收益，才不会高估 ROI。
对管理者而言，真正的指标不该是「工程师今天让 Agent 写了多少行」，而是「本周有多少功能真的到了用户手里」。
四、不必悲观，但要校准预期
这项研究不是否定 AI 编程，而是把预期从「翻倍」校准到「局部提效」。在瓶颈清晰的环节（样板代码、测试、排查），Agent 的价值是真实的；在模糊、跨团队、强上下文的环节，它更像是放大器而非替代者。
结语：AI 编程的生产力悖论提醒我们——工具降低的是某一段的成本，而交付是系统问题。把 Agent 接进研发，别只盯着代码行数的增长，更要盯着那条从代码到上线的链路，是否真的被打通了。