代码不再稀缺，稀缺的是你如何对抗复杂度

这件事我其实是反过来理解的。

过去我们以为“写代码”本身是一种稀缺能力——会的人少、产出慢、成本高，所以工程师的价值建立在“能不能写出来”。但现在，代码正在变成一种接近“语言”的东西。你只要说得清楚，它就能被生成。于是问题开始发生偏移：不是你能不能写，而是你到底在让机器写什么。

这不是一个能力提升的问题，而是一个价值函数重构的问题。

我认为，代码边际成本趋近于零这件事，本质上改变了三个隐含前提。

第一个前提是：实现不再是瓶颈。

当实现不再稀缺，所有“把想法变成代码”的路径都会被压平。你很难再用“我能做出来”作为差异点，因为别人也可以，而且可能更快。这里有个反直觉点——效率的提升，反而让“无效尝试”指数级增加。过去写一个系统要三个月，你会非常克制；现在半天能出原型，试错成本低到你不会认真思考。

于是你看到的不是创新爆发，而是噪声爆发。

第二个前提是：复杂度开始失控。

代码变便宜之后，人类的本能不是“少写”，而是“多叠”。多写一点逻辑，多接一个API，多加一层抽象。因为成本低，所以没有约束。但复杂度不是线性增长的，它是组合爆炸的。

真正的问题在于，大模型并不会帮你管理复杂度，它只会放大复杂度。

你让它生成一个模块，它可以做得很好；但你让它维护一个系统，它没有“全局约束感”。这时候，复杂度的责任就重新落回到人身上——但人已经被“生成的便利”削弱了约束意识。

所以我越来越倾向于一个判断：
未来工程能力的核心，不是构建能力，而是约束能力。

不是你能写多少，而是你能删多少、限制多少、拒绝多少。

第三个前提，其实更隐蔽：注意力开始成为硬通货。

当一切都可以被快速生成，信息本身就不再有价值。代码也是信息。你可以生成一万行，但你无法阅读一万行。你可以让系统变复杂，但你无法理解它。

这时候，瓶颈从“生产”转向“消费”。

你有没有发现，现在真正耗时间的，不是写代码，而是理解代码、验证代码、调试代码、确认系统行为。换句话说，注意力成为系统的运行成本。

而注意力是不可扩展的。

所以这里出现了一个结构性矛盾：
生成能力指数级增长，但理解能力线性甚至停滞。
这不是效率问题，这是系统失衡。

换个角度看，这其实在逼迫一种能力重新浮出水面：系统设计能力。

不是架构图那种“设计”，而是更底层的东西——你如何划分边界，如何定义接口，如何约束状态，如何让系统在复杂度增长时仍然可控。

过去这些能力被“写代码能力”掩盖了，因为实现本身很贵；现在实现不贵了，设计的好坏就直接暴露出来。

你可以很快生成一个系统，但你很难生成一个长期可演化的系统。

这两者的差距，会越来越大。

我在想一个问题：如果代码完全免费，工程师还剩下什么？

不是语法，不是框架，不是工具链。这些都会被抽象掉。

剩下的是三件事：

• 你是否能定义问题（而不是解决问题）

• 你是否能控制复杂度（而不是扩展复杂度）

• 你是否能分配注意力（而不是消耗注意力）

这三件事，其实都不是“工程技能”，而更接近一种认知能力。

这里还有一个容易被忽略的变化。

当代码变得廉价，错误也变得廉价。

过去一个bug的代价很高，所以你会在设计阶段避免它；现在修复很快，于是大家开始接受“先生成再修”。这听起来没问题，但它隐含着一个长期风险——系统质量开始依赖“后验修正”，而不是“前置约束”。

如果系统规模小，这种方式是高效的；但当系统变大，这会变成灾难。

因为复杂系统的问题，不是bug多，而是不可预期性增加。

我不太认同一种乐观叙事：认为AI会让软件工程变得更简单。

它确实让“写代码”变简单了，但同时让“做系统”变难了。

这两件事是反向的。

所以如果非要给一个结论，我更倾向于这样表达：

代码的边际成本趋近于零，并没有降低工程的门槛，而是把门槛从“执行层”抬升到了“认知层”。

真正的问题不再是“你会不会写”，而是：

你是否知道不该写什么。
你是否能在无限生成中，维持有限秩序。
你是否能在复杂度失控之前，主动收缩系统。

这听起来不性感，但这是我目前看到的最真实的变化方向。