MIT调研10万名开发者：AI编程代码翻17倍，软件仅增三成

2022 年 6 月，Github 推出 GitHub Copilot，这是首个被广泛采用、基于大语言模型（LLM）的编程辅助工具。在此之前，负责软件开发的程序员需要花费 40%~60% 的精力编写样板代码、调试基础语法，以及处理事务性的胶水代码。但 AI 辅助工具的出现，让代码编写的边际成本骤然下降。

当写代码变得更容易，软件产出会随之变多吗？

为解答这一问题，2026 年 5 月，麻省理工学院和宾夕法尼亚大学的研究人员联合在美国国家经济研究局（NBER）发表工作论文，对生成式 AI 在软件开发领域的实际生产率效应进行了系统且深入的实证研究。他们通过追踪十万名开发者的产出，揭示了 AI 编程工具对生产率的真实影响：代码行数是原先的 17.3 倍，而实际发布的软件版本只提升了 30%。

（来源：https://www.nber.org/papers/w35275）

AI 编程工具的三代演进

研究人员将 AI 编程工具的演进历程分为三代。

第一代是具有增强作用的“自动补全”，起点是 GitHub Copilot：开发者敲击键盘时，它能预测后文的代码片段并提供相应建议。在这一时期，开发者的生产力提升了 26%。

时间来到 2025 年初，第二代“同步代理（Sync Agents）”迅速崛起。以 Claude Code 和 Cursor 为代表的智能体更进一步，可直接在集成开发环境（IDE）中与开发者实时对话、协同操作。开发者用自然语言下达任务，AI 代理自主导航本地代码库，跨文件编辑、运行单元测试，并根据反馈迭代修改，人类开发者成了“监工”，需实时审阅 AI 的阶段性产出，并决定是否采纳。

2025 年 3 月，Anthropic CEO 达里奥·阿莫代伊预测，六个月内，90% 的代码将由 AI 编写；同年，微软 CEO 萨提亚·纳德拉和谷歌 CEO 桑达尔·皮查伊各自声称，公司约四分之一代码已由 AI 生成。

几个月后，2025 年 5 月中旬，AI 辅助编程进入“异步代理（Async Agents）”阶段：OpenAI 发布了基于 Codex 的全新研究预览版，GitHub 推出 GitHub Copilot Coding Agent。利用这些工具，人类开发者可以直接将需求工单指派给异步智能体。

随后，智能体在云端虚拟机上启动，独立完成代码编写、测试运行，自动提交合并请求（Pull Request，简称 PR）供人类审查。截至 2026 年初，带有 Claude Code 署名的代码提交在 GitHub 公开仓库中占比已超 5%。

（来源：https://www.nber.org/papers/w35275）

代码提交增长近 80%，Claude Code 增益最明显

为论证 AI 对真实软件生产率的影响，团队设计了一项涵盖十万名开发者的匹配事件研究。

研究的数据来源分为三大部分。首先是 GitHub 公开数据集，其中包含全球 1.8 亿开发者和 3.95 亿个公开仓库中的历史活动记录。第二部分是微软的内部去标识化遥测数据，包括 2021 年至今所有 Copilot 用户的订阅与使用明细，以此记录每个开发者首次启动 AI 助手的具体时间。

第三块则是 2020 年 3 月至 2026 年 5 月期间，Apple App Store、Google Play Store、Chrome Web Store 以及 SourceForge 这四大主流软件分发市场的月度面板数据。

结果显示，如果只比较写代码或代码提交，AI 工具展现出的提效能力的确十分显著。

从数据上看，使用第一代自动补全的开发者，每周的提交数量在长时间内稳定上升约 40%；一旦将第二代同步代理引入工作流，这一累积增幅直接升至 140%；而当第三代异步代理全面铺开后，又被推高至 180%，其中，仅智能体自主撰写并直接提交的代码就占全部增量的 34%。

在这场技术红利中，获益最多的是低活跃度或低技能的普通开发者。在自动补全阶段，该工具对于低活跃开发者的效率提升高达 85%，而对原本就高频提交的开发者仅有 21% 的提升。

到同步代理时代，这一分化更加明显，低活跃群体的提交次数增加了 217%，高活跃群体的增幅为 62%。尽管对新手而言，AI 的普惠性更强，但在原本就活跃的开发者群体中，长期效率的提升依然稳定且持续。

更重要的是，研究首次证实，底层大模型迭代升级可直接驱动提效。追踪 Claude Code 使用者时，研究者发现，用户的生产力在 2025 年 11 月 Opus 4.5 发布后出现了一次与开发者使用时间无关的上涨。作为对比，2022 年使用 GitHub Copilot 的早期用户，在其接受 AI 建议后的 24 周里，曲线一直维持平盘。

而在不同工具之间，效率的表现也各不相同：Claude Code 带来的同步提效达到 199%，远超 GitHub Sync Agent 的 43% 和 OpenAI Codex 的 94%。

（来源：https://www.nber.org/papers/w35275）

代码量扩大，最终发布的软件多了多少？

工业化的软件生产，按先后顺序分为六个环节：代码行（Lines of Code）、文件（Files Touched）、代码提交（Commits）、合并请求（Pull Requests）、项目/仓库（Distinct Repositories）、版本发布（Releases）。研究人员发现，增长近两倍的任务提交量向最终产品转化时，增幅呈现漏斗状层层衰减的趋势。

（来源：https://www.nber.org/papers/w35275）

