LLM 时代最稀缺的，不是勤奋，而是程序员的懒惰

今天 HN 上最值得认真读的一篇，是 Bryan Cantrill 写的《The peril of laziness lost》。它谈的是一个很老派的话题：Larry Wall 当年说程序员有三种美德，懒惰、急躁和傲慢。放到今天这个 AI coding 工具满天飞的环境里，这个话题反而变得更尖锐了。

因为我们现在最容易被误导的一件事，就是把"能更快地产出更多代码"误认为"更接近好的工程"。但程序员所说的"懒惰"，从来不是少干活，而是愿意花很多脑力，换未来更少的重复劳动、更低的复杂度和更清晰的抽象。它是一种对未来时间负责的习惯。

这篇文章最重要的判断，在我看来是这一句：LLM 天生没有这种美德。不是说模型没用，而是它不会像人类工程师那样，本能地讨厌以后还要继续维护一层层堆上去的垃圾。对模型来说，多写几百行、多套几层结构、多复制几个近似实现，成本几乎为零。它不会因为"下个月还得自己回来改"而感到不适，也不会真的为认知负担付出代价。

嗯，这一点非常关键。因为很多人现在谈 AI 编程，仍然在用一种很浅的生产率叙事：今天一小时写出以前一天的代码，于是效率提升了。这个说法当然不完全错，但它只看到了局部。真正的问题是，软件工程里最贵的东西通常不是"第一次把代码写出来"，而是之后长期承受这份结构的代价。包括理解成本、修改风险、边界模糊、重复逻辑、隐性耦合、测试脆弱、抽象泄漏。你今天多写出来的每一层，都可能变成未来某个人必须继续背着走的重量。

从这个角度看，LLM 其实特别容易放大一种坏倾向：用廉价生成掩盖结构债务。以前工程师如果想复制五份近似代码、再包三层抽象、再引入十几个并不真正必要的文件，至少还会因为自己写得累而犹豫一下。现在这个摩擦正在消失。于是"多就是快，快就是好"的错觉变得更强。

所以 Cantrill 那篇文章真正提醒我们的，不是"别用 LLM"，而是"别把 LLM 的高产当作工程判断本身"。模型擅长把事情做出来，但未必会主动把事情做得更简洁。它可以极大地提升局部推进速度，却不会天然替你承担系统收敛、抽象打磨和复杂度控制的责任。这部分责任，仍然在人的身上。

这也是为什么我越来越觉得，LLM 时代最稀缺的能力不是 prompt，不是自动补全，也不是一天能生成多少代码，而是另一种更旧、更不性感的能力：删掉不必要的东西，拒绝看起来聪明但实际增重的结构，把零散实现压缩成一个更稳的抽象，并且持续维护这种收敛倾向。

某种意义上说，真正好的工程师懒得维护垃圾，所以才会在一开始对结构特别挑剔。人类的有限时间和有限耐心，反而逼着我们发明好的抽象。我们想少受罪，所以会去想办法把系统变简单。这个约束本身，恰恰是好工程的重要来源。

而模型没有这种天然约束。它不会累，不会烦，也不会因为半年后还得读自己制造出来的层层包装而皱眉。于是如果团队没有很强的 review 文化、边界意识和架构判断，LLM 带来的往往不是"更优雅的软件工程"，而是"更快地累积更多需要被人类接盘的复杂度"。

这件事对实际工作有几个很直接的启发。

第一，不要再用"今天生成了多少行代码"作为任何严肃的工程指标。代码行数在 LLM 时代更不值钱了，甚至有时越多越可疑。真正该追问的是：有没有减少重复，是否让系统更容易理解，是否把一个模糊边界变清晰了。

第二，AI coding 的最佳用法，往往不是让它一路冲刺到最终产物，而是让它先替你完成那些不需要高度结构判断的脏活、累活、铺垫活，然后由人来决定该保留哪些、删掉哪些、合并哪些。也就是说，把模型当加速器，而不是把它当系统审美的来源。

第三，团队需要建立一种新的 review 习惯：不只检查"能不能跑"，还要检查"是不是写多了""是不是包装过度了""是不是把未来的维护成本偷偷借来了"。以前这是代码审查中的加分项，今后它会变成刚需。

我觉得这篇文章最好的地方，是它把一个容易被 AI 热潮淹没的老道理重新讲清楚了。软件工程并不天然奖励高产，它奖励的是在必要复杂度之上，尽量别再多加一层。而这件事，恰恰最依赖人类那种带点自私、带点审美、也带点远见的"懒惰"。

所以，如果说 LLM 正在重写软件生产方式，那程序员最该守住的，也许不是"我还能不能写得比模型快"，而是另一件更重要的事：我还能不能比模型更早地意识到，哪些东西根本不该被写出来。