摘要
1) 一句话总结 借助 AI 智能体实现 10 倍编码效率提升的同时会带来同等放大的 Bug 风险，团队必须同步升级自动化测试、CI/CD 基础设施以及沟通决策机制以保障工程质量。
2) 关键要点
- 效率提升与代码占比：亚马逊一资深工程师团队在过去三个月内借助 Coding Agent 将代码产出效率提升了 10 倍，其中 80% 的提交代码由 AI 编写。
- Agentic Coding 工作流：人类工程师的角色转变为“技术主管”，负责拆解任务、下达指令、逐行审查 AI 输出的代码，并对最终提交的 PR 负全责。
- 改变成本收益结构：AI 极大地降低了软件工程的实施成本，使过去“好但太贵”的最佳工程实践（如高仿真测试、CI/CD）变得便宜且可行。
- 低成本“风洞测试”：利用 AI 擅长编写模拟服务的特性，团队仅用几天时间（过去需数周或数月）就搭建了完整的本地高仿真模拟环境，用于端到端测试以抓取组件间的隐藏 Bug。
- CI/CD 基础设施升级：为匹配 AI 编码速度，必须将 CI/CD 的反馈循环从“小时级”压缩至“分钟级”，确保能在几分钟内发现、隔离并回滚有问题的改动。
- 沟通与决策模式转变：10 倍的代码产出要求更高的沟通效率，建议尽可能减少人员间的依赖沟通（如采用微服务方案）；同时由于开发成本降低，技术决策可以有更多试错空间，无需像过去那样反复论证。
3) 风险/缺口
- Bug 绝对数量激增：在 Bug 出现概率不变的情况下，10 倍的提交速度会导致 Bug 绝对数量翻 10 倍（例如严重的生产环境事故可能从一年一次变为每周一次）。
- 系统崩溃风险：如果仅提升编码速度而没有相应的工程规范和测试作为保障（如同赛车缺乏“下压力”），系统崩溃的概率会大幅上升。
- 旧有流程成为瓶颈：在 AI 时代，如果继续沿用耗时巨长的传统 CI/CD 流程或低效的沟通决策模式，这些旧基础设施将成为阻碍交付速度的障碍。
正文
今天看到一篇文章，作者（Joe Mag）是亚马逊的一位工程师，他所在的一个资深工程师团队，过去三个月里借助 Coding Agent，代码产出效率是普通高效团队的 10 倍。
但作者可不像傅老板那样说人类程序员要被替代，毕竟人家是专业程序员，他反而是来浇冷水的。他用亲身经历告诉我们：当你的速度提升 10 倍时，你面临的风险和瓶颈，可能也放大了 10 倍。
并且“AI Coding”带来了新的变革”——它彻底改变了软件工程中关于“成本”和“收益”的传统计算方式。
他们的用法是这样的：
他自己提交的代码里，有 80% 是 AI 写的。但这绝不是“Vibe Coding”。他们管自己的工作流叫 “Agentic Coding”（智能体编码）。AI 在这里扮演一个“能力超强、但没有责任感”的初级程序员。人类工程师则是那个经验丰富的“技术主管”或“架构师”。
工程师的工作流变成了：
-
拆解任务（自己先想明白，或者和 AI 一起头脑风暴）。
-
给 AI 下指令。
-
逐行审查 AI 的输出。
-
反复迭代，直到对质量完全满意。
-
最终提交PR，并为这些代码负全责。
这里面人的作用是最重要的，并没有闲着，只是把工作重心从手写代码转移到了“提要求”和“代码审查”上。
我以前打过一个比方：如果说 AI 编程就像汽车引擎一样，可以越来越快，但是软件项目交付速度并不会跟着一起变快，因为汽车跑得快，光引擎快还不够，还要考虑路况、司机的能力。
作者在文章中也用了一个类似的比喻：
当你在赛道上以 200 迈的速度狂飙时，你需要巨大的“下压力”来把车死死按在地面上，否则你会在第一个弯道就飞出去。
在软件工程里，“飞出去”指的就是 Bug 和系统崩溃。编码的速度上去了，相应的 Bug 出现的概率和系统奔溃的概率也会跟着上升：
-
过去：一个团队可能一年才会遇到一两次严重的生产环境 Bug。
-
现在：当你以 10 倍的速度提交代码时，哪怕 Bug 出现的 概率 不变，你遇到 Bug 的 绝对数量 也会翻 10 倍。以前一年一次的事故，现在可能每周都来一次。
这种“事故率”是任何团队都难以承受的。而很多吹捧 Vibe Coding 的人有意无意都忽略了这些问题。
要享受 AI 带来的 10 倍编码速度提升，相应的你也必须要想办法把“出问题的概率”降低 10 倍，甚至更多。
当然作者也给了一些具体建议：
- 借助 AI 降低本级搭建开发测试环境的成本，做好“风洞测试”
提高代码质量最好的办法就是加强测试。
作者一直很推崇一种“风洞测试”的思路。就像造飞机一样，在真正上天前，会把模型放进风洞里吹。
在软件里，这就是指在本地搭建一个“高仿真模拟环境”。比如，你的系统依赖了 10 个外部服务（数据库、认证、支付等），你就把这 10 个服务全本地运行或者模拟出来。然后，在你的电脑上就能完整地跑一遍端到端的测试，甚至可以模拟各种极端失败情况。
这种测试能抓出大量在“组件”之间缝隙中隐藏的 Bug。
以前为啥不做？太贵了！模拟和维护这些服务的工作量太大，大多数团队都放弃了。
现在为什么能做了？AI 擅长干这个！ AI 智能体非常擅长写这种逻辑清晰、行为明确的模拟服务。作者的团队在 AI 的帮助下，只花了几天时间，就为他们那个相当复杂的系统搭建起了一套完整的本地“风洞”。过去要几周甚至几个月的活，现在几天搞定。
- 做好持续集成部署（CI/CD）
早些年瀑布开发的时候，模块划分好后，都是各自开发，开发后再集成，集成时会很多问题，要花很长时间才能稳定下来。后来持续集成开始流行：
越早集成越早可以得到反馈，越频繁集成越是可以减少问题复杂度。
到现在 CI/CD 已经是公认的软件工程最佳实践，但真正做好的团队也不算太多，原因同样也是搭建和维护这样一套流程成本不低。另外还有一个问题就是很多团队虽然做了 CI/CD，但是流程耗时巨长，一个 PR 等所有各种测试、发布跑一遍，少则十分钟，多则上个小时。
以前没有 AI 的时候，这些问题还不明显，现在 AI 能力强了反而成了障碍。特别像汽车引擎速度上来了，还是跑在土坑路上。
所以 CI/CD 也需要跟着一起升级，把反馈循环从“小时级”压缩到“分钟级”。 你需要一套快到夸张的基础设施，能在几分钟内发现、隔离并回滚有问题的改动，让其他没有问题的改动继续前进。
- 决策和沟通系统也要升级
10 倍的代码产出，意味着也要 10 倍以上的沟通和决策效率。
以前开发个系统，需要各种开会，讨论很久，最后才开工干活，毕竟要依赖其他人的模块，要先定义好协议，否则后面都没法集成。
另外各种技术决策也要反复讨论很久，毕竟那时候开发成本高，如果决策错了返工代价太大。
而现在如果还是以前的沟通效率，会极大的拉低整体效率，也许最高效的是尽可能的减少沟通，每个人做的事情尽可能不依赖于其他人。包括我以前提到过的微服务方案，也许在 AI 时代是个不错的选择。
对技术决策来说，现在反倒是可以有更多机会试错了，不必像以前一样过于严谨的去反复论证技术决策。
AI 带来的 10 倍编码速度，它更像是一个给汽车升级了一个全新的“引擎”。如果你只是把它装在原来的“老爷车”上，你得到的不会是 10 倍的速度，而是 10 倍的问题。
AI Coding 的真正价值，不仅仅是写得快，更是它让那些过去“好是好，但太贵”的最佳软件工程实践（比如CI/CD、自动化测试）变得便宜可行了。就像你不仅仅是升级汽车的引擎，还把汽车经常跑的马路一起升级一下，以前的老司机不是让 AI 替代，而是让他们能适应新的高速引擎，给他们舒服和安全的驾驶环境。
原文：The New Calculus of AI-based Coding https://blog.joemag.dev/2025/10/the-new-calculus-of-ai-based-coding.html 译文《AI 编程带来的新变革》： https://baoyu.io/translations/the-new-calculus-of-ai-based-coding.html