AI 写代码快了, 为什么软件没变快?

AI 编程智能体让代码行数增加约 30%，Jira 里的任务完成量却没有显著变化。代码写快了，软件交付没有跟着快。

10 月 19 日凌晨，Yuchen Jin 在 X 上发了个段子，几个小时就有五百多人点赞：

工程师 1 对 AI 说：“把这个功能做了，提个 PR。”

工程师 1 对工程师 2 说：“帮我审一下？”

工程师 2 对 AI 说：“审一下这个 PR。”

工程师 2 对工程师 1 说：“LGTM，看着没问题。”

讽刺的是，两个人用的是同一个 AI 模型。

有人问：他俩知道自己用的是同一个模型吗？Yuchen 回了一句：每个 PR 都应该让真正写它的那个 AI 联合署名。

这段话好笑，也有点扎心。写代码的人把活交给 AI，审代码的人也把活交给 AI，最后还是要一个人说“看着没问题”。

最近一篇哈佛论文，把这件事放到七百多家公司里看了看。AI 让代码多了，卡住的却是代码后面的流程。

代码多了三成，交付没跟上

论文叫《企业中的人工智能：软件生产的瓶颈》，作者是哈佛大学的两位博士生 Fiona Chen 和 James Stratton。这是他们的求职论文，首版发表于 2026 年 1 月，最新版是 8 月 4 日，目前还没有经过同行评审。

数据来自 Jellyfish，一家帮企业分析研发团队效率的公司。客户把 GitHub、Jira、日历这些系统接进去，平台就能看到工程师提交了什么、任务什么时候关闭、开了多少会。

研究用的是同意把数据用于研究的客户：718 家公司、约 72.6 万名员工、约 3 亿条工作记录，时间从 2021 年 1 月到 2026 年 3 月。论文也说得很清楚，结论只代表作者；Jellyfish 只检查有没有泄露商业机密，没有审核研究结论。

公司开始用 AI 的时间不一样。有些公司采购快，有些要过几个月的安全和法务审批。作者用这个先后差异做比较，方法叫交错双重差分。论文还把工具分成两类：Copilot、Cursor 这类助手，主要帮人补全代码；Cursor Agent、Claude Code 这类智能体，可以自己做一大段工作。

公司用上智能体之后，代码行数增加约 30%，提交次数增加约 20%，PR 增加约 23%。

再看 Jira 里关闭的任务、完成的整块功能，只是小幅上升，统计上不显著。按论文的 95% 置信区间，任务完成量的增幅上限不超过 12%。

代码多了三成，交付最多多一成出头。

会不会是大家开始做更大的任务，所以完成数量没涨？作者用模型估算了任务大小，没发现任务变大。

就业方面，论文没发现明显的短期裁员。用智能体的公司，员工总数变化接近于零，可以排除超过 2.9% 的下降；工程师人数也没有显著变化。

不过，这项研究只看单家公司，也只看短期。如果 A 公司靠 AI 抢了 B 公司的生意，B 公司的岗位会不会少，论文看不到。

真正堵住的，是代码审查

多出来的代码去哪了？论文测了 PR 从提交到合并要多久。用上智能体之后，平均时间从 7.03 天拉长到约 10.48 天，多了 49%。

被要求打回去修改的 PR，从约 13% 涨到 25%，接近翻倍；每个 PR 收到的评论多了 35%；参与审查的人员比例增加了 14%。

有个细节，PR 本身没有变大。同样大小的改动，需要更多来回。

为什么？作者给了两个解释：一是代码一下子多了，审查的人手没跟上，PR 开始排队；二是 AI 写的初稿可能需要更多核对，每单位代码花在审查上的时间变多了。

论文里有个初级工程师的访谈。他说，项目里只有一位资深工程师有权批准代码，但那位工程师太忙，一周才能看一次他的改动。后来几次事故和 AI 生成的代码有关，公司加了规定，AI 写的代码必须由资深工程师批准。事故少不少还要看，审查先更堵了。

那让 AI 来审不就行了吗？论文也查了。到 2026 年 3 月，接近 80% 的公司已经在审查环节用过 AI 工具。但所有审查评论里，只有 23.3% 是 AI 写的；只有 10.8% 的 PR 收到过 AI 评论。

