AI 编程代理最迷人的地方，是它能让代码像水一样涌出来。

最危险的地方，也在这里。

2026 年 5 月 11 日，Simon Willison 在博客里摘引了 James Shore 一段判断。Shore 说得很狠：如果你的 AI coding agent 让你写代码快了两倍，你最好同时把维护成本砍掉一半；如果产出提升三倍，维护成本就得降到三分之一。否则，你不是获得生产力，而是在签一份长期苦役合同。

这句话把 AI 编码的焦点往前推了一步。只谈责任边界，还不够。责任最终会落到一个更朴素的问题上：这堆由 AI 加速进入仓库的代码，以后谁来理解、修改、测试、重构、背锅？

发生了什么：Willison 摘引了一笔维护账

这次信息很简单，但很关键。

  • 来源.Simon Willison 博客摘引 James Shore 的文章《You Need AI That Reduces Maintenance Costs》。
  • 主题.AI 编码代理不能只提高写代码速度，还必须降低维护成本。
  • 核心公式.产出提升多少，单份代码的维护成本就要反向下降多少。
  • 受影响对象.正在引入 coding agents、AI-assisted programming、agentic engineering 的软件团队。

Shore 的账可以压成一张表：

情况表面变化实际后果
产出翻倍，单份维护成本减半写得更快总维护负担大致不变
产出翻倍，单份维护成本不变写得更快总维护负担翻倍
产出翻倍，单份维护成本也翻倍写得更快总维护负担变成四倍

这里的维护成本，不只是服务器费用，也不只是工程师工时。它包括读懂代码、定位问题、补测试、改需求、排线上事故、拆旧逻辑、让新人接手。

相比只讨论 AI 生成代码后责任怎么分，Shore 补上的变量更硬：责任不是抽象伦理题，责任会变成维护账单。账单不会因为代码是人写的还是模型写的就自动消失。

为什么重要：代码多，不等于交付强

很多团队现在最容易被一个指标骗住：代码产出变多。

commit 多了，PR 多了，功能分支多了，demo 更快了。管理层看见速度，工程师也感觉自己被增强了。这些都是真的。

但软件不是一次性内容。写出来只是开始。真正的成本发生在后面：需求变了，依赖升级了，用户撞到边界条件了，安全漏洞被扫出来了，新同事打开文件后沉默了。

AI 生成的代码如果没有测试、边界、评审、重构纪律，速度越快，库存越厚。库存不是资产，周转不动就是成本。

我更在意的不是 agent 能不能写出一个可运行版本。现在很多工具已经能做到。更该问的是：它写出来的东西，三个月后还敢不敢改？半年后还能不能解释？出了事故之后，团队能不能迅速定位？

如果答案含糊，所谓效率提升就很脆。

今天省下来的半小时，可能变成下个版本里三天的排查。今天自动补出来的十个文件，可能变成没人愿意碰的一片泥地。

谁最受影响：技术负责人和团队里的“最后接盘人”

普通用户不太会直接感受到这件事。真正被推到前台的是两类人。

一类是技术负责人。

他们会被要求用 AI 提升交付速度，也会在事故、返工、延期时被要求解释为什么系统越来越难改。AI 让产出加速，组织也会自然提高预期。问题是，维护能力没有同步扩容，压力会集中落到工程管理上。

另一类是代码库里的接盘人。

也就是那些要读别人代码、改历史逻辑、给线上问题擦屁股的人。AI 写代码时很快，接盘时未必快。尤其是缺少测试、缺少领域命名、缺少架构边界的代码，最容易变成一种看似正确的噪音。

这里就回到旧问题：AI 编程代理越可靠，代码责任越难分清。

因为它看起来能干活，团队就更容易放松审查；因为它经常能跑通，责任就更容易被摊薄；因为每个人都觉得只是让工具补了一段，最后没人愿意承认整套复杂性是自己放进系统里的。

责任不是写在流程文档里的那一行。责任是系统坏掉后，谁有能力把它修回来。

我的判断：模型越会写，工程纪律越值钱

我不太买账那种轻飘飘的说法：以后代码都交给 agent，人类只负责表达意图。

这句话听起来先进，实际绕开了软件工程最难的部分。意图会变。需求会冲突。历史包袱会反噬。旧接口会牵住新功能。工程团队的核心能力，从来不只是把想法翻译成代码，而是持续管理复杂性。

AI 能写代码，甚至能写得不错。但它越能写，团队越需要更硬的约束：

  • 自动化测试能不能覆盖关键路径；
  • 代码评审有没有权力拒绝“能跑但难养”的生成物；
  • 架构边界是不是清楚；
  • 可观察性够不够定位问题；
  • 重构是不是被当成成本，而不是浪费；
  • AI 生成代码的责任归属有没有落到具体人。

没有这些，AI 不是工程能力，而是复杂性加速器。

“天下熙熙，皆为利来。”这句话放在 AI 编码上很合适。利来得很快：演示好看，速度可见，汇报容易写。但利的背面是债。软件行业过去每一轮工具提效，最后都会撞上同一堵墙：系统变大以后，治理能力跟不上。

这和早年的低代码、脚本自动化、外包堆人并不完全一样，但结构相似。入口都很便宜，后期都要还账。工具降低了创建门槛，却没有自动降低理解门槛。

真正健康的 AI 编码，不该只问“本周多写了多少代码”。更该问几件更难看的事：

  • AI 生成代码有没有减少回归 bug？
  • 新人接手模块是不是更快？
  • 重构阻力有没有下降？
  • 线上事故的定位时间有没有缩短？
  • 删除无用代码是不是更容易？

这些问题比速度指标难看，也更接近真相。

接下来该观察什么：不是产出速度，是维护曲线

判断一个团队有没有真正用好 AI 编程代理，不看它是不是每天发很多 PR。

看维护曲线。

如果 AI 让测试更完整、命名更清楚、文档更贴近代码、重构更频繁、问题定位更快，那它确实在降低维护成本。这样的 AI 才是工程增益。

如果 AI 只是让更多未经充分理解的代码进入主干，团队很快会遇到一种新型膨胀：功能看着多，系统越来越虚；模型看着更强，产品反而更难改。

这也是 Shore 那段话真正锋利的地方。它没有停在道德讨论，也没有陷入工具崇拜。它把问题拉回账本：多出来的代码，未来是不是更便宜。

软件工程不会因为模型变强就自动消失。恰恰相反，模型越强，工程纪律越值钱。

开头那股代码洪水，最后还是要流进维护的河道。河道修不好，水越大，灾越快。