AI 已经改写了一大块编码工作

正方证据先摆在这里。过去一年，AI 已经不只是帮工程师补几行代码，而是开始进入软件工程里一段连续的工作流。

证据主要有四类。

  • Benchmark 在跳。2025 AI Index 里，SWE-bench 的最好成绩一年内从 4.4% 涨到 71.7%。只看这张图，结论会是“机器已经冲进软件工程腹地”。
  • 现场实验在给出正结果。Microsoft 汇总 Microsoft、Accenture 与一家匿名《财富》100 强公司的三组随机现场实验，在 4,867 名开发者样本上观察到，AI 工具让已完成任务数平均增加 26.08%。
  • 受控实验不只显示更快，也显示局部质量在变好。GitHub 对 202 名有至少五年经验的开发者做随机实验，结果是 Copilot 组通过全部单测的概率更高，代码可读性、可靠性、可维护性和批准率也更高。更早一轮经典实验里，Copilot 组在标准化任务上快了 55.8%。
  • 一线产品遥测早已超过“偶尔写点补全”的阶段。Anthropic 2026-02-18 的实测显示，Claude Code 最长会话的自主运行时长三个月内从不到 25 分钟拉到超过 45 分钟；新用户全自动批准约 20%，经验用户超过 40%；公共 API 的 agentic tool calls 里，软件工程接近 50%。

中国企业的一手材料也在指向同一件事。

  • 百度在 2025-06-23 披露，内部每天新增代码中，文心快码生成代码占比已超过 43%。
  • 百度在 2025-09-10 进一步披露，内部整体新增代码中 45% 已由 AI 生成，而前 10% 的 Agent 重度用户里，AI 完成部分甚至超过 75%。
  • 阿里云在 2024-11-26 披露，通义灵码累计生成代码超过 10 亿行，服务上万家企业。
  • 蔚来在 2025-07-29 的案例里，近 1000 名工程师常态化使用通义灵码，AI 生成代码占比超过 30%，在“天探”系统中业务增量代码最高超过 70%。
  • 中华财险在 500+ 人研发团队里，近 60% 研发人员使用通义灵码，生成并采纳代码约 20%。

这些证据共同指向一件事：AI 已经开始改写软件工程。它改写得最深的，首先还是实现层。

会写代码，不等于会接住整个系统

分歧也在这里。实现层被改写，不等于整个软件系统已经被改写。

反方证据也主要有四类。

  • Benchmark 和真实工程是两回事。AI Index 同一章里，更难的 BigCodeBench 上，顶级系统只有 35.5%，远低于人类的 97%。这说明前沿系统确实进步很快，但 benchmark 高分和真正做系统之间还有明显距离。
  • 旧 benchmark 本身也开始失去解释力。OpenAI 在 2026-02-23 公开表示，不再用 SWE-bench Verified 衡量前沿编码能力，因为污染和题目缺陷已经开始扭曲结果。
  • 更贴近真实市场任务的评估没有给出“多数任务已被拿下”的结论。SWE-Lancer 基于 1,400+ 个真实自由职业软件工程任务，总价值约 100 万美元，OpenAI 的结论是前沿模型仍无法解决多数任务。
  • 最直接的现实摩擦来自 METR。它在 16 位熟悉自己仓库的资深开源开发者、246 个真实 issue 上做随机对照实验，结果并没有更快，平均反而慢了 19%。更刺耳的是，很多参与者主观上还以为自己更快了。

这些反差说明，AI 正在重写“编码”这件事，但还没有证明自己已经重写“软件系统”。

不过，连这个反证本身也要谨慎用。METR 在 2026-02-24 的后续更新里又说，随着 2025 年底到 2026 年初 Agent 工作流扩散，后续更大样本实验已经出现严重选择偏差，研究团队认为 2026 年初 AI 很可能比 2025 年初更能提速，但新数据又不足以给出可靠点估计。它没有推翻旧结果，却清楚地告诉我们：今天这个问题已经不能只靠一组旧数据定输赢。

更值得问的是：AI 已经改写了哪一层复杂性，还卡在哪一层。

第一层：实现复杂性先被压缩

Brooks 把复杂性分成两类：本质复杂性和偶然复杂性。放到今天，先被削薄的是后者。

