AI 的热潮确实让我想起早期低代码和无代码工具的突破。我不怀疑 AI 能成为开发者的有用工具，我知道有些任务它能作为更好的工具来辅助完成。但这些论点总让我再次思考偶然复杂性与本质复杂性的问题。
布鲁克斯在《没有银弹》一文中探讨了新工具对开发者生产力的影响。要像程序员一样思考，你必须理解现实世界的复杂性。编程最好被理解为在混乱的现实之上施加简化的表征——我们称之为_抽象_——通过降低复杂性使其可理解。这让我们能够将特定情境泛化为可层层叠加的抽象层。
即使更好的工具减少了偶然复杂性，本质复杂性依然存在。我们仍需以正确的方式设计抽象和系统——一种优雅、清晰且可维护的方式——这本身就是一项复杂的工作。而这种复杂性不会消失。这类工作需要技能、经验以及从过去系统失败中艰难获得的智慧。
LLM 驱动开发的魅力在于它理应消除摩擦。拥护者们编造着开发团队一天内交付数十个功能的故事，他们指挥着多个自主运行的智能体团队，以越来越奇特的拓扑结构协同工作。我理解，软件开发有时确实繁琐且令人沮丧。能够以相对惊人的速度产出代码，并摆弄那些打磨精美的产品而非原型，这种感觉一定令人无比兴奋。
不过我需要这种摩擦。
当我初次学习一门新语言或框架时，即使是最基本的任务也会让我感到举步维艰。这感觉糟透了！而当我面对一个陌生且不熟悉的代码仓库或数据源时，我需要花上几个小时仔细审视。我常常会进行细致的研读，调出特定文件逐行查看，直到理解它们的上下文以及开发者做出的选择。我知道我可以直接让 LLM 帮我总结项目来节省时间，但我发现我需要这个过程来真正沉浸到代码中。我需要的不只是理解开发者做了哪些选择，更是理解他们为何做出这些选择，以及这些选择如何体现所用语言的约束或惯用法。我在失败中学习，如果 LLM 替我完成了这部分工作，我就无法真正理解自己在做什么。
如果编写提示词的工程师缺乏判断好坏的能力，他们就会陷入反复让 AI 硬编码来消除摩擦的循环。这可能导致一团混乱的抽象层，而留给未来团队的唯一设计文档，只是一份为几年前使用的 AI 模型写的 Markdown 指令。
也许我不使用 LLMs 的最简单原因就是，我实在是太热爱编程了，以至于我不想把它交给机器。就像如果我是艺术家或音乐家，我不会求助于 AI 一样，编程是我表达创造力的一种方式，我不会放弃这种快乐。尽管有时会极其令人沮丧，但从一个模糊的想法塑造出一个真实的系统，尤其是涉及优雅的实现或有趣的问题时，会带来深沉的喜悦。有些晚上，我合上工作笔记本，打开个人笔记本，去探索一些我想构建的有趣新东西。
编程也一直是我在困难时期的慰藉。有研究表明，玩俄罗斯方块是避免创伤后应激障碍的有效方法。其理论依据是，调动大脑中负责排列和旋转形状的部分，会妨碍创伤记忆的形成。幸运的是，我没有患 PTSD（我也并非轻视那些受其困扰的人），但确实能理解这一概念。编程就像解复杂的谜题，有时是我黑暗时刻的慰藉。
