“Maybe later” was a feature

背景

在软件工程和产品开发领域，团队往往面临着无尽的待办事项（Backlog）。这些事项通常源于对未来的美好设想：比如为某个核心模块增加更完善的测试、将老旧的遗留系统重构为“光鲜亮丽”的新架构、迁移云服务提供商（如从 GCP 转向 AWS），或者构建一些锦上添花的功能（如在 CRM 之上增加任务管理功能，或优化基础设施中的图像处理流程）。

然而，现实是残酷的。在资源有限、优先级明确的商业环境中，许多看似诱人的想法从未被真正执行。作者认为，这种“不构建”（Not building）的行为，实际上是一种被低估的战略优势。随着 AI 编码助手（LLM）的普及，这种“选择性构建”的能力正面临前所未有的挑战。

核心内容

未被编写的代码是最有价值的

作者开篇即提出一个核心观点：仓库中最有价值的代码，往往是我没有写的那部分代码。

回顾过去，我们可能曾对某些技术改进感到兴奋，例如重写遗留网站或迁移云基础设施。但随着时间的推移，四年后回头看，那些当时被认为“稍后处理”的待办事项，实际上并没有带来任何价值。原因有二：

1. 相关性丧失：这些功能在今天已经变得无关紧要。
2. 产品转型：产品本身可能已经发生了彻底的转向（Pivot），使得这些旧功能变得多余。

如果这些功能被构建出来，它们只会成为需要维护或清理的“遗留垃圾”（Legacy cruft）。因此，不构建本身就是一种强大的功能，它加速了团队和产品的迭代，确保了资源始终集中在当下最重要的事情上。选择“不做什么”，是产品开发和战略的核心。

AI 时代的焦虑与现状

关于 AI 取代人类工作的讨论层出不穷。作者承认，从表面看，AI 在某些局部场景下确实能生成比人类更好的代码。LLM 的输出在特定任务上表现出色，但作者指出，在宏观架构和长期维护层面，AI 仍有巨大差距。

作者观察到，AI 生成的代码往往难以阅读。例如，同一个概念可能在代码库的 15 个不同地方被重复定义，或者在嵌套的 if 语句中出现 4 种不同的模式验证实现。当代码对人类来说都难以理解时，AI 自身也难以有效解析和维护它。尽管作者相信 AI 最终会进步，但目前的输出质量仍是一个痛点。

警惕“Tokenmaxxing”带来的反噬

随着 LLM 的普及，人们正在以前所未有的速度消耗 Token（Tokenmaxxing）。作者担忧的是，AI 正在让人们去构建那些原本不会被构建的功能。

过去，由于优先级筛选，许多低价值功能被自然过滤掉了。但现在，由于构建成本极低，团队可能会将积压的“待办事项”全部实现。这导致代码库膨胀，包含更多不必要的功能、框架和重复重写的内容。

更严重的是，这种趋势可能导致代码库变得对人类不可读，只能由 AI 进行接口交互。虽然理论上可以用 AI 来清理这些代码，但在实际工程中，移除代码往往比添加代码更难论证其价值。非技术人员很难理解“删除代码”如何带来净收益，且随着依赖这些新增功能的系统、人或流程增多，清理的阻力会呈指数级增长。

Hyrum 定律的阴影

最后，作者提到了 Hyrum 定律（Hyrum's Law）：只要一个系统提供了足够多的接口，无论官方文档如何定义，必然会有人依赖那些未明确承诺的行为。

如果 AI 生成的代码变得庞大且复杂，即使这些功能是“意外”产生的，也会有外部系统或内部流程依赖它们。这使得后续的重构和清理变得极其困难。因此，不编写代码，往往比编写代码能带来更大的长期价值。

关键要点

• 战略性的“不构建”：在资源受限的情况下，拒绝构建某些功能是一种主动的战略选择，它避免了技术债务和遗留垃圾的产生，确保团队聚焦于当下最重要的价值。
• AI 代码的可读性危机：目前的 LLM 生成的代码往往存在重复定义、逻辑嵌套过深等问题，导致代码可读性下降，甚至出现“人类看不懂，AI 也难维护”的局面。
• 低构建成本的陷阱：AI 降低了编码门槛，可能导致团队将原本因优先级低而被搁置的想法全部实现，造成代码库无序膨胀和功能冗余。
• 清理成本高于构建成本：在工程实践中，论证“删除功能”的价值比“添加功能”更难，且随着依赖关系的增加，移除代码的风险和成本会急剧上升。
• Hyrum 定律的制约：随着 AI 生成代码的复杂性增加，未预期的行为会被外部依赖锁定，使得后续的技术重构和清理变得几乎不可能。

意义与影响

这篇文章对当前 AI 辅助编程的狂热提出了冷静的反思。它提醒开发者和技术管理者：技术的进步不应以牺牲代码库的简洁性和可维护性为代价。

1. 对开发者的启示：在使用 AI 工具时，应保持更高的警惕性和筛选能力。AI 是强大的执行者，但不应成为战略决策的替代品。开发者需要坚守“少即是多”的原则，利用 AI 提高核心功能的效率，而不是用它来填充所有待办事项。
2. 对产品管理的启示：产品路线图应更加严格地控制范围。AI 使得“什么都可以做”成为可能，但这恰恰是危险的。产品团队需要更坚定地执行“不做”（Not building）的策略，防止功能蔓延（Feature Creep）。
3. 对技术债务管理的警示：传统的“快速迭代、后期重构”模式在 AI 时代可能失效。因为 AI 生成的代码可能更加晦涩，且依赖关系更加复杂，导致“后期重构”的成本变得不可承受。预防优于治疗，在代码生成阶段就保持克制，是降低长期技术债务的关键。

总之，“Maybe later”（稍后再说）不仅仅是一个拖延的借口，它是一种保护产品健康度和团队效率的重要机制。 在 AI 时代，这一机制的价值不降反升。