（本文改編自我在 YouTube 影片 https://www.youtube.com/watch?v=l6lxgYeVZqs 的逐字稿）

當 Linus Torvalds（林納斯·托瓦茲）開發第一個 Linux 核心時，他已經研讀過 Minix 的原始碼，也學過電腦架構，具備所需的基礎知識，而且顯然是一位非常傑出的程式設計師。但為 386 寫出一個精簡卻能運作的 Unix 核心（剛開始的 Linux，姑且說是單一架構）這件事，其實是許多其他程式設計師與學生也能做到的。所謂許多，是指，我不知道，0.1%、千分之一、萬分之一。顯然大多數人做不到這種壯舉，但做得到的人仍然不少。如果你看看近年來的 Hacker News，就會發現有多少用 C 寫的核心、從零開始實作的 microkernel、用 Rust 寫的核心、各種花樣與形式的 kernel、為 Raspberry Pi 量身打造的小型 Unix 系統、為 ESP32 設計的作業系統等等。撰寫核心並非人人可及，但只要投入足夠的努力，不少人是能夠完成的。當然，不是每個人都能做得好。他毫無疑問是天才程式設計師，所以他做得更好。

然而，托瓦茲只有一個。事實上，他的這種實作能力並沒有告訴我們太多關於他的事：我們真正該關注的，反而是後來發生的事。

他不再寫程式碼

在眾多知名開源專案的維護者當中，他是極少數在 Linux 發展史非常早期就幾乎完全停止寫程式碼、轉而專注於領導專案的人。專注於擔任領導者、協調者，成為那個對專案目標該是什麼保持清晰思路的唯一大腦，等等。這是很罕見的事。許多維護者（包括我自己，很長一段時間以來）反而持續親自實作、不太委派工作，等等。

這也源自於對軟體不同的想像。Linux 必然得無止盡地成長：一個想要涵蓋眾多裝置、平台、子系統，並持續適應時代、適應新軟體的需求、適應陸續問世的硬體的核心，其本質就是如此。所以這並非錯誤。相反地，Redis 則可以保持自成一體的東西。前幾天，我在 linenoise 上收到來自 SQLite 的 Richard Hipp（理查·希普）博士的一個 pull request：他同樣追求穩定、極簡與效能，但始終讓程式碼庫保持非常精簡，而且很長一段時間都持續親自寫程式碼。而托瓦茲則不然。他立刻就明白，對於一個注定會遠比單一個人的實作能力所能負荷還要龐大的專案，他必須把時間奉獻給更重要的事。

於是他成了專案的領導者，掌握想法與方向的人。那麼，托瓦茲究竟在做什麼呢？他並非每次都逐行檢視每一個 patch。當然，他偶爾也會深入檢視某個實作，以了解實際情況。這些年來，他也曾寫過一些新的子系統，甚至重寫過：我想他多年前曾對 USB 層做過一次，他也曾對虛擬檔案系統做過，我記得他在某個時間點重新實作了它，改變了 inode 及其 inode cache 的結構，也曾因其他幾個原因這麼做。他不時仍會寫程式，像是當他打造 Git 的時候等等。但大多數時候，他並不會逐一、逐行細看每個 patch：他與各子系統的維護者溝通，並判斷某個功能或某個方向究竟是否值得走下去。

所以，用 Brooks（布魯克斯）的話來說，用 Mythical Man Month（《人月神話》）的話來說，托瓦茲掌握著核心的設計概念，並持續與核心架構中在他之下的所有人對話，讓核心朝著某個方向前進。讓各項開發朝著某個方向前進，無論是從實作的角度（這些開發如何被實作、品質如何、光是程式碼的寫法本身就體現了什麼樣的實作理念），還是從設計的角度：我們想做什麼、不想做什麼、對於模組、排程器、硬體支援、是否整合 Rust 等，什麼才是最好的策略。就是這些東西。

現在，我認為這才是托瓦茲真正的過人之處。他不僅僅是一位非常傑出的程式設計師：這樣的人還有其他人。他同時也是一位維護者、一位了不起的設計者，以及一位能夠以一致的方式駕馭龐大專案的理念與結構、並與眾多人對話的人。這件事並非人人都能做到。

現在，我們就是托瓦茲

現在，當我們與人工智慧一起寫程式時，我們正是同樣的角色。我們就是托瓦茲，雖然不一定擁有他那樣的天賦，但在那些我們不會逐行審查程式碼的專案中，我們應該扮演的角色，正是那一類。正是他所扮演的角色。

只是，這件事要掌握起來更簡單：除非我們同時大量平行使用 agent，否則它本質上比處理來自四面八方的眾多 patch 要簡單得多。但它要快得多。這就好像，與其以人類的速度與由許多人組成的團隊互動，我們是與由一、二、三個人組成的團隊互動，取決於我們當下同時開發多少個平行分支，但他們速度快得多，因此能立刻給予我們快得多的回饋。這稍微改變了工作的方式，但在我看來是往好的方向改變：更輕鬆、更少情境切換、要應付的人更少，因性格、態度等所產生的問題也少得多。

所以，如果我們認為這個角色很重要，就不該把自動化編程想成「我丟個 prompt，東西就自己寫出來」。vibe coding(氛圍編程)是對自動化編程是什麼、以及對多數人而言自動化編程將會是什麼的一種錯誤想像。vibe coding 對於那些不具備技術能力、卻仍想對自己工具的打造產生影響的人來說，是件非常有趣的事，等等：所以，歡迎它，因為它讓可能性民主化了。但它不是那回事。

相反地，自動化編程在專家技術人員、專家程式設計師、專家設計師、專家軟體架構師的手中，就是去扮演托瓦茲的角色，由 agent 與 LLM 來扮演不同子系統的各個維護者的角色。而正因為不是每個人都能把這件事做得那麼好，自動化編程同樣需要懂得與 agent 對話、檢視想法、知道哪些實作該做、哪些不該做、懂得如何與 agent 溝通以讓它們做出最好成果、並在其中放入偉大程式設計師所直覺察覺、優秀程式設計師所能直覺察覺並預先構思的那些設計提示的人才。

所以，自動化編程若要做得好，就意味著要扮演托瓦茲的角色。而這件事可以做得好，也可以做得不好，可以被理解，也可以被貶低。它也是一件需要訓練、需要學習的事，就像托瓦茲當初也必須學習一樣：他固然對此有天生的才華，但他是從「我什麼都自己實作」走到了那種駕馭一場交響樂、成為樂團指揮的能力。

對我而言，那正是托瓦茲的啟示，也是應該立刻拿來反駁那些說「嗯，有了 LLM，人人都能輕鬆寫程式」的人的論點。