代码不再稀缺，稀缺的是你如何对抗复杂度
这件事我其实是反过来理解的。
过去我们以为“写代码”本身是一种稀缺能力——会的人少、产出慢、成本高，所以工程师的价值建立在“能不能写出来”。但现在，代码正在变成一种接近“语言”的东西。你只要说得清楚，它就能被生成。于是问题开始发生偏移：不是你能不能写，而是你到底在让机器写什么。
这不是一个能力提升的问题，而是一个价值函数重构的问题。
我认为，代码边际成本趋近于零这件事，本质上改变了三个隐含前提。
第一个前提是：实现不再是瓶颈。
当实现不再稀缺，所有“把想法变成代码”的路径都会被压平。你很难再用“我能做出来”作为差异点，因为别人也可以，而且可能更快。这里有个反直觉点——效率的提升，反而让“无效尝试”指数级增加。过去写一个系统要三个月，你会非常克制；现在半天能出原型，试错成本低到你不会认真思考。
于是你看到的不是创新爆发，而是噪声爆发。
第二个前提是：复杂度开始失控。
代码变便宜之后，人类的本能不是“少写”，而是“多叠”。多写一点逻辑，多接一个API，多加一层抽象。因为成本低，所以没有约束。但复杂度不是线性增长的，它是组合爆炸的。
真正的问题在于，大模型并不会帮你管理复杂度，它只会放大复杂度。
你让它生成一个模块，它可以做得很好；但你让它维护一个系统，它没有“全局约束感”。这时候，复杂度的责任就重新落回到人身上——但人已经被“生成的便利”削弱了约束意识。
所以我越来越倾向于一个判断：
未来工程能力的核心，不是构建能力，而是约束能力。
不是你能写多少，而是你能删多少、限制多少、拒绝多少。
第三个前提，其实更隐蔽：注意力开始成为硬通货。
当一切都可以被快速生成，信息本身就不再有价值。代码也是信息。你可以生成一万行，但你无法阅读一万行。你可以让系统变复杂，但你无法理解它。
这时候，瓶颈从“生产”转向“消费”。
你有没有发现，现在真正耗时间的，不是写代码，而是理解代码、验证代码、调试代码、确认系统行为。换句话说，注意力成为系统的运行成本。
而注意力是不可扩展的。
所以这里出现了一个结构性矛盾：
生成能力指数级增长，但理解能力线性甚至停滞。
这不是效率问题，这是系统失衡。
换个角度看，这其实在逼迫一种能力重新浮出水面：系统设计能力。
不是架构图那种“设计”，而是更底层的东西——你如何划分边界，如何定义接口，如何约束状态，如何让系统在复杂度增长时仍然可控。
过去这些能力被“写代码能力”掩盖了，因为实现本身很贵；现在实现不贵了，设计的好坏就直接暴露出来。
你可以很快生成一个系统，但你很难生成一个长期可演化的系统。
这两者的差距，会越来越大。
我在想一个问题：如果代码完全免费，工程师还剩下什么？
不是语法，不是框架，不是工具链。这些都会被抽象掉。
剩下的是三件事：
你是否能定义问题（而不是解决问题）
你是否能控制复杂度（而不是扩展复杂度）
你是否能分配注意力（而不是消耗注意力）
这三件事，其实都不是“工程技能”，而更接近一种认知能力。
这里还有一个容易被忽略的变化。
当代码变得廉价，错误也变得廉价。
过去一个bug的代价很高，所以你会在设计阶段避免它；现在修复很快，于是大家开始接受“先生成再修”。这听起来没问题，但它隐含着一个长期风险——系统质量开始依赖“后验修正”，而不是“前置约束”。
如果系统规模小，这种方式是高效的；但当系统变大，这会变成灾难。
因为复杂系统的问题，不是bug多，而是不可预期性增加。
我不太认同一种乐观叙事：认为AI会让软件工程变得更简单。
它确实让“写代码”变简单了，但同时让“做系统”变难了。
这两件事是反向的。
所以如果非要给一个结论，我更倾向于这样表达：
代码的边际成本趋近于零，并没有降低工程的门槛，而是把门槛从“执行层”抬升到了“认知层”。
真正的问题不再是“你会不会写”，而是：
你是否知道不该写什么。
你是否能在无限生成中，维持有限秩序。
你是否能在复杂度失控之前，主动收缩系统。
这听起来不性感，但这是我目前看到的最真实的变化方向。