在自动补全工具时代，代码行数增加了 228.2%，最终软件发布量仅增长了 10.2%。在同步代理时代，智能体推动代码行数量增长了 741%；在修改的独立文件数中，这一增幅就缩水至 187%；转化为开发者实际提交的代码数时，降至 109%；再往上走，合并请求的增长率降至 65%；独立项目数仅增长了 26%；而到了代表真正产品交付的最终发布环节，这一数字最终回落至 20% 左右。

团队将三代 AI 工具的累积效应一并计入，结果发现，代码行数虽增加到原来的 17.3 倍，但文件数量的增长已骤降至 3.9 倍，逐级递减之后，最终的软件发布数仅提升了 30%。

软件生产是一条垂直的流水线，在这一体系中，底层流水线的产出不能直接使用，必须与上一层的人类劳动、审查和测试相结合，才能合成更高层级的半成品。AI 在这一过程中的介入方式包括增强（让人类每单位努力产出更多）和部分自动化（AI 直接生成产出，但人类必须进行审查）。

为此，团队建立了一套层层嵌套的常替代弹性（CES）生产函数模型对其进行阐释。结果显示，上游产出的弹性权重约为 0.75，而 AI 产出与人工投入之间的替代弹性系数约为 0.25。

（来源：https://www.nber.org/papers/w35275）

当替代弹性系数远低于 1 时，两个生产要素之间就存在极强的互补性，它们必须严格以固定比例搭配使用。

因此，即使 AI 的自动化编写能力趋于无穷大，只要更上一层的流水线离不开人类参与，人类程序员阅读、测试和审核的工作没有成比例增加，最终增益都会被急剧压缩。代入参数计算，这一上限仅为 26%。这代表着，哪怕未来的 AI 可以一秒钟写出全世界的代码，只要不革新软件工业流程，最终发布率的提升都无法突破 26%。

软件上市，反响如何？

既然代码产出受到人类能力的限制，那么通过审核、最终推向市场的新软件，在真实消费端的表现又如何？

研究人员分析了四大应用商店的供给端数据，结果显示，软件供给确实扩大了。在 Apple App Store 上，新上线 iOS 应用数量从 2023 至 2025 年初的每月 3 至 5 万款，在进入智能体爆发期的 2026 年 4 月增加至约 10 万款。

Google Play 商店中，新应用发布量改变了此前长期下滑的趋势，从月均 4.2 万款回升，并稳定在约 6 万款。而在 Chrome 浏览器插件市场，新扩展的发布量也从原本月均约 5,000 个增加至 1.3 万个。作为对照，在极少使用 AI 辅助工具的 Linux 遗产软件社区 SourceForge 上，新项目的发布曲线表现平缓。

供给侧增加后，需求侧的反应却略显冷淡：AI 提效并未推动新一代超级爆款 App 的集中涌现。在三大主流应用市场中，研究者追踪了新应用上线后三个月内的总使用量，结果发现，这个指标不仅没有随着 App 数量的增加而上升，反而处于持平甚至小幅下滑的态势。

至于所谓长尾效应假设，如果 AI 真能帮助开发者更精准地满足小众、垂直、细分的需求，这些软件上线后，至少应在小范围内积累起最基础的用户反馈。现实却是，供给的快速扩张并未带来对应的需求增长，许多应用在发布后便归于沉寂。

此外，上线前三个月内从未获得基本受众的“僵尸应用”比例正在增加。在 iOS 平台上，上线三个月内用户评分数少于 10 的新 App 占比从 79% 上升至 86%。在 Chrome 插件商店，上线三个月内下载量低于 10 次的“僵尸扩展”比例更是从 18% 升至 31%。

（来源：https://www.nber.org/papers/w35275）

AI 工具的 J 曲线

当然，从积极的一面看，AI 工具演进带来的效益同样十分显著。如果横向对比三代工具，AI 的干预点正在越来越靠近下游：第一代自动补全仅在最底层的代码编写切入；第二代同步代理将代码和文件修改进行了部分自动化，同时增强了后续两个环节的效率；第三代异步代理直接将产出推向了第四层的合并请求。

目前，层级 5（项目仓库协调）和层级 6（版本发布管理）仍是 AI 无法介入的领域：产品功能确定、跨团队的技术协调、软件交付周期管理、发布前的多环境部署等环节，依然只能由人类负责。

（来源：https://www.nber.org/papers/w35275）

为了缩小写代码与交付软件之间的差距，研究人员也指出了三条解决路径：提高 AI 的产出质量，使其生成的代码本身更加安全、可读，降低人类审查调试的精力成本；开发可自主进行代码审阅、集成测试，决策协调的“下游智能体”；以及改善应用的分发和发现机制，降低软件抵达消费者的流通阻碍。

1987 年，诺贝尔经济学奖得主罗伯特·索洛（Robert Solow）在《纽约时报书评》发文质疑：“计算机时代的产物随处可见，唯独在生产率统计中看不到。”经济史学家保罗·大卫（Paul David）1990 年发表研究证实，一项通用技术（General Purpose Technology）从被发明到真正推动生产力爆发，往往需要数十年。

经济学家埃里克·布林约尔松（Erik Brynjolfsson）和查德·西弗森（Chad Syverson）2021 年将这一规律形式化为“生产力 J 曲线”：任何跨时代的通用技术，在早期发展阶段都需要大量组织重组、流程再造、人力培训、配套基础设施等互补性资产投入，投入累积至临界点前，社会的总生产率提升往往不显著。

我们正处于新一轮 J 曲线的初期，当写代码变得空前廉价，如何用 AI 将代码变成可用的软件、让软件真正触达用户，才是下一阶段的考验。

参考内容：

https://www.nber.org/papers/w35275

运营/排版：何晨龙

注：封面/首图由 AI 辅助生成