When Code Becomes Cheap

“Talk is cheap. Show me the code.” — Linus Torvalds, August 2000

过去，一个想法是否值得实现，常常会先被开发成本筛一遍。即使 PRD 已经写好、会议里也讲出了完整愿景，真正把它变成 MVP，仍然需要几周甚至几个月的开发、测试和协作。很多想法并不是被证明没有价值，而是还没有走到验证阶段，就先停在了愿望清单里。

到了 2026 年，Coding Agent 开始改变这道筛选机制。它可能在我们还没完全想清楚问题时，就已经写出第一版实现、补上测试，并把 Demo 跑了起来。从 Idea 到 Code 的链路，从几周缩短到几小时。

变化不只是开发速度变快，而是过去稀缺的代码突然开始过剩。当实现本身不再构成主要瓶颈，新的问题就出现了：我们该生产什么，又凭什么相信它？

Just Code is Cheap

Coding Agent 可以快速生成和修改代码、运行测试，也可以与开发者一起梳理一个还很模糊的想法。对于大量模式成熟、边界相对清楚的任务，代码的生成成本已经显著下降。一个有想法的人，确实比过去更容易做出可以运行的版本。

但 Just Code is Cheap。更准确地说，变得廉价的是代码的生成、复制、修改和试错，以及将一个想法快速变成 Prototype 的过程。

这里的 Cheap 也有边界。需求越模糊、系统越特殊、真实环境约束越多，Agent 越难仅靠现有 Context 给出可靠答案。新的算法、复杂遗留系统、安全关键软件，以及那些没有被文档和开源代码充分覆盖的问题，并不会因为一次 Prompt 就突然变得简单。

更重要的是，代码便宜不代表软件便宜。一个能够运行的 Demo，和一个能够被真实用户长期使用的系统之间，仍然隔着需求判断、架构取舍、测试、部署、可观测性、安全、维护，以及大量没有写在 PRD 里的约束。Coding Agent 压缩了实现成本，却没有自动消除这些成本。

代码生产与代码验证的速度也没有同步提升。Agent 可以在很短时间里修改几十个文件，Reviewer 仍然需要理解这些修改改变了什么、遗漏了什么，以及它们是否会在未来变成事故。生成者节省下来的时间，很容易被转移成维护者和审核者的负担。

Code and Prototypes Are Cheap, Engineering Isn’t

Manu Singh Chauhan 在 Code Is Cheap. Engineering Isn’t. 中回应了 Kailash Nadh 的 Code is cheap. Show me the talk.。他的核心观点是：Coding 从来都不是 Software Engineering 的全部，甚至未必是其中最困难的部分。

Software Engineering 是一条完整的 Pipeline。从理解需求、设计方案、开发与测试，到上线后的监测、维护和迭代，代码只是其中一个重要环节。对游戏开发这样更长的生产流程来说，代码还需要与策划、美术、动画、音频、内容生产和发行协同。加速其中一环可以提高局部吞吐量，却不必然让整个系统发生质变。如果需求确认、资产生产、评审和集成没有同步变化，节省下来的时间只会变成下游新的等待与积压。

工程师在写下第一行代码之前，通常已经需要回答许多问题：这个需求为什么存在？谁真正需要它？当前运行中的系统和架构图有什么差异？我们有多少时间？哪些债务可以暂时接受？失败之后如何回滚？上线后又如何判断它是否正常？这些问题未必会直接出现在代码里，却决定了代码应该长成什么样子。

这些都不是单纯的 Coding Problem，而是 Judgment Problem。Agent 可以快速给出多个技术上合理的方案，却无法仅凭代码决定组织愿意承担哪一种风险、团队有能力维护哪一种复杂度，以及什么结果才算真正解决了问题。

组织中的沟通也不只是交换信息。它还包括协商优先级、暴露冲突、建立承诺和承担后果。Agent 可以帮助整理信息、寻找遗漏，却不能替团队完成这些关系性工作。

代码生成越快，这些判断就会越频繁。过去受制于开发成本而没有机会被尝试的方案，现在都能迅速变成一个看起来可行的版本。Agent 没有减少我们需要做的选择，它只是极大地增加了我们能够选择的东西。

这也是为什么 Code is Cheap 会紧接着变成 Prototypes are Cheap。过去，一个想法需要占用几周的开发排期；现在，一个人可能在一个下午完成原型，第二天就展示一个交互完整的 Demo。探索因此更加自由，错误方向上的产出也同样变得更加廉价。

一个漂亮的 Prototype 很容易制造已经取得进展的错觉。界面能够点击、Agent 能够回答、核心流程能够跑通，只能证明这条技术路径可以被实现，却不能证明用户真的需要它、它比现有方案更好，或者它能够在真实环境中稳定运行。Buildable、Desirable 和 Reliable 是三件不同的事。

原型越便宜，越需要在动手之前说清楚它准备验证什么：什么观察支持继续投入，什么结果说明我们应该停止，用户是否愿意迁移、付费或改变现有流程，模型在目标数据和边界场景中能否达到最低可接受的质量。否则，我们只是在以更快的速度，把一个未经验证的猜测包装成可以演示的产品。

我在之前的《从 Engineer 到 Builder》中讨论过类似的问题：AI 扩大了工程师能够独立完成的范围，也要求工程师更早接触用户、需求和分发。当实现成本下降后，我们不能再用「已经投入了很多开发时间」证明一个方向值得继续。实现越来越便宜，选择什么值得实现，反而越来越贵。

稀缺的东西发生了迁移

Code is Cheap 并没有让所有东西都变得廉价。它改变的是软件开发过程中的稀缺性分布。