样板代码、API 封装、脚手架、单元测试、局部修复、文档补齐、跨语言改写、简单迁移，这些过去非常耗时但结构相对清晰的工作，现在几乎都已经被 AI 明显改写。Microsoft 的现场实验、GitHub 的受控实验、Anthropic 的产品遥测，以及百度和阿里的内部数据，指向的是同一个事实：实现层软件工程的生产函数已经变了。

这意味着一个更具体的变化：原本分散在人手里的不少实现工作，已经可以先交给模型起草、展开和回填，再由人来判断、验收和收口。

但实现复杂性被压缩，并不自动推出系统复杂性也被一并压缩。

第二层：系统复杂性还没有被接住

Parnas 讨论的是变化会沿着边界扩散。边界一旦划错，后面的每次变化都会放大代价。

AI 现在已经能把补丁写出来，但还没有被证明能替团队稳定地划对边界。

在一个成熟系统里，麻烦的部分从来不只是“有没有人能把功能写出来”，还包括：

  • 这个需求到底属于哪个上下文。
  • 这次修改会不会把另一个模块的隐含假设打穿。
  • 哪些约束写在文档里，哪些约束只活在资深工程师脑子里。
  • 哪些地方必须一致，哪些地方允许局部最优。
  • 当性能、安全、可维护性、上线时间冲突时，应该牺牲什么。

这些问题可以被 AI 辅助，但还很少被 AI 彻底解决。

SWE-Lancer 和 METR 一起看，结论会更清楚。前者说明，当任务被拉回真实世界，前沿模型还拿不下大多数真实软件工作；后者说明，在熟悉仓库、强约束、高上下文的环境里，AI 甚至可能先把速度拉低。合在一起，结论就是：实现层跃迁是真的，系统层通关还没有被证明。

第三层：组织复杂性变化更慢

Conway 说，软件系统会映射组织的沟通结构。到了 Agent 时代，这条规律还在起作用。

很多复杂性根本不长在代码里，而长在协作关系里。支付、金融、医疗、车机、政企系统之所以难，往往不在某个函数没人会写，而在产品、研发、合规、安全、运营、法务和外部接口方之间本来就存在不同目标、不同责任和不同节奏。

AI 能帮助团队更快生成局部实现，也能把 review、测试、问答、排障中的一部分工作前移或自动化，但它并不会自动消灭下面这些问题：

  • 谁有权定义系统边界。
  • 谁承担错误的最终责任。
  • 哪些规则可以形式化，哪些规则必须保留人为裁量。
  • 跨团队目标冲突由谁拍板。
  • 出现事故后，追责链路如何闭环。

也因为这些问题还在，中国信通院会在 2025 年联合工商银行、农业银行、邮储银行、百度、腾讯、阿里、华为等二十多家机构发布 AIIA/T 0219-2025《面向软件工程智能体的技术和应用要求 第1部分：开发智能体》。如果复杂性已经被直接吃掉，行业不会这么快转向“能力建设、服务能力、全流程智能体、安全合规和协同机制”的标准化。

这类标准本身就在说明：企业想要的，已经不只是一个会写代码的模型，而是能被放进真实组织的 Agent。

第四层：演化复杂性可能继续放大

Lehman 的软件演化定律今天仍然成立。系统不会停在原地，它会随着环境、需求、组织、接口和历史包袱持续变化。

AI 让修改更便宜，不一定让系统更简单；它也可能让系统更快积累演化债。

功能更容易加，原型更容易搭，局部重构更容易做，团队就更可能用更高频率持续改系统。短期看，这是生产力；中期看，如果边界、规范、评审和回归能力没有同步升级，它也会成为更快的复杂性生产机。

DORA 的 2024 预览数据能说明这一点。AI 已经广泛进入 IDE 和内部工作流，但只有 24% 的受访者对 AI 生成代码“高度信任”，而 39% 的受访者对其信任程度只有“一点”或“完全不信任”。这说明采用率和系统吸收能力不是同一个指标。

团队、行业和工具组合决定体感差异

体感差异不是错觉，变量本来就很多。

