内容
在经典著作《Programming Perl》（被几代技术人亲切地称为“骆驼书”）中，拉里·沃尔曾将程序员的三种美德总结为：懒惰、急躁和傲慢：
若我们要讨论优秀软件设计，就必须谈一谈“懒惰”、“急躁”和“傲慢”——它们是良好软件设计的基石。我们都曾掉进过这样的陷阱：本应定义更高层次的抽象（哪怕只是一个循环或子程序），却直接复制粘贴。当然，也有人走向另一个极端——在明明可以复制粘贴的时候，却堆砌出越来越多的抽象层次。不过总体而言，我们大多数人其实更需要思考如何增加抽象，而不是减少。
在这三种美德中，我一直认为“懒惰”最为深刻：它那略带自嘲的幽默背后，不仅关乎抽象的必要性，更触及了抽象本身的审美价值。“懒惰”驱使我们把系统做到尽可能简单（但绝非更简单！）——从而开发出强大的抽象机制，让我们能更轻松、更高效地完成更多事情。
当然，这里隐含的调侃在于：真正的“懒惰”其实需要付出大量努力。当程序员投身于▶ 吊床驱动开发这种看似懒散的工作方式时，他们实际上是在反复推敲问题本身。我们进行这些抽象的艰苦智力劳动，部分原因正是为了优化未来自己的时间成本——哪怕牺牲当下的效率也在所不惜。一旦计算得当，这种抽象带来的成果便格外辉煌：它不仅服务于我们自己，更造福后来者。换言之，我们的“懒惰”让软件开发变得更轻松，系统组合变得更灵活——让更多人能写出更多代码。
理想情况下，那些受益于抽象的人应当将这些“懒惰的美德”传承下去——利用自己掌握的新能力，继续投入精力构建新的抽象层。然而过去二十年来软件开发的普及化趋势带来了一个副作用：越来越多原本不自称程序员的人参与其中——对他们而言，“懒惰”这一美德的本意反而失去了意义。
更糟的是，现代抽象机制带来的惊人生产力，催生了一种虚假的勤奋文化。贬义地说，这就是“码农崛起”现象——“懒惰”与“吊床式开发”被“奋斗 porn”所取代，取而代之的是关于疯狂编码的浮夸宣传。
就在这片干燥的引火物上，LLM（大型语言模型）这道闪电划破长空。无论人们对软件开发持何种态度，LLM都能以（远大于以往的）力量赋能这一过程，因此毫不奇怪，LLM已成为“码农群体”的类固醇。
沉浸在突增的“产能”中，他们再也无法保持沉默。就拿知名“码农”加里的·谭来说，他尤其热衷于炫耀自己使用LLM的成果，吹嘘自己每天能产出3.7万行代码（而且“还在加速”）：
如果“懒惰”是程序员的美德，那么以这种方式思考软件显然是一种恶习。就像按重量评判文学作品一样，其谬误连新手程序员都看得一清二楚。
至于谭用如此狂热精力构建的作品，我此前基本没怎么关注。但波兰软件工程师格雷戈雷因却将其拆解开来，结果既 predictable（可预见）、 hilarious（滑稽）又 instructive（富有启发性）：谭的所谓“新闻简报博客小工具”中竟包含多个测试框架（！！），一个 Hello World Rails 应用（？！），一个偷偷混入的文本编辑器，还有八种不同版本的同一 logo——其中一种文件大小为零字节。
问题的关键不在于这些具体缺陷（它们都容易修复！），也不在于相信这种产生这些产物的开发方法就是软件工程未来的方向（虽然这确实令人恼火！）。
真正的问题在于：LLM本质上缺乏“懒惰”的美德。对 LLM 而言，生成内容毫无成本。它不会为自身或任何人的未来时间考虑而进行优化，只会乐此不疲地在垃圾堆上不断叠加新层。任其发展，LLM 会让系统变得更大而非更好——或许迎合某些扭曲的虚荣指标，却牺牲了一切真正重要的东西。正因如此，LLM 恰恰凸显了我们人类“懒惰”的不可或缺：我们有限的时间迫使我们必须开发出清晰的抽象——因为我们不愿浪费自己（人类！）的时间去承受那些笨拙抽象带来的后果。最优秀的工程永远诞生于约束之中，而时间的约束让我们不得不接受系统认知负荷的上限。这正是我们为何要在系统本质复杂的前提下，依然努力使其更简单的原因。正如我在演讲▶ 简单的复杂性中所阐述的，这是一项艰巨的任务——我们无法指望那些不受时间或负载约束的 LLM 自发完成这项任务。
当然，这并不意味着 LLM 在未来不会发挥重要作用：它们是软件工程中 extraordinary（非凡）的工具——但正如我们在Oxide 的 LLM 使用准则中所阐述的，它终究只是工具。我们可以利用 LLM 处理那些非 ironic（非反讽）、也非 virtuous（非美德）的编程“懒惰”方面——比如帮助我们攻克技术债务这类棘手问题，或借助它们提升我们的工程严谨性——但这一切必须服务于我们自身的“懒惰美德”：最终目标是构建一个更简单、更强大的系统，它不仅能满足我们的需求，更能造福后世一代又一代的软件工程师。