AI让软件进入“一次性消费”时代!Capital One首席软件工程师:有些代码写完就该扔

Max Kanat-Alexander：一段软件能否完成目标，只取决于两件事：理解系统，以及根据这种理解采取行动。

Max Kanat-Alexander：在那样的情况下，代码质量并不重要。

Max Kanat-Alexander：对于可抛弃软件，代码质量不重要；对于耐用软件，它很重要。

一个只用半小时的CSV清洗脚本，和一个每天处理资金交易的账户系统，要不要执行同一套代码质量标准？

Max的回答很直接：不用。

AI正在把代码的生产成本压低。以前不值得专门开发的小工具，现在几分钟就能生成；需求变了，重新做一个可能比继续维护更快。

Max把这类程序称为“Disposable Software”，也就是可抛弃软件。

这并不等于开发团队从此可以随便提交代码。真正需要先回答的是：这段软件准备活多久，坏掉会伤到谁，有多少人和系统依赖它，以及重写是否真的便宜。

备注：Max Kanat-Alexander，Capital One首席软件工程师（Principal Software Engineer）他也是《Code Simplicity》和《Understanding Software》的作者，长期研究代码设计和软件复杂度。

这场演讲没有继续争论“AI代码好不好”，而是给软件划了一条更实用的边界：有些程序完成任务就该删除，有些系统仍要按未来十年的风险来建设。

以下为演讲及原文博客内容，我们进行了翻译与整理。

Max认为，测试、调试器、可观测性和代码结构最终都在帮助开发者理解系统，并据此安全行动

代码写得好不好，最后看的是还能不能改

开发者经常用可读性、测试覆盖率和编码规范描述代码质量。Max把这些指标继续往下拆了一层。

Max Kanat-Alexander：第一件事是弄清系统实际上怎样运行。不是文档声称它会怎样运行，而是它真实表现出的行为。

Max Kanat-Alexander：第二件事是，怎样正确而安全地改变这种行为。

小程序容易做到这两点。一个程序只打印“Hello World”，需求改成“Hi World”，开发者几乎不需要理解别的东西。

真实系统没有这么轻松。

Chromium内部有大量组件，每个组件还会以不同方式相互作用。任何人都很难把整个浏览器一次装进脑子里，Agent也会遇到同样的结构复杂度。工程师之所以还能修改它，是因为URL解析器、网络栈和渲染模块各自拥有清楚的职责。

Max用Chromium和Hello World程序说明，代码结构让人和AI能够分块理解复杂系统

Max Kanat-Alexander：代码最根本的作用，是为系统提供结构。

一堆难以辨认的指令，今天可能给出正确结果；几个月后再改一个需求，团队却要重新猜测每部分的用途。代码质量真正保护的，就是下一次修改发生时，开发者还能不能看懂它。

Max把技术债的增长说得很重：理解难度不会线性增加，它会随着每次修改不断叠加。系统越难理解，开发者越容易为了赶进度继续破坏结构；结构越差，下一次修改又越危险。

AI写出来的软件，可能只活一个下午

Coding Agent改变了另一个变量：替换成本。

Max Kanat-Alexander：它们正在创造一种新的软件类别。

Max Kanat-Alexander：这种软件过去也存在，但它将大量增加。这就是可抛弃软件。

Max预计，AI编程工具会让可抛弃软件的数量迅速增加

操作系统里的计算器不合手，可以让Agent重新做一个。孩子办一次聚会，需要一套邀请和日程工具，活动结束后就能删除。某次数据迁移需要检查字段，也可以生成一个只运行一次的脚本。

这些程序通常有几个共同点：用户很少，几乎没有下游系统依赖，失败后果有限，重新生成只需要几个小时，也没有长期维护计划。

当失败、依赖、替换和维护成本都很低时，Max认为代码质量不再承担长期风险

Max Kanat-Alexander：当需求发生变化时，可以直接扔掉，再从头生成一个。

支付、身份认证、订单和数据库迁移显然在另一端。它们会被大量用户和系统依赖，故障可能影响资金与数据，重写还要处理历史状态和兼容问题。Agent让代码生成得更快，也没有消除这些成本。

四个问题，决定这段代码能不能随手写

Max没有把软件简单分成“一次性”和“永久性”。他给出了一条连续的光谱，并用四个因素判断一段软件应该投入多少工程成本。

软件越靠近高后果、高依赖、高替换成本和高维护成本的一端，越需要完整的工程纪律

故障后果。失败只是重新运行一次，还是会造成资金损失、数据泄露或业务中断？

依赖关系。只有作者本人使用，还是已经被其他团队、服务和自动化流程调用？

