夜雨聆风
一个团队过去一天只能写出三个功能，测试、review 和上线流程虽然慢，但大致还能跟得上。现在同样的人，借助 AI 一天能产出三十个功能雏形。看起来效率提高了，问题却从另一个地方冒出来：谁来读这些代码，谁来确认它们没有破坏旧逻辑，谁来判断它们是不是应该进入系统？
Google 工程师 Adam Bender 在 Google I/O 2026 的演讲《Software engineering at the tipping point》里谈到的，不是某个新编程工具，也不是又一次“AI 会写代码了”的展示。他提醒的是另一个问题：软件开发不是只有写代码，还是一个由人、工具、流程、代码库、测试、文化和基础设施组成的生态系统。当其中一个节点突然被 AI 加速，周围所有环节都会被拖着一起承压。
代码生成变便宜，不等于软件工程变便宜。过去，软件工程的节奏大体由人写代码的速度决定。代码写得慢，测试、审查、理解、部署和维护还有时间跟上。现在，“写出一版代码”的成本被快速压低，真正稀缺的东西就往后移动了：理解这些代码，验证它们真的工作，并在未来继续维护它们。
代码多了以后，系统先要消化
先承认一个事实：AI 编程确实让很多局部动作变得容易了。写一个脚本、补一个接口、生成一组测试、搭一个原型，过去可能要半天，现在可能几分钟就有第一版。很多工程师已经不再从空白文件开始，而是从 AI 给出的半成品开始修改。
但写代码只是一个局部动作，软件工程是一个系统活动。一个功能进入真实系统之前，要经过需求理解、架构判断、代码审查、测试、部署、监控、安全、回滚、文档和长期维护。AI 加速的是其中一个节点，整个系统能不能承受这个节点的加速，是另一件事。
这也是“十倍代码产出”真正让人不安的地方。它不只是让团队更快地得到结果，也让团队更快地得到一堆需要处理的东西。代码变多以后，工程团队面对的不是空白文件，而是一堆等待被理解、被验证、被合并、被维护的半成品。以前瓶颈在“写不出来”。现在瓶颈可能变成“写出来以后怎么办”。
第一个堵点是测试
代码产出增加以后，测试会先承压。
这不是因为测试不重要，正相反，测试原本就是软件工程里最吃系统能力的部分。更多代码意味着更多路径、更多依赖、更多边界条件，也意味着更多测试成本。AI 可以一天生成五个 PR，每个 PR 看起来都能跑，CI 却开始排队，测试时间变长，flaky test 变多。一个失败到底是新代码的问题、旧测试的问题，还是环境偶发问题，工程师仍然要花时间判断。
AI 当然也可以帮忙写测试。但测试不是“有几行断言”就算完成。好的测试要代表真实业务风险，要覆盖那些系统最不该出错的地方。一个模型可以根据函数名补出几组样例，却未必知道某个折扣计算在月底结算时有多危险，也未必知道一个看似边缘的权限分支曾经导致过线上事故。
所以测试的压力不会因为 AI 能写测试而消失。代码更多以后，团队更需要判断哪些测试有意义，哪些失败值得追，哪些路径一定要守住。测试从“代码写完之后跑一遍”变成了吸收 AI 产出的第一道闸门。
第二个堵点是代码审查
AI 生成代码常常有一种危险的顺滑感。结构完整，命名合理，注释也像那么回事。它不像一段手忙脚乱写出来的临时代码，反而很容易给人一种“已经很像正式代码”的感觉。
但代码审查的难度从来不只在语法。真正难的是判断这段代码是否应该存在。它有没有绕开已有抽象？有没有破坏团队约定？有没有把一个临时需求写成长期负担？有没有让下一个维护者更难理解系统？这些问题不会因为代码长得整齐就自动消失。
当 PR 数量变多，review 不会自动变轻。过去 reviewer 可能主要在找 bug，现在还要判断这段 AI 生成的代码有没有资格进入系统。一个功能能跑，不代表它应该以这种方式被合并。一个修复通过了样例，不代表它没有绕开系统原来的边界。
这会改变 review 的性质。它不再只是检查代码写得对不对，而是在判断团队要不要接受一笔新的长期关系。一旦合并，这段代码就会进入依赖链、测试链、部署链和维护链。AI 写得快，人类并不能因此看得更快。
第三个堵点是理解
软件系统能长期活下去，靠的不只是代码能运行，还靠团队知道它为什么这样写。
人类慢慢写代码的过程中，会形成一种共同记忆。哪个模块脆弱，哪条路径不能碰，哪个 workaround 是历史遗留，哪个看似奇怪的判断其实是为了兼容老客户。这些知识不一定都写在文档里，但它们存在于讨论、review、事故复盘和长期协作中。
AI 快速生成代码以后，可能出现一种新的负债：代码在仓库里，功能看起来可用，但没人真正理解它为什么这样写。几个月后出问题，日志指向一段 AI 生成的逻辑。最早让 AI 写这段代码的人已经不记得当时的提示词，PR 描述只写了“fix edge case”，文档没有更新，测试只覆盖了当时那个样例。团队不是不能改，而是要先重新理解它为什么存在。
这不只是技术债。技术债是代码本身欠下的债，比如重复逻辑、坏味道、脆弱依赖。AI 时代还会多出认知债和意图债。认知债是团队对系统的共同理解变少，意图债是当初为什么这样设计没有被留下来。代码越容易生成，这两种债越容易被藏起来。
一篇关于 AI 时代软件健康的论文就提出，生成式 AI 可能让代码增长得快于团队理解代码的速度。问题不只是代码质量，而是团队对系统的心智模型会不会被稀释。软件不怕复杂，怕的是复杂以后没人知道复杂从哪里来。
第四个堵点是架构
AI 很擅长在局部完成任务，但软件系统最怕局部都对、整体变乱。
一个 Agent 为了完成任务，新建了一个工具函数。另一个 Agent 处理相似问题，又新建了一个类似函数。第三个 Agent 为了赶进度，绕开了原来的抽象。每次单独看都合理：它完成了当前任务，通过了当前测试，没有明显报错。但半年以后，系统里多出三套相似逻辑、五种数据格式、十几个没人敢删的适配层。
这就是架构会承压的地方。架构不是画几张图，也不是给代码分几层目录。它本质上是在维护边界：哪些东西应该放在一起，哪些变化应该被隔离，哪些规则不能被临时需求轻易绕开。
AI 不会天然尊重一个系统已经形成的边界，除非这些边界被清楚地写进上下文、测试和评审流程里。对模型来说，完成当前任务是明确目标；维护一个系统长期可理解、可演化的结构，往往是更隐性的目标。如果团队自己都说不清边界在哪里，AI 只会更快地把模糊变成代码。
这不是 AI 的道德问题，而是软件工程的老问题被放大了。执行力变便宜以后，判断和治理会变贵。过去团队因为人力有限，很多坏想法还来不及变成代码；现在坏想法也可以很快拥有一个看起来能跑的实现。
第五个堵点是维护
维护是这件事最容易被低估的部分。
代码刚生成出来时，最容易让人兴奋。功能跑通了，界面能点了，接口返回了，测试也绿了。但只要进入真实系统，代码就会进入时间。它会被依赖，被误用，被别的模块调用，被新人阅读，也会在未来某一天要求别人理解它。
几个月后，一个线上问题出现。日志指向一段 AI 生成的代码。团队打开 PR，发现当时的描述很短，只有“fix edge case”。再去找上下文，发现提示词没有留下，文档没有更新，测试只覆盖了一个具体输入。于是维护者要做的第一件事不是修改代码，而是重新追问：这段代码当时为什么要存在？它解决的是哪个真实问题？删掉会影响谁？改掉会不会破坏另一个隐藏路径？这时 AI 当初节省下来的时间，可能会在维护阶段重新出现。只是它换了一种形式，不再表现为“写代码很慢”，而是表现为“理解代码很慢”。
另一篇研究 AI 生成代码的论文也给了一个提醒。研究者分析了 6,299 个 GitHub 仓库中约 30.26 万个经过验证的 AI-authored commits，发现 AI 生成代码会引入 code smells、正确性问题和安全问题，并且有相当一部分问题会长期留在代码库里。论文里一个值得注意的数字是，研究追踪到的 AI 引入问题中，22.7% 在仓库最新版本中仍然存在。
这类研究不能简单推出“AI 写的代码都不好”。更稳妥的理解是：AI 生成的代码一旦进入真实仓库，就和人写的代码一样，会成为系统历史的一部分。它不会因为来源是 AI，就自动免于老化、误用和长期维护。
下一场竞争，不是产出更多代码
Adam Bender 在 Google I/O 2026 那场演讲里使用了 software ecology 这个视角。这个词有点抽象，但放到这里并不难理解：软件不是一堆代码文件，而是一个生态。人、流程、工具、测试、基础设施和组织文化共同决定了代码怎样被生产、吸收和演化。
如果把 AI 只当成写代码工具，就会低估它带来的变化。它加速的不是一个人敲键盘的动作，而是向整个工程系统注入更多变化。变化越多，系统越需要消化能力。
未来团队之间的差距，不一定是谁用 AI 写得最多，而是谁能把 AI 生成的东西纳入可验证、可理解、可维护的工程系统。好的测试体系会更重要，清楚的架构边界会更重要，文档和决策记录会更重要，code review 的标准会更重要。甚至，能拒绝不该合并的代码，也会变得更重要。
这不是要把 AI 编程说成麻烦。相反，代码生成变便宜是一件很大的事。它会让很多想法更快被试出来，让小团队拥有更强的执行力，也会让工程师从大量重复编码里解放出来。只是便宜的东西变多以后，新的贵东西会浮出来。
AI 编程真正改变的，也许不是程序员终于不用写代码了，而是代码第一次变得过于容易出现。过去，软件工程总是在和“写不出来”较劲。接下来，它可能要更多和“写出来以后怎么办”较劲。当代码变得便宜，软件工程不会消失。它会退到更深的地方：判断哪些代码应该存在，确认它们真的工作，留下足够的理由，让未来的人还能够接住今天的速度。