还有个区别：审查时间拉长，出现在智能体工具上；Copilot、Cursor 这类助手没有显著拉长审查时间。看起来，能自己做更多工作的工具，也把更多检查工作带进了流程。

Anthropic 的变化，发生在审查流程

这组数据和 Anthropic 最近公开的数据，放在一起看，好像有点打架。

10 月 15 日，Anthropic 写道，Claude 写了 Claude Code 这个产品自身大约 90% 的代码。今年 6 月到 9 月，Claude Code 代码库合并的 PR 翻了一倍多，需要回滚的比例反而下降了 40% 以上。Anthropic 整个大仓库每天落地的改动，从 5 月约 2500 个增加到 9 月超过 3 万个。

一边是七百多家公司，代码多了，任务没显著增加，审查还慢了；另一边是 Anthropic，PR 翻倍，回滚比例下降。我觉得两者不矛盾。区别在于，有些公司只是把 AI 接进了旧流程，Anthropic 连审查流程也一起改了。

他们把检查往 PR 前面挪。代码提交之前，AI 先跑测试，再让一个新开的子智能体检查代码差异。研究预览上线后，他们说内部每个 PR 都经过 AI 审查，收到实质性审查意见的 PR 比例从 16% 升到了 54%。

审批也按风险分。文档、文案和开关后面的新功能，自动检查全绿就可以不需要人工批准；普通产品改动要一个人审；计费、自动更新、CI 等高风险代码要两个人审。风险看改动内容，不看是谁写的。智能体的批准不算人的批准，写代码的工程师本人也要承担审查责任。

他们也踩过坑。有个 PR 让写代码的智能体和审代码的智能体互相“喂活”，一夜之间改了五十多轮，最后作者手动叫停。后来他们加了轮数限制，三轮之后就让作者停下来重新想思路。

所以我更愿意把 Anthropic 的效率，理解为两件事一起变了：AI 写得更多，审查也被重新安排了。

当然，这些是公司自报的数据。90% 说的是 Claude Code 这个产品，不是 Anthropic 全公司；回滚下降的是比例，不是数量。

字节和美团也碰到了同一堵墙

国内团队也遇到了这个问题。

今年 6 月的火山引擎 Force 大会上，字节跳动技术副总裁洪定坤分享过 TRAE 团队的数据：过去半年，超过 90% 的代码由 AI 编写，人均需求吞吐率提升了 60%。

他讲得很坦诚：AI 写代码至少是人的 10 倍速，90% 的代码都交给 AI 之后，效率本来应该高好几倍，甚至一个数量级，最后却只有 1.6 倍。“10 倍和 1.6 倍之间，有着很大的差距。”

有些团队还把 AI 代码贡献率定成 KPI，围着这个数字优化。洪定坤说，这个指标会失真。代码占比涨了，不代表需求真的更快交付。

美团技术团队 5 月的一篇博客也讲得很直接。他们有一个 31 万行代码的系统，90% 以上的代码由 AI 辅助编写，很快就遇到木桶效应：代码审查成了全链路最堵的地方。如果 CR 效率不提升，AI Coding 带来的提效就会被审查瓶颈吃掉。

美团的做法是，提交 PR 前先用 AI 多轮自查，让人主要看业务逻辑；还会用不同厂商的模型互相审对方的代码。

这个做法，正好回应了开头那个段子。两个模型交叉检查，可能多找出一些问题；但问题重不重要、改动值不值得做，还是得有人判断。美团说，AI 很适合帮我们把问题看全，什么问题最重要，仍然要由人来定。

代码占比涨了，不能当作交付变好了

把这几份材料放在一起，我的判断很简单：代码量不再是一个可靠的效率答案。

如果公司开始拿 AI 代码占比、提交次数考核人，你得留个心眼。哈佛这组数据里，代码多了三成，任务完成量没有显著增加。代码写了多少，是过程；功能有没有上线、上线后有没有出事，才是结果。

审查能力会越来越值钱。写代码的人没少，被拉去审代码的人多了。能看出改动会不会影响别的地方、能判断一件事值不值得做的人，会越来越重要。

对程序员来说，学会让 AI 多写，只是第一步。测试能不能自动跑，PR 能不能拆小，出了问题能不能回滚，这些事看着不性感，却决定了代码能不能安全地进系统。

你们团队现在审一个 PR 要多久？比一年前更快了，还是更慢了？