替换成本。Agent几个小时就能重写，还是要迁移数据、兼容旧接口并完成灰度发布？

维护成本。运行一次就删除，还是需要持续升级、审计和响应故障？

Max Kanat-Alexander：未来，团队会根据软件的可抛弃程度，决定投入多少工程纪律。

可抛弃与耐用是一条连续光谱，工程投入也应随风险变化

判断时还有一个容易被忽略的地方：开发者往往低估软件会活多久。

一个临时报表被同事转发出去，很快就有第二个人使用；随后它被放进定时任务，又接入生产数据库。最初“坏了就重跑”的小工具，几个月后已经没人敢删。

所以Max建议，有经验的工程师应该倾向于把软件想得更耐用一点。真正能够放心丢弃的程序，需要把它的影响范围主动限制住。

想让代码随时能扔，先把影响范围缩小

“可抛弃”不是一句写在README里的声明。它需要系统边界配合。

Max Kanat-Alexander：为这类软件准备隔离得更好的运行环境。

Max Kanat-Alexander：不要让它接触客户数据或个人身份信息。

Max Kanat-Alexander：不允许其他生产系统反向调用这个环境中的程序。

隔离、无生产依赖、后备系统和限制用途，可以主动降低软件失败的代价

Max还提出保留冗余：后面放着一套笨重但稳定的旧系统，开发者可以在前面用Vibe Coding生成更方便的界面。新界面失败了，用户仍能退回旧系统。

这套思路和传统“把代码写好”不同。团队先限制程序能访问的数据、可以被谁调用、失败后怎样回退，再决定是否值得投入更多测试和维护。

真正的可抛弃软件，需要满足三件事：删得掉、换得起、坏得起。

临时工具一旦“转正”，技术债立刻开始计息

实际项目很难永远停在原来的位置。

下面这组“转正触发器”是根据Max的四个因素整理出的工程检查项，并非他的原话。

一次性脚本出现长期用户、生产数据、外部依赖或持续维护需求后，就应补齐耐用软件需要的工程措施

一段临时代码出现以下变化时，团队应该重新评估：开始处理生产数据；出现第二个长期用户；被其他系统调用；需要定期运行；故障开始影响业务；已经连续维护多个版本。

此时继续强调“它只是临时工具”已经没有意义。负责人、测试、监控、权限边界、文档和回滚方案都需要补上。

这个检查也适合Agent生成的内部工具。开发者不必为每个一次性脚本搭建完整平台，但要记录它何时跨过了临时与生产之间的边界。

别只让Agent堆代码，也让它把测试做便宜

演讲后半段还有一个观点：软件需要多少工程投入是一条轴，工程投入本身有多贵是另一条轴。

Max Kanat-Alexander：更值得关注的是降低工程投入的成本，让严谨变得更便宜

当自动测试、规范和工具检查足够便宜时，它们也可以覆盖可抛弃软件

标准化可以减少团队需要处理的组合。如果公司不使用PHP，就不用重复准备PHP的Lint规则、安全规范和运维知识；前后端框架越分散，每套质量工具都要重新建设。

Max把另一类工具称为“In-workflow Tooling”。检查会在工作流里自动发生，开发者不用记得手动启动，也不必成为工具专家。它足够快、稳定，并且误报率低，看起来就像没有成本。

Agent也能参与这件事。

Max Kanat-Alexander：每个服务都应该提供内存中的Fake版本。现在，Coding Agent可以帮助团队完成这项工作。

让Agent生成测试、补齐服务Fake、执行Lint和维护脚手架，比单纯用它堆更多业务代码更有长期价值。关键在于，这些能力要由团队建设成所有项目都能使用的默认设施。

写在最后

AI没有把所有代码变成一次性用品。它让以前不值得开发的小需求也能拥有软件，同时把“这段代码准备活多久”推到了设计阶段。

真正一次性的程序，可以少一些仪式，完成任务后及时删除。进入生产、连接数据、被别人依赖的系统，需要尽早补上结构、测试、监控和回滚。

以后评审一段Agent生成的代码，第一句话或许不该是“写得够不够漂亮”。先问它会活多久，坏掉会影响谁，删掉以后能不能在一天内重来。

这三个答案，才决定团队该为它付出多少工程成本。

参考链接：

https://ai.engineer/nyc/2026/talks/capital-one

——好文链接——

思维链并不是大模型的内心独白！Anthropic研究员：模型并非逐行写成，它是在训练中“长出来”的

AI永远不会带来就业末日！吴恩达：我的团队不招没用过Coding Agent的工程师

程序员正在失去软件选择权！RedMonk联合创始人：Agent正在成为新的“Kingmakers  ”，开发者可能从决策者退成建议者