AI 让代码变便宜后，工程纪律反而涨价了

Simon Willison 最近摘了一段话。原文来自 Charity Majors 的《AI demands more engineering discipline. Not less》。她的判断很硬：2025 年，代码生产的经济学被倒了过来。

过去，代码难写、慢写、贵写，所以团队会珍惜、复用、维护、整理。现在，AI 让代码生成接近免费、即时。代码从被呵护的资产，变成可丢弃、可再生的消耗品。

这句话真正刺人的地方，不是“AI 写代码快”。这已经不新鲜。问题在后面：当代码不再稀缺，组织会不会顺手把工程纪律也当成多余成本删掉？

变化不在写得快，而在稀缺资源换了

Charity Majors 说的是代码生成经济学，不是说工程师可以被替代。Simon Willison 只是摘引这段判断，也不是把它包装成自己的完整论证。

这个区别很重要。

如果只看表面，AI 编程像是把开发效率拉高了。但对真实团队来说，麻烦没有消失，只是换了位置。以前最贵的是“写出代码”。现在更贵的是“判断这段代码该不该存在”。

受影响最直接的是两类人。

一类是软件工程师。以后不能只证明自己“会写”。更要证明自己知道边界在哪里，能识别模型给出的伪正确，能把没必要的实现挡在主干外。

另一类是技术管理者和平台团队。AI 会让需求吞吐看起来更漂亮，也会让代码库膨胀更快。管理者如果只盯交付速度，很容易把评审、测试、监控压成形式。

“天下熙熙，皆为利来。”成本一变，组织行为马上跟着变。过去开发时间贵，所以团队喊复用、架构、少返工。现在生成代码便宜，最危险的误读是：既然写得快，那就少评审、少测试、少文档、少等待。

这不是效率提升，这是把账推迟到生产环境。

工程纪律不是被 AI 替代，而是被 AI 放大

我不太买账一种说法：AI 会自动让软件工程变简单。

它确实会让一些事变简单。脚手架、样板代码、一次性脚本、迁移辅助、测试初稿，这些都适合交给模型先跑一遍。开发者也会调整工作方式：先让工具生成草稿，再把精力放到设计、验证和删改上。

但软件系统真正难的部分，从来不是“敲出代码”。难的是状态、边界、兼容性、回滚、权限、数据一致性，以及半年后还有人敢改。

代码越容易生成，测试越不能省。

这里的“贵”，不是单指钱。是权重变高。过去少写一点代码，少一点风险。现在生成成本低了，风险入口变多了。测试不跟上，AI 只是把 bug 写得更快。

可观测性也一样。

手写代码时，开发者至少知道自己为什么这么写。AI 生成的逻辑看起来顺滑，错起来也顺滑。没有日志、指标、追踪和告警，团队可能连它错在哪里都找不到。

评审会变得更难。以前评审常看“这段代码写得怎么样”。以后更要看“这个变更是否应该存在”。这比挑语法、挑风格更吃判断力。

删代码能力也会成为分水岭。代码便宜之后，最容易出现的不是创新爆炸，而是仓库发胖。每个功能三版实现，每个临时方案都活成遗产。AI 让创建变轻，不能自动让组织学会清理。

这有点像早期互联网遇到零成本发布。不完全一样，但结构相似：生产门槛下降后，质量控制没有消失，只是从生产端转移到筛选端、分发端和治理端。

软件工程也会走到这一步。模型看着更强，产品反而可能更虚。因为真正撑住产品的，不是生成速度，而是验证链路。

接下来别只看模型，要看团队怎么收口

这件事接下来最该观察的变量，不是某个模型又多会写代码。

更该看四件事。

• 测试是否跟着生成速度一起扩张，还是继续靠人工补洞。
• 评审有没有从“看代码风格”转向“看变更必要性”。
• 可观测性是否成为默认配置，而不是出事后补作业。
• 团队有没有明确 owner，能不能定期删除无效代码。

这几条听起来不酷，但它们决定 AI 编程到底是加速器，还是债务制造机。

对小团队来说，诱惑是最快的。人少、需求急，AI 生成代码很容易变成“先上再说”。短期看很爽，长期会变成没人敢碰的系统。

对大团队来说，问题不在会不会用 AI，而在流程能不能承压。生成更多变更，会压到 CI、评审、发布、回滚、监控。平台团队如果没有配套自动化，最后只是把开发速度变成运维压力。

所以我更在意的不是“AI 写代码会不会继续进步”。这大概率会继续发生。真正的分水岭在组织：有没有能力把便宜代码变成可靠系统。

如果一个团队原本就靠英雄主义、口头约定和上线后祈祷在跑，AI 只会让它更快地制造混乱。如果一个团队有测试文化、可观测性、清晰 owner 和删除机制，AI 才可能变成加速器。

开头那段话的反常感就在这里：越是免费生成的东西，越需要昂贵的判断来收口。

代码可以再生。生产事故、用户信任、维护责任，不会自动再生。