TL;DR：AI 编程工具压缩的是“写出代码”的时间，但理解设计、审查影响、验证行为和长期维护并没有同步变快——Florian Herrengt 在 2026 年 8 月 11 日的文章中，把这层被挤压的空间称为软件工程的“中间地带”。本文结合 GitHub、METR 与 DORA 的研究核对一个关键问题：写得更快，是否真的等于生产力更高。
AI 编程工具最直观的变化，是让“写出一批能运行的代码”变得更快。一个需求可以在几小时内长出页面、接口、数据表和测试，过去需要几天的实现工作被压缩到一个下午。
但软件交付并不在代码生成时结束。团队还要理解设计、审查影响、验证行为、迁移数据、处理故障，并在几个月后继续修改。生成速度提高后，这些工作反而更容易成为新的瓶颈。
🎬 视频版（B站） ｜ 🎧 音频版（5 分 09 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇
原文所说的“中间地带”是什么
Herrengt 描述了一个常见场景：周一早上出现多个由 Agent 生成的巨大合并请求，功能看起来能运行，却没有人能清楚解释数据从哪里来、为什么增加某个抽象、失败后如何恢复。设计依据甚至只存在于一条来回改口的模型对话里。
他所谓的“工程师中间层消失”，不是一项职业分类研究，而是一个比喻：当实现和集成越来越容易，单纯把规格翻译成代码的价值可能下降；能够理解复杂系统、判断取舍并对结果负责的人会更重要。
原文中的“25,000 行合并请求”“一下午生成 20,000 行”等数字是叙事例子，不是行业平均值。文章对薪资分化和岗位减少的判断也是作者预测，不能当成已经发生的统计结论。
AI 到底让开发者快了多少
不同研究给出的答案并不一致，因为它们测量的任务完全不同。
GitHub 在一项受控实验中让 95 名专业开发者完成同一个 JavaScript HTTP 服务器任务。使用 GitHub Copilot 的一组平均用时 1 小时 11 分，未使用的一组平均用时 2 小时 41 分，前者快 55%。这是一个范围清楚、自动测试可以判断完成度的单项任务。
METR 在 2025 年研究了另一种情境：16 名熟悉大型开源项目的开发者完成自己仓库里的 246 个真实任务。允许使用当时的 AI 工具后，任务完成时间反而增加了 19%。参与者原本预计会快 24%，做完后仍主观认为自己快了 20%。
这项结果也不能推广到所有开发。它只代表 2025 年初的工具、这些开发者和成熟仓库。METR 在 2026 年公布的后续数据出现了可能的加速信号：原研究参与者子集估计快 18%，新招募开发者估计快 4%，但置信区间都包含没有提升的可能，而且不愿离开 AI 工具的开发者更容易退出实验，造成明显的选择偏差。研究团队因此决定调整实验设计。
三组结果放在一起，能得到一个更可靠的判断：AI 对明确、局部、容易验证的实现任务可能明显提速；在熟悉但复杂的长期项目中，上下文、验证和协作成本可能抵消一部分收益。不能用一个百分比概括全部软件工程。
瓶颈从敲代码移到理解变化
实现变快以后，团队要处理的变更数量和批次都可能增加。每个变更仍需要回答这些问题：
- 它是否符合真实业务约束；
- 新抽象是不是必要；
- 数据迁移失败时怎样回滚；
- 测试是否覆盖了没人想到的行为；
- 出现线上事故时，谁能解释和修复；
- 半年后还有没有人知道为什么这样设计。
图中流程是一般性的交付模型，不代表每个团队都使用相同阶段，也没有给出行业统一的速度比例。
DORA 的 2025 年研究把 AI 描述为组织能力的“放大器”：基础流程、平台和文化较强的团队更容易获得收益，原有弱点也可能被同步放大。DORA 在 2026 年的后续分析中还指出，生成阶段节省的时间经常转移到审计和验证；更高的 AI 使用与更高吞吐量、同时也与更高交付不稳定性相关。这里是关联关系，不等于 AI 单独造成了不稳定。
代码行数和 PR 数量为什么会骗人
一个人一天提交十个 PR，看起来像生产力提高了十倍。如果三个审查者接下来花两天理解、退回和重写，工作只是从生成者转移到了团队其他成员。
代码行数、PR 数量和“完成”的任务卡都属于局部产出指标。团队真正关心的是从需求到安全上线的完整周期，以及上线后的失败率、恢复时间、维护成本和知识是否有人掌握。
这并不意味着大改动永远错误，也不意味着技术债绝对不能欠。团队必须知道自己接受了什么风险、为什么此刻值得接受，以及准备怎样偿还。
“工程师两极分化”仍然只是预测
原文认为，AI 会扩大优秀工程师和较弱工程师之间的薪资差距。这是作者的判断，不是文章提供数据证明的结论。
现有证据只足以说明，AI 正在改变工程技能的相对价格。模板实现、样板代码和常规转换越来越便宜；需求澄清、系统建模、复杂度控制、测试设计、事故处理和技术取舍仍然需要大量上下文与责任承担。
初级工程师也不等于“只能写 CRUD”。原文自己举了相反例子：愿意追问、建立理解并检查假设的初级开发者，可能比已经放弃理解的资深开发者更可靠。风险不在职级，而在于是否把 AI 当作建立理解的工具，还是替代理解的借口。
怎样避免代码增长快过团队理解
团队可以从变更规模和知识所有权入手：
- 要求 Agent 把任务拆成可独立审查的小改动；
- 合并请求必须说明设计理由、替代方案和主要风险；
- 用测试和 Eval 验证行为，不只验证代码能编译；
- 数据库、权限和基础设施变更必须写回滚方案；
- 生成代码的人要能不用聊天记录解释数据流和故障模式；
- 同时衡量审查负荷、交付周期、变更失败率和恢复时间；
- 把模型对话中的关键决定整理成团队可维护的文档。
使用 AI 并不等于放弃工程判断。真正需要警惕的是，代码已经进入生产，而团队仍不知道它为什么存在、会影响谁，以及出错后该怎么办。
收看本期节目
原始资料与延伸阅读
本文由《听懂 AI》第 004 期整理而成。节目来源是 Florian Herrengt 于 2026 年 8 月 11 日发布的个人文章《AI is removing the middle class of software engineering》。原文以作者经历和判断为主，并不是就业市场或软件质量的统计研究；本文另外引入 GitHub、METR 和 DORA 的研究，核对“写得更快是否等于生产力更高”。
- Florian Herrengt，2026-08-11：AI is removing the middle class of software engineering——个人经验与观点文章。
- GitHub Research：Quantifying GitHub Copilot’s impact on developer productivity and happiness——95 名开发者完成固定 JavaScript 任务的受控实验。
- METR，2025-07-10：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity——16 名成熟开源项目开发者、246 个真实任务的随机实验。
- METR，2026-02-24：We are Changing our Developer Productivity Experiment Design——晚 2025 工具的后续信号、选择偏差和实验设计限制。
- DORA，2025：State of AI-assisted Software Development——AI 使用与组织系统、吞吐量和稳定性的研究框架。
资料说明：原文关于“中间层”、薪资和就业结构的描述属于作者观点。本文补充的研究测量了不同任务和组织情境，结果不可直接互相替代，也不能用于预测单个岗位的未来。