不同组织的结果会不同。

  • 初创团队、工具链轻、决策链短、历史包袱少，更容易把 AI 变成真实产出，尤其在新产品原型和 greenfield 开发里。
  • 大公司平台团队，如果有清晰规范、完整测试、可复用组件和内部知识库，也能把 AI 的收益放大。
  • 大型传统企业、跨部门流程长、审批重、遗留系统深的组织，AI 常常先重写局部实现，再卡在系统边界和上线流程。

不同行业的结果也会不同。

  • 互联网产品、内部效率工具、运营支撑系统，往往先吃到 AI 的红利。
  • 汽车、制造业只要子系统边界清晰，也能在特定模块里把 AI 用得很深，蔚来案例就是这样。
  • 金融、保险、医疗、政企等高合规行业，经常会看到“采用不慢、上线更慢”。中华财险近 60% 研发人员使用通义灵码、采纳代码约 20%，说明工具进入组织不难，把组织全链条一起改掉更难。

工具组合不同，结果也会继续分化。

  • IDE 补全和问答，主要放大的是单兵实现效率。
  • Repo-aware Agent、CLI Agent、测试 Agent、Code Review Agent，开始触碰系统层工作。
  • 当 Agent 与内部知识库、规则库、MCP、CI/CD、测试覆盖、回归验证、审计日志连起来时，它才会进入更深一层的复杂性。

问题已经从“AI 工具有没有用”转成了“你把它接到了哪一层系统里”。

AI 会吃掉一部分复杂性，但不是全部

如果“彻底解决”指在任何组织、任何行业、任何系统里都把复杂性压到接近零，今天还没有足够证据支持这个判断。

把问题改成“AI 是否会在一部分环境里吃掉越来越多原本由人承担的系统复杂性”，答案是：会，而且已经开始发生。

先被吃掉的，是下面这些环境：

  • 需求边界清晰，例外情况有限。
  • 规则可以结构化写进知识库、测试和流程里。
  • 系统有稳定接口、强可观测性和完整回归机制。
  • 团队已经把规范、规则、经验沉淀成机器可调用的上下文。
  • 错误成本可逆，允许高频试错。

更难解决的，是这些环境：

  • 需求本身持续变化，甚至彼此冲突。
  • 业务逻辑和组织权责强耦合。
  • 系统深嵌物理世界、监管体系或多方博弈。
  • 历史包袱重，隐性约束多，很多知识无法显式化。
  • 正确性标准不只是单一的“测试通过”，更是多目标平衡。

Brooks、Parnas、Conway、Lehman 放回今天，并没有变成“AI 不会进步”的证据。它们更像一组边界条件：AI 可以大幅削薄实现复杂性，也可能逐步吞掉一部分系统复杂性，但只要软件还是现实世界、组织结构和持续演化的产物，复杂性就不会像样板代码那样被一次性清掉。

更常见的误判，是把“编码已经被重写”直接翻译成“软件系统已经被重写”。前一句今天已经基本成立，后一句截至 2026 年春天还没有被证明。

更新附注

  • v1.1｜2026-03-31：补充“AI Index / SWE-bench 与 METR 反差”一节后的注释，说明 benchmark、真实开发实验和 2026 年初后续口径变化之间的差异，避免把编码基准高分误读为软件系统复杂性已被改写。
  • v1.2｜2026-03-31：重写正文论证骨架，补入 Microsoft、GitHub、Anthropic、OpenAI、DORA 与百度、阿里、蔚来、中华财险等近期证据，把问题拆成实现层、系统层、组织层和演化层，并增加不同组织、行业、工具组合下的差异化判断。
  • v1.3｜2026-03-31：改成更适合公众号发布的标题、导语和小标题，收紧文风，让文章更温和、可读，同时保留原有论证与证据结构。
  • v1.4｜2026-04-01：继续收紧全文语气，重写正反方起手段、后半段过渡句与首屏 summary / abstract / highlights，减少姿态句和解释腔，让证据与判断直接落到正文上。
  • v1.5｜2026-04-01：继续收紧标题与小标题，去掉解释腔和提问腔，把各段标题改成更直接的判断句，统一首屏与正文语气。
  • v1.6｜2026-04-01：继续清理正文里的软化词和解释词，压缩“先看 / 至少 / 很容易 / 原因很简单 / 通常”等句式，让论证更直接。