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

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

然而，林納斯只有一個。他這種實作能力，其實並不能說明太多關於他的事：我們真正該關注的，反而是之後發生的事。

他不再寫程式

在知名的開源專案維護者當中，他是極少數在 Linux 開發歷史非常早期，就幾乎完全不再寫程式，轉而專注於領導專案的人。專注於成為領導者、協調者，成為那個唯一清楚掌握專案目標該是什麼的大腦，等等。這是很罕見的事。許多維護者（很長一段時間裡也包括我自己）反而會繼續親自實作，不太授權分工，等等。

這也源於對軟體不同的想像。Linux 必然得無止盡地成長：這正是那種想要支援眾多裝置、平台、子系統，並持續跟上時代、跟上新軟體的需求、跟上陸續問世的硬體的核心本身的特質。所以這並不是一個錯誤。相反地，Redis 就可以保持為一個自給自足的東西。前幾天我還在 linenoise 上收到來自 SQLite 的 Dr. Richard Hipp 的 pull request：他同樣追求穩定、極簡與效能，但始終把程式碼庫維持得非常小，而且很長一段時間都持續親自寫程式。林納斯則不然。他立刻就明白，自己必須把時間投入到更重要的事上，因為這個專案註定會變得非常龐大，遠遠超出一個人的實作能力所能負荷。

於是他成了專案的領導者，那個掌握理念與方向的人。那麼，林納斯到底在做什麼呢？他並不是每次都逐行檢視每一個 patch。當然，他偶爾也會深入檢視某個實作，以了解究竟發生了什麼事。這些年來，他也曾寫過一些新的子系統，甚至重寫過既有的：我記得很多年前他曾對 USB 層做過一次，還有虛擬檔案系統，我記得他在某個時間點曾重寫過，改變了 inode 與 inode cache 的結構，也還有其他幾次是出於不同的原因。他不時還是會寫程式，像是後來創造 Git 的時候等等。但絕大多數時候，他並不是逐一、鉅細靡遺地逐行檢視 patch：他是與各個子系統的維護者溝通，去判斷某個功能或某個方向，究竟是不是一條該走的路。

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

在我看來，這才是林納斯真正的天才之處。他不僅僅是一位非常傑出的程式設計師：這樣的人還有其他人。他同時也是一位維護者、一位了不起的設計者，一位能夠以一貫的方式駕馭龐大專案的理念與結構、並與眾多人對話協作的人。這件事不是人人都做得到。

現在，我們就是林納斯

現在，當我們與人工智慧一起寫程式時，我們扮演的正好就是同樣的角色。我們就是林納斯·托瓦茲，未必擁有他那樣的天賦，但在那些我們不再逐行審查每一行程式碼的專案裡，我們應該承擔的角色，正是那一種。正是他所扮演的角色。

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

所以，如果我們認為這個角色很重要，就不能把自動化程式設計想成「我丟個 prompt，東西就自己寫出來」。Vibe coding 對於自動化程式設計是什麼、以及對大多數人而言將會是什麼，是一種錯誤的想像。Vibe coding 對於那些沒有技術能力、卻仍想對打造自己的工具有所影響的人來說，是件非常有趣的事，等等：所以，歡迎它的出現，因為它讓可能性變得更普及。但它不是那回事。

相反地，自動化程式設計在那些專業的技術人員、專業的程式設計師、專業的設計師、專業的軟體架構師手中，是去承擔林納斯的角色，讓 agent 和 LLM 去扮演不同子系統的維護者。而正因為不是每個人都能把這件事做得很好，自動化程式設計同樣需要那些懂得與 agent 對話、檢視構想、知道哪些實作該做、哪些不該做，懂得如何與 agent 溝通以讓它們做出最好成果，並在其中放入那些厲害的程式設計師所能直覺感知、優秀的程式設計師能夠直覺領會並預先構思的設計提示的人才。

所以，自動化程式設計如果要做得好，就意味著要承擔起林納斯的角色。而這件事可以做得好，也可以做得很糟，可以被理解，也可能被曲解、被貶低。而且它也是需要訓練、需要學習的，就像林納斯當初也必須學習一樣：他當然對此有與生俱來的天賦，但他也是從「什麼都自己實作」轉變為具備駕馭一場交響樂、成為樂團指揮的能力。

對我而言，這就是林納斯的啟示，而這個啟示應該立刻被用來反駁那些說，嗯，有了 LLM 之後，人人都能輕鬆寫程式的說法。