上午，工程师用AI完成了一个功能修改。

代码生成、测试补充、提交PR，整个过程只花了过去一小部分时间。

但接下来，事情慢了下来。

代码要等同事审查，测试环境还在排队，相关团队需要确认，发布也得等下一个窗口。

AI把代码写完了，用户却还要等好几天。

这正成为AI编程普及后，软件团队需要面对的新问题：编码时间省下来了，为什么交付速度没有同步提升？

Jellyfish发布的AI工程趋势研究，提供了一组值得关注的数据。

在其样本企业中，按中位数统计，28%的已合并PR有Agent参与，而仅由AI完成审查的比例为0.5%。

两个数字之间的差距很明显。

但需要注意，Agent参与不代表整份代码都由AI编写；仅由AI审查，也不代表缺少测试和其他安全检查。

这些数据同样不能直接代表全球所有开发团队。

它反映出一个现象：

AI已经大量参与代码实现，但企业对代码审查仍然保留了较强的人工参与。

原因并不难理解。

写出一段看起来正确的代码，与确认它能够安全进入现有系统，是两回事。

假设AI修改了一个公共接口。

它不仅更新了接口定义，还调整了几个直接调用的位置。

局部测试全部通过，代码看起来没有问题。

但审查者还需要确认：

其他模块有没有依赖旧接口？

异常处理是否保持一致？

权限检查有没有遗漏？

修改会不会影响线上已有用户？

这些问题无法仅靠代码生成速度解决。

审查人员需要理解项目历史、业务约束和系统之间的依赖关系。

AI可以协助寻找问题，但最终的验收仍需要可靠的证据。

代码生成解决的是“怎么实现”，代码审查还要回答“这样实现是否合适”。

AI让工程师能够更快提交修改。

但PR数量增加，不代表软件发布频率一定提高。

一项需求可能拆成多个PR，多个PR也可能合并到同一次发布。

发布还受到自动化测试、构建资源、跨团队协调和运维安排的影响。

如果前端编码速度提高，而后面的处理能力没有变化，等待就可能集中到审查和验证环节。

不过，这是一种需要通过数据验证的可能性，不能仅凭PR数量增加就认定瓶颈已经后移。

团队应该观察的是：PR提交后，究竟在哪个环节等待最久？

当代码不再难产，等待代码被确认和发布，可能成为新的效率问题。

AI编程的效率报告，经常会讨论单位PR成本下降。

这当然可能意味着生产效率提高。

但还需要看清成本是怎么计算的。

如果相近的人力投入完成了更多PR，平均到每个PR上的成本自然可能降低。

问题是，不同PR的复杂度和价值并不相同。

修改一行配置，与完成一个关键业务功能，不能简单按数量比较。

更重要的是，代码合并之后仍可能产生返工、故障和维护成本。

如果生成更多代码，却带来更多后续修复工作，部分收益就可能被抵消。

真正需要计算的，不是写一个PR花多少钱，而是交付一个可靠功能花多少钱。

过去，团队容易关注代码量、提交次数和开发速度。

这些数据并非没有价值，但不足以反映完整交付效率。

更值得持续跟踪的是四件事：

从需求提出到正式上线，花了多少时间。

代码审查、测试等待和返工占用了多少时间。

上线后出现了多少故障、回滚和紧急修复。

最终交付了多少真正有价值的功能。

最好选择一个团队，在相近的任务条件下持续比较，同时记录人员和流程变化。

否则，很容易把所有效率提升归功于AI，也可能把其他问题错误归咎于AI。

AI正在显著改变代码生产方式。

但软件开发从来不只是把代码写出来。

需求需要确认，修改需要验证，系统需要稳定运行，最终还要让用户真正用上。

当编码环节加速，其他环节的等待和协调成本就会更加显眼。

这并不意味着AI编程没有价值，而是提醒团队：下一步的优化目标，应该从代码生成延伸到整个交付流程。

AI写完代码，不等于软件已经交付。

真正的效率提升，不是一天多合并多少个PR，而是让可靠的功能更快到达用户手中。