机械荟萃山庄

 找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
热搜: 活动 交友 discuz
查看: 159|回复: 0

AI多写代码 并没有让整个工程交付提速

[复制链接]

2万

主题

3万

帖子

22万

积分

超级版主

Rank: 8Rank: 8

积分
224863
发表于 2026-7-22 09:04:17 | 显示全部楼层 |阅读模式
先看一组来自 Rohan Paul 在 X 上的总结:
"Code volume surges by 300%, but output increases by only 30%: The AI dividend meets an awkward reality."
代码量飙升 300%,产出只增长 30%
这段话背后,是一篇 MIT 经济系和沃顿商学院联合发表的 NBER 工作论文,编号 w35275,标题直接把问题摆在桌面上:
Writing Code vs. Shipping Code

这篇论文的作者是 Mert Demirer(MIT 经济系/NBER)、Leon Musolff(沃顿/NBER)和 Liyuan Yang(MIT),2026 年 5 月以 NBER Working Paper 形式发布。
他们做了一件以前很少有人做的事:把 10 万名 GitHub 开发者的活动数据和他们使用 AI 工具的遥测数据拼在一起,用匹配事件研究法(matched event study),追踪 AI 编程工具采用前后的变化。

研究把 AI 编程工具分成三代:
第一代:自动补全
(比如 GitHub Copilot 初版)——代码提交量增加约40%
第二代:交互式/同步 Agent
(比如本地运行的 Claude Code)——累计增加约140%
第三代:自主/异步 Agent
(比如远程运行的 OpenAI Codex、GitHub Agent)——累计增加约180%
光看这组数字,效果惊人。从补全到 Agent,每一代都在让开发者写出更多代码、提交更多 commit。

论文提出了一个「生产层级」(production hierarchy)模型,把软件生产拆成一层一层:代码行数 → 文件修改 → 提交(commits)→ PR → 项目数 →实际发布(releases)。
结果是这样的:
自主 Agent 在 commit 层面带来的180% 累计增幅,传导到项目数量时只剩50%,到实际发布时只剩 30%。

换句话说,AI 帮你多写了将近两倍的代码,但最后多发布出来的软件只有三成。
中间那超过一半的"额外努力",被审查、集成、测试、修复边缘情况、合并冲突和发版流程消耗掉了。
论文给这种现象起了个名字叫「弱链条假说」(weak-link hypothesis):整个链条的产出取决于最慢的那个环节。
AI 加速了写代码,但审查、QA、产品决策、部署,这些还是人在做,还是原来的速度。

论文还估算了一个关键参数:AI 产出与后续人类工作之间的替代弹性(elasticity of substitution)只有 0.25。
如果替代弹性接近 1 或大于 1,说明 AI 多干一份,人可以少干一份,两者可以互相替换。但 0.25 意味着强互补。
AI 多产出的每一行代码,背后都需要人类投入对应的审查、测试和集成工作。AI 写得越多,人类要跟进的工作反而越多。
大家以为 AI 写代码更快,团队就能更快交付。但现实是:代码产出加速后,瓶颈转移了。
从"写不出来"变成了"审不过来""测不完""合不了""发不出去"。

论文没有只停留在 GitHub 数据上,还把视角拉到了下游——四大应用商店:Apple App Store、Google Play Store、Chrome Web Store 和 SourceForge。
结果发现:自 2025 年中以来,新上架的 App 数量确实有明显增长。
但是,这些新 App 在上架后三个月内的总使用量,在四个商店里都没有增加。
AI 降低了"做一个 App"的门槛,但没有降低"做一个有人用的 App"的门槛。
市场上多了一批软件,用户却并没有因此用上更多新东西。

论文最有价值的贡献之一,是把"AI 编程效率"这个笼统说法拆开了。
传统 benchmark 测的是:模型能不能写对代码、能不能过 SWE-bench、能不能自动提 PR。但企业真正关心的从来不只是"代码写没写",而是整条交付链条:
需求对不对 → 代码写没写 → PR 能不能审 → 测试过没过 → 集成顺不顺 → 部署安不安全 → 用户用不用。
AI 目前加速的主要是链条的前半段,写代码和提交代码。但从 PR 审查开始,每一步都需要人类判断。
代码写得越多越快,积压在审查和测试阶段的工作量就越大。
这篇论文的启示很明确:AI 编程工具的下一个大机会,可能已经不在"写代码更快"上了。
如果模型只是继续提高生成代码的速度,收益递减几乎是必然的。代码堆得再多,审查跟不上、测试跟不上、产品决策跟不上,最终就是在生产流水线上制造拥堵。

点评
问题不在模型,在于用模型的人。需求变成现实,这中间要改无数遍,通过多次测试后才知道需求是不是合理。
所以模型好坏已经决定不了什么,因为模型解决不了提需求这个人,即让他如何提出合理的需求。























回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|小黑屋|手机版|Archiver|机械荟萃山庄 ( 辽ICP备16011317号-1 )

GMT+8, 2026-8-2 19:41 , Processed in 0.068198 second(s), 20 queries , Gzip On.

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表