过去相对稀缺的能力	现在更加稀缺的能力
将需求翻译成代码	判断需求是否值得实现
掌握语言、框架与语法	理解业务、系统与历史约束
制作一个可以运行的原型	设计能够证伪假设的验证
生产更多代码	阅读、筛选和拒绝代码
展示实现工作量	展示决策依据与验证证据
完成一次功能交付	长期承担运行和演进的责任

这不意味着 Coding 失去了价值，而是它作为稀缺能力和工作量证明的区分度正在下降。工程师的价值开始更多地出现在代码的前后两端。

在代码之前，工程师需要和产品、设计、运营以及其他开发者一起，把模糊的需求变成可讨论的目标、约束和取舍。如果输入只是一个模糊的愿望，Agent 会非常高效地把模糊变成大量具体代码，却不会自动判断最初的问题是否正确。

在代码之后，团队要面对集成、上线、观测、维护和责任。Agent 的输出通常针对当前 Prompt、当前仓库和当前验收条件；工程师还要考虑下一次迁移、半年后的维护、深夜的 On-call，以及系统失败时谁能够接管。

如果组织把工程师仅仅理解为代码生产者，并因为代码变得廉价而削弱工程能力，那么省下来的成本很可能会在集成、事故和长期维护中重新出现。

验证与学习不会自动变得廉价

验证成为新的瓶颈

AI Coding 最值得注意的问题，不是它会不会生成错误代码，人类同样会犯错，而是生成与验证的速度正在失衡。

一个 Agent 可以同时尝试多个方案、修改几十个文件并补齐测试。理论上，这扩大了开发者的搜索空间；现实中，它也制造了更多需要阅读、比较和拒绝的候选结果。如果团队仍然沿用以人工生产速度为前提的 Review 流程，最终只会得到越来越长的 PR、越来越表面的审核，以及越来越晚才暴露的问题。

因此，Code is Cheap 之后需要限制的不是生产本身，而是未经验证的生产。团队需要控制单次改动范围，让 Agent 提交更小、更容易证伪的变更；优先验证高风险的状态变化、数据边界、安全条件和不可逆操作，而不是被整齐的代码风格和完整的注释迷惑。

一次完整交付也不能只有代码。问题与约束、选择当前方案的理由、测试与验证结果、已知失败模式、监控信号、回滚方式和最终 Owner，都是交付的一部分。当代码可以被大量生成时，真正有价值的不是又多了一种实现，而是我们为什么相信这一种实现可以进入现实世界。

不要把学习过程外包出去

Code is Cheap 对有经验的工程师来说是一种能力放大器。我们可以跳过熟悉的样板工作，把更多时间放在架构、实验和过去没有精力完成的想法上。但对于还没有建立系统理解的人，它也可能成为一条绕过能力形成过程的捷径。

一个初学者可以不断要求 Agent 修改代码，直到测试通过，却始终不知道问题为什么出现、修复为什么有效。短期看，任务完成了；长期看，他没有形成能够在 Agent 犯错时接管问题的心智模型。

我在 Don’t Outsource the Learning 中将它称为一种认知负债：我们用未来的判断能力换取今天的交付速度。Code is Cheap 之后，学习不会自然发生。工具的默认目标是关闭任务，而不是培养一个能够独立判断的人。

这要求我们有意识地把一部分摩擦重新放回工作流。在请求实现之前先写下自己的假设；在接受代码之前要求解释方案和取舍；合并之前，团队中至少要有人能够解释关键状态如何变化、失败路径在哪里，以及为什么选择当前方案而不是另一个方案。

Vibe Coding 当然适合探索、个人工具和低风险原型。但当软件需要长期维护、处理真实用户的数据，或者在失败时产生现实后果，理解我们正在做什么依然重要。否则，我们可能拥有越来越多代码，却逐渐失去能够判断这些代码的人。

After Code is Cheap，我们应该做什么

在代码之前，定义意图与边界。 不要让 Agent 的第一份实现替我们决定问题的范围。先写清用户、目标、约束、不能破坏的行为，以及什么结果能够证明这次修改有效。对于原型，还要提前定义继续与停止的信号。

在代码之中，限制生成规模并挑战它的假设。 把 AI 生成的代码当成一份未经信任的 PR，而不是答案。阅读它、运行它、寻找反例，并要求它解释为什么选择当前方案。更小的任务、更窄的 Context 和更短的反馈循环，通常比一次生成一万行代码更可靠。

在代码之后，交付证据并保留责任。 测试只是证据的一部分，尤其当实现和测试来自同一个 Agent 时，还要检查它们是否共享了同一组错误假设。涉及资金、权限、用户数据和不可逆状态的修改，需要明确监控、回滚和 Owner。Agent 可以执行任务，却不能成为事故的负责人。

Show Me the Evidence

“Talk is cheap. Show me the code.” 属于一个代码生产昂贵的时代。那时，能够把想法变成代码，本身就是最有力的证明。

现在，一个能运行的版本可以在很短时间内生成，十种不同的实现也可以同时出现。代码不再足以证明理解、投入和质量。我们需要继续追问：它解决了什么问题？我们如何知道它是正确的？它在什么条件下会失败？谁理解它，又由谁承担结果？

也许这个时代新的表达应该是：

Code is cheap. Show me the evidence.

Evidence 背后仍然需要 Judgment，也需要一个愿意承担结果的 Owner。软件工程不会因为 Code is Cheap 而结束。相反，那些过去被 Coding 的可见产出遮挡的部分——问题定义、取舍、验证、沟通、维护、教学和责任，正在重新成为工程工作的中心。

After Code is Cheap，我们要做的不是继续制造更多代码，而是判断哪些代码值得存在，并为它们进入现实世界之后发生的一切负责。

参考资料

• Kailash Nadh, Code is cheap. Show me the talk.
• Manu Singh Chauhan, Code Is Cheap. Engineering Isn’t.