内容
当林纳斯·托瓦兹（Linus Torvalds）开发第一个 Linux 内核时，他研究过 Minix 的源代码，研究过计算机体系结构，具备所需的基础知识，而且他显然是一位非常杰出的程序员。但为 386 编写一个最小却可运行的 Unix 内核这件事——Linux 刚开始时，姑且可以说是单一架构——其实在很多其他程序员和学生的能力范围之内。这里说的“很多”，我是说，0.1% 吧，千分之一，万分之一。显然，大多数人都做不到这种壮举，但也有相当一部分人可以。如果你看近些年 Hacker News 上的内容，就会看到有多少项目：用 C 写的内核、从零实现的微内核、用 Rust 编写的内核、各种各样实现出来的内核、为 Raspberry Pi 纵向打造的小型 Unix 系统、ESP32 的操作系统，等等。写内核并不是人人都做得到的事，但如果投入足够的努力，很多人还是可以完成的。当然，并不是每个人都能写好。他毫无疑问是一位天才程序员，所以他做得更好。
然而，林纳斯只有一个。事实上，他这种实现能力并不能告诉我们太多关于他的事：我们真正应该关注的，是后来发生了什么。
他停止写代码
在那些著名开源项目的维护者中，他是极少数在 Linux 开发史很早期就几乎完全停止写代码、转而专注于带领项目的人之一。他把重心放在领导者、协调者、那个对项目目标应当是什么保持清晰认知的“唯一大脑”，诸如此类的角色上。这是很少见的。很多维护者（我自己也包括在内，而且很长一段时间都是如此）仍然会直接实现功能，不太愿意下放，等等。
这也源自一种不同的软件观。Linux 必然要膨胀到难以估量的规模：内核本身的特性就决定了它要覆盖很多设备、平台、子系统，并不断适应时代、适应新软件的需求、适应逐渐出现的新硬件。所以这并不是一个错误。相比之下，Redis 可以一直保持某种自洽、封闭的形态。前些天，我收到了 SQLite 的 Richard Hipp 博士在 linenoise 上提交的一个 pull request：他同样追求稳定、极简和性能，但始终保持代码库非常小，而且他很长时间都在持续写代码。林纳斯则不同。他很快就明白，自己必须把时间投入到更重要的事情上；对一个注定会变得非常庞大的项目来说，这超出了单个人的实现能力。
于是他成了项目领导者，拥有想法和方向的人。那么林纳斯具体做什么呢？他并不是每次都逐行查看每一个补丁。当然，他也会深入审视某个具体实现，以便弄清楚到底发生了什么。多年来，他有时会编写某个新的子系统，甚至重写一个子系统：我记得很多年前他曾对 USB 层做过一次这样的事情；他也做过虚拟文件系统，我记得他在某个阶段重写过它，改变了 inode 和 inode 缓存的结构；出于其他一些原因他也做过类似的事。时不时地，他仍然会亲自编程，比如他创建 Git 的时候，等等。但大多数情况下，他并不会逐个补丁、逐行细看：他会与各个子系统的维护者沟通，判断某个特性或某个方向是不是值得走下去。
所以，用布鲁克斯（Brooks）和《人月神话》（The Mythical Man-Month）里的术语来说，林纳斯掌握着内核的设计理念，并持续与内核层级中他下面的每个人对话，让内核朝着某个方向前进。让开发朝着某个方向前进——无论是从实现角度来看（这些开发具体如何实现、质量如何、代码写法本身体现的实现思路是什么），还是从设计角度来看：我们想做什么、不想做什么、模块的最佳策略是什么、调度器该怎么设计、硬件支持怎么做、要不要集成 Rust，等等。诸如此类。
现在，我认为这才是林纳斯真正的天才所在。他不仅仅是个非常聪明的程序员：这样的人还有很多。他还是一位维护者，一位不可思议的设计者，一个能够以一致的方式处理庞大项目的理念和结构、并与众多人协同对话的人。这不是人人都能做到的。
现在，我们就是林纳斯
现在，当我们借助人工智能进行编程时，我们其实就是在做同样的事。我们就是林纳斯·托瓦兹——不一定拥有他那样的天赋，但在那些不需要我们逐行审查代码的项目里，我们应当承担的角色，正是那一类角色。也正是他所扮演的角色。
只是，这件事更容易驾驭：除非我们并行使用很多 agent，否则它本质上比来自不同方向的大量补丁更容易掌控。但它快得多。就好像我们不是以人类速度和一个由很多人组成的团队互动，而是和一个由一、二、三个人组成的团队互动——取决于我们此刻在开发项目的多少条并行分支——但这些“人”快得多，因此能立刻给我们更快的反馈。这会稍微改变工作的方式，但在我看来这是更好的：更容易，减少上下文切换，要面对的人更少，因为性格、态度之类导致的问题也少得多。
所以，如果我们认为这个角色很重要，就不能把自动编程理解成“我把提示词输入进去，然后它自己写出来”。Vibe coding 对自动编程的理解是错误的，也错误地理解了自动编程对大多数人来说会是什么样子。对于那些没有技术能力、但仍然想参与构建自己工具的人来说，vibe coding 是一件非常有意思的事：所以欢迎，它确实让更多可能性变得民主化了。但它并不是那样的。
相反，在专家技术人员、专家程序员、专家设计师、专家软件架构师手里，自动编程意味着扮演林纳斯的角色，而由 agent 和 LLM 扮演不同子系统的不同维护者的角色。并且因为不是每个人都能做得那么好，自动编程同样需要有天赋的人去和 agent 对话、去检查想法、去判断哪些实现该做、哪些不该做、该怎样与 agent 沟通才能让它们产出最好的工作，在那里放入优秀程序员会直觉到、优秀程序员会直觉到并且能够预先计算出来的那些设计提示。
所以，自动编程如果做得好，本质上就是扮演林纳斯的角色。而这件事可以做得很好，也可以做得很差；可以被真正理解，也可以被贬低、被误用。它同样需要训练，需要学习，就像林纳斯也必须学会这一点：他无疑有这方面的天赋，但他确实是从“我把所有东西都实现出来”走到那种能够驾驭交响乐、成为乐团指挥的能力的。
对我来说，这就是林纳斯给我们的启示；而对于那些说“有了 LLM，编程对每个人都变得简单了”的人，这个启示应当立刻被拿来作为反例。