David Heinemeier Hansson(DHH) 專訪：全新程式開發之道，從極度質疑到全面 Agent 優先
Gergely Orosz： 我感覺你非常看重軟體工程作為一門工藝的價值。
David Heinemeier Hansson (DHH)： 非常看重。我的意思是，我認為美學即是真理。當某個事物是美麗的，它往往也很可能是正確的。我認為這在數學中適用，在物理學中適用，在許多不同的領域中都適用。
Gergely Orosz： 我想知道 AI 是否有一部分影響在於：讓我們去執行那些以前根本不會去做的工作？
DHH： 我們內部著手進行的專案數量，那些如果放在以前我們連想都不會想要啟動的專案，實在是多到數不清。Jeremy 是我們公司使用 Agent 加速最極致的人之一，他說：「我們要來做 P1，我們要優化 P1。」字面意思就是，所有請求裡速度最快的那 1%，我們要讓它們變得更快。
Gergely Orosz： 現在其實有一點緊張氛圍，我發現大多數全力投入的人，他們工作得比以往任何時候都還要賣力。
DHH： 我自己現在也體會到了這一點。當你花一個小時監督這些 Agent，就能發揮出如此巨大的成效和影響力時，那種感覺真的令人無比陶醉。而我得去……你知道嗎，這並不是像限時特賣那樣。
Gergely Orosz： 在 Lex Fridman 的 Podcast 上，你那時非常有理有據地對 AI 抱持著極度懷疑的態度。
DHH： 這是一個微妙的觀點，也許聽起來有點像在為自己辯解，但其實我並不認為我的觀點有所改變，改變的是……
Gergely Orosz（開場旁白）： Ruby on Rails 的創造者現在是如何藉助 AI Agent 來改變他構建軟體的方式？David Heinemeier Hansson（常被稱為 DHH）創造了 Ruby on Rails、Omakub，並且是 37signals 的共同創辦人。六個月前，他在 Lex Fridman 的節目上痛批了 AI 寫程式工具的能力；然而，在寒假短短幾週之內，他來了個 180 度大轉彎，在所有事情上都全面轉向「AI 優先」。
在今天的對話中，我們探討了 David 和他在 37signals 的團隊如今是如何構建軟體的，以及 AI 工具如何讓他們變得比以往任何時候都更加雄心勃勃；為什麼 Ruby on Rails 未來可能會比現在更加流行，因為它非常適合與 AI Agent 協同工作；為什麼品味與美麗的軟體正變得愈發重要；為什麼優秀的設計師和在乎工藝的工程師可能會變得更加搶手；還有更多精彩內容。
如果你對於科技界經驗最豐富的開發者之一如何看待 AI 工具的實際效用感興趣，或者想了解這些工具將如何影響重視工藝的軟體工程師，那麼這一集就是為你準備的。
本集節目由 Statsig 贊助播出，Statsig 是一個集成了 Feature Flag、數據分析、實驗功能等於一體的整合平台。查看節目資訊以了解更多關於他們以及我們本季其他贊助商 Sonar 和 WorkOS 的詳細資訊。
David，非常高興能邀請到你。
DHH： 謝謝你的邀請。
Gergely Orosz： 感謝你的到來。我其實應該說，你現在人正在哥本哈根。
DHH： 那是我目前最喜歡的城市。這是一座美麗的城市，擁有太多迷人之處。
Gergely Orosz： 那麼，你最近都在忙些什麼呢？
DHH： 我總是在打造東西。我在網際網路上打造東西已經整整三十年了。我想我是在 94 年開始的，那時我第一次接觸到網路，基本上從那之後就再也沒有停下來過。
在過去的六個月裡，我打造了各式各樣的東西。其中之一是一個名為 Omakub 的全新 Linux 發行版。大約兩年多前我切換到了 Linux，一開始先花了一些時間在 Ubuntu 上，玩得很開心，但隨後我意識到，我其實想要從頭開始打造一個屬於我自己的系統，基於 Arch 和 Hyprland 來建構。所以我在 Omakub 上投入了大量時間。它最初是在我去參加利曼 24 小時耐力賽時的一個夏季隨手小專案，那整個星期裡有很多空閒等待時間，所以我就開始寫寫程式碼，然後它很快就大受歡迎。
看到在 Linux 發行版這樣一個如此擁擠的市場中——市場上大概有 7000 個不同的發行版，有些擁有悠久的歷史底蘊，很多甚至在某種程度上都有著相似的風格調性——居然還有空間容納全新的東西，這段經歷真的令人非常振奮。這也是一個極好的提醒：即使世界上所有的想法看起來都已經被別人捷足先登了，那也沒關係，因為你對它的獨特詮釋還沒有被做出來。而我把我對 Linux 的詮釋融入了進去，為我自己打造了一個完美的電腦系統，並且看到了我以往所見過的相同現象：每當我打造出某個真正能精準打中我自己個人痛點的東西時，世界上總會有成千上萬個像我一樣的人，或者至少與我的喜好足夠接近的人，也能從中體會到相同的樂趣與喜悅。無論是 Ruby on Rails、Kamal、離開雲端，還是其他任何事，都是同樣的道理。
Gergely Orosz： 是的，對於 Rails 來說，你完全就是在解決你自己的痛點。你只是在建構自己的組件，然後把將它們開源出來，一開始是這樣嗎？
DHH： 基本上是這樣。我在 2000 年代初接觸到了 Ruby，並在 2003 年我們開始構建 Basecamp 時真正將它付諸實踐。在構建它之前，我並沒有被硬性規定必須用什麼工具來開發。在此之前，我承接過很多外包專案，客戶會說「我們要用 PHP 來寫這個，因為我們有懂 PHP 的人，所以你必須用這個」。而當我們在構建自己的系統、構建 Basecamp 時，我可以自由選擇，所以我選擇了 Ruby。
在當時，Ruby 在 Web 應用程式方面幾乎沒有什麼工具，或者說非常匱乏，所以我必須自己把所有東西寫出來。而那最終演變成了 Ruby on Rails，直到今天它依然發展強勁。我目前仍然深度參與其中。我認為在某些方面，Ruby on Rails 正在迎來一場復興，因為它是構建 Web 應用程式中最節省 Token 的方式之一。它非常適合我們現在正在處理的 Agent 工作流。
我們拭目以待這能持續多久，也許再過五分鐘所有 Agent 就會開始直接寫機器碼或組合語言了，所以這股優勢也許很快就會終結；但就目前而言，Token 效率仍然至關重要，而且 Agent 產出的程式碼是否能讓人讀懂和驗證也仍然至關重要。那種情況在未來的某個時刻也可能會改變，但就目前來說，看到這些出於解決我自己痛點而誕生的專案能夠引起更大群體的共鳴，並吸引大家前來幫忙，這真的是一段非常有趣的旅程。
我的意思是，對於才剛推出大約六個多月的 Omakub 來說，我們已經擁有了大約 400 位向該發行版貢獻程式碼的貢獻者，除此之外，還有數萬人安裝了它並將其作為日常主力系統使用。所以我一直很喜歡這種發現全新、新穎且能啟發人心的事物的感覺，就像 Ruby 一樣；或者說，談論發現一個自 91 年就存在的作業系統聽起來有點奇怪，但對很多人來說，現在的 Linux 正是這樣一種新發現，因為他們以前從未在個人電腦上使用過它，所以這是他們第一次見到它。
而對我來說，能夠幫助新一代的 Linux 使用者，甚至希望是狂熱愛好者的誕生，是因為我稍微把學習曲線拉平了一點。我讓入門變得更容易，我讓預設的安裝外觀直接看起來極其驚豔，這樣他們就不會覺得自己必須先投入一百個小時去調校系統才能開始使用，這真的非常有趣。
但同樣有趣的是，無論是 Ruby on Rails 還是 Omakub，它們都不僅僅只是業餘嗜好專案。我熱愛業餘專案，而且我永遠都會做這些專案，但我也喜歡將它們應用到商業中。因此，在 37signals，我們在 Ruby on Rails 之上建立了一整個運營了二十多年的業務。我們現在在大多數開發者的機器上都運行著 Linux，因為我們現在擁有了自己的發行版。
Gergely Orosz： 所以大家是可以自由選擇的，對吧？他們可以選嗎？
DHH： 嗯……算是吧。一開始我們確實是開放自由選擇的，但在某個時間點，這樣做就不合理了。這就像在 37signals，如果有人跳出來說「我想用 Django 寫這個，我們要用 Python 和另一個框架」，即便大家都在用 Ruby on Rails 並且運行良好，這顯然是說不通的。所以我們從一開始邀請大家隨便玩玩的態度——那是我剛切換到 Linux 時，我只是說「嘿，如果你們想看看，就去看看吧」——轉變為當 Omakub 變得更加成熟認真時，我就直接說：技術團隊的所有人都全面轉向 Linux 吧。當然不包含 iOS 開發者，但任何做 Web、寫 Ruby、做 DevOps 的人，他們都應該用 Linux。
因為首先，這更接近我們實際部署的環境。我們一直都是部署在 Linux 上，從第一天起我們在伺服器端就是一家純 Linux 公司。對於開發者和系統管理員來說，我認為更貼近你的生產環境並更熟悉這些工具，本身就是一個實質上的巨大優勢。再加上，我們正在打造這個發行版，我們應該讓盡可能多的人來幫忙。而且考慮到我是這家公司的 CTO，我有權力設定技術方向，而這就是我們要走的方向。
Gergely Orosz： 你能不能做個非常簡短的回顧，談談你現在的狀態？現在整個業務處於什麼階段？你們一直在打造、一直在推出全新、令人興奮且很酷的東西，我想最近的一個應該是 Fizzy 吧？
DHH： 是的。37signals 成立於 1999 年，最初是一家網頁設計公司。兩年後的 2001 年我加入了進來，有幾年的時間我都與 Jason 一起合作接案諮詢專案。然後在 2003 年，我們開始開發 Basecamp，並在 2004 年發布了它——事實上不是在 Facebook 上線的前一天就是後一天，巧合的是我們屬於同一個時代和批次。
大約一年之內，我們意識到這個產品正迅速崛起，於是我們轉為全職投入，從一家諮詢外包公司轉型為軟體產品公司。
Gergely Orosz： 太棒了。
DHH： 那已經是 22 年前的事了，甚至還要多一點。在那段時間裡，我們推出了大量的產品。Basecamp 是第一個，也依然是規模最大、最重要的一個。這其實也蠻耐人尋味的，因為有時候你可能會抱有一種妄想：隨著你學得越來越多、經驗越來越豐富，你會變得更聰明，會有更好的點子。然而事實並非如此，有成千上萬的人，他們的第一個點子就是他們一輩子最好的點子。我毫無保留地承認，就商業角度客觀而言，Basecamp 是我們有過最好的點子。我感到無比自豪的是，我們能夠讓它持續運轉、成長並蓬勃發展了 20 多年。極少有軟體公司，更不用說軟體產品，能夠擁有這樣長久的生命力與傳奇。
但這些年來我們也嘗試了非常多的東西，並取得了其他巨大的成功。我們在 2020 年推出了我們的電子郵件服務 Hey.com。當你回想這件事時，那真的是個極其瘋狂的任務。這是一個完全由單一巨頭——擁有 Gmail 的 Google 所主導的領域。那是個好產品，雖然它有 17 年幾乎沒有真正改變過，但它非常穩定，很多人對它完全滿意。
人們在腦海中維持著一種奇妙的雙重思維：他們一方面極度討厭電子郵件，但不知為何卻從不把這件事與他們正在使用 Gmail 聯繫在一起，這我覺得很有意思。無論如何，我們推出了這個產品，它不僅是這個根深蒂固產品的競爭對手——在任何我能想到的主要類別中，該產品在美國所佔的市佔率可能比任何其他產品都要大，我記得在美國 Gmail 佔據了全部電子郵件流量的大約 85%，這聽起來很瘋狂，也許可說是 80%，總之高得驚人。基本上就是 Gmail 獨大，而其餘所有產品都擠在圖表上極小的一角。
所以我們認為，在使用了 Gmail 之後——我從……我都記不清是什麼時候註冊的了，大概是在它上線後幾週，我拿到了一個邀請碼，那真是一個非常聰明的發布方式，從那之後我就一直在用它。所以那是貨真價實用了 17 年左右的 Gmail。而在這段時間裡，我對許多運作方式不如我意的地方積累了非常多的想法。我們把所有這些想法都注入到了一個新的軟體產品中，花了將近兩年的時間開發，投入了數百萬美元的累計研發資金，並在 2020 年夏天正式推出。順便說一句，2020 年並不是個推出產品的好時機，原因有非常多，我們那時試圖找一個全世界上上下下沒有集體陷入瘋狂的空檔週。
我們好不容易挑了一週，正式上線了，然後我們就迎來了與 Apple 之間這輩子最慘烈的一場大戰。
Gergely Orosz： 跟 Apple，我記得這件事。
DHH： 最終，他們不想批准我們的 App。
Gergely Orosz： 除非你們支付那 30% 的過路費。
DHH： 除非我們支付 30% 的過路費。他們基本上打算直接說：「你們不能上架 App Store。」而對於這樣的電子郵件產品來說，這無異於死刑。
Gergely Orosz： 是的。
DHH： 你不能僅僅只存在於行動裝置上，更必須明確出現在 iPhone 上。直到今天依然如此，Hey 的絕大多數付費用戶都是 iPhone 用戶，因為那是美國最大、消費力最強的市場，而美國又是世界上消費力最強的軟體市場。因此，為了讓這項業務成立，我們必須出現在 iPhone 上。
在經過長達兩週史詩般的來回拉鋸戰後——值得慶幸的是，當時機點恰逢 WWDC，Apple 最好是不希望自己看起來像個正在無情碾壓微小開發者的龐大歌利亞巨人——我們最終獲准上架，而 Apple 事後也稍微重寫了規則來讓這件事合規。這是一個小勝利，雖然不是最終的徹底勝利，但至少它讓我們能夠立足於那裡。
而 Hey 最終取得了巨大的成功，諷刺的是，部分原因正是因為 Apple 在那兩週內給予了我們鋪天蓋地的全媒體曝光。回想起來，我覺得我當時如果知道後果是不會去冒那種險的，因為那種賭局的另一面可能就是零，對吧？如果 Apple 堅決拒絕我們的 App，我們大概只能簽下 200 個用戶，然後整個 App 就直接死透了。然而實際發生的卻是，他們為我們提供了一場價值數百萬美元的發布宣傳活動，所有主流媒體都在報導，我們在最初的幾週內就吸引了數萬名用戶註冊。
那真是一場無比瘋狂的事件，但也令人非常痛快。而另一件令人滿足的事是，我真的很愛 Hey，我每天都在用它。在 Web 應用程式方面，我基本上主要就用 Basecamp，我們所有協同工作都在那裡進行；然後我的第二大應用，很多時候甚至是第一大應用，就是 Hey。因為我所有的事務都是在電子郵件中處理的。我不停地在與人溝通、在寫作，就像很多人一樣在電子郵件裡做很多事。讓這件事成為一種愉悅的體驗、一個美好的環境，並且讓我的收件匣比 Gmail 那樣更具神聖感——在 Gmail 裡，全世界任何素昧平生的陌生人只要發一封信，如果你的通知是開啟的（而且預設就是開啟的），就能讓你的口袋震動，這在我看來簡直是瘋了，對吧？這種任何人都能直接把東西塞進我每天最重要的優先事項清單的想法，實在是太瘋狂了。
總之，Hey 不會這樣。我們有篩選器（Screener），在你自己明確表示「我想收到這個人的信」之前，任何人都無法直接進入你的收件匣。大多數時候我對大多數人都說「不」，對吧？信件會進到篩選器裡，我們有「讚」代表我願意收到此人的信，以及「倒讚」代表我永遠不想再收到這個人的信。
Gergely Orosz： 我就是這樣聯繫上你的。我的意思是，我不確定我們之前有沒有在 X 上互相關注，但我寄了一封電子郵件，因為你的信箱是公開的，而你的篩選器看來起作用了，因為它給了我「讚」。
DHH： 它確實起作用了，因為那個篩選器就是我本人。根本不需要靠 AI 去猜測我想不想收到你的信，因為事實證明，每天花一次時間看過篩選器並按下讚或倒讚，其實並沒有那麼繁重累人，因為世界上的人也就那麼多。而只要你對那些煩人的推銷業務員說「不」——在 Gmail 裡那些人能想方設法把信寄進你的收件匣七次——那麼你的工作量就會少得多。
我必須說這也讓人非常痛快，因為以前使用 Gmail 時，我總會掉進那些業務員依賴的話術圈套中。也就是你回覆說：「不用了，謝謝，我沒興趣。」然後他們又會再回覆，這時你就會覺得：「等等，我現在是有義務要再回覆這個人嗎？我總覺得我好像有義務。」偶爾我甚至真的回了；而就算我不回，他們依然握有直接進入我收件匣的權限，所以我下週還會再收到他們的信。他們有一整套自動跟進郵件排程（Drip campaign），他們每個人他媽的都搞這一套，對吧？任何推銷都不會只寄一封，一定是連寄七封；如果你表現出任何一絲活著的跡象，那大概就會變成五十二封。
在 Hey 裡根本不是這樣運作的。我點一次倒讚，就永遠不會再收到這個人的信了。你能以多麼驚人的速度將你的花園清除掉這些雜草，簡直令人難以置信，接著瞬間就只剩下美麗的花朵。突然之間，電子郵件不再是一件苦差事，你會想去駐足聞聞玫瑰花香。突然間，絕大多數出現在我信箱裡的東西都是我想讀的，都是來自我想聯繫的人。
這正是我們打造 Hey 的根本使命：我們能讓電子郵件重新變得討人喜歡嗎？電子郵件被這麼多人痛恨，是因為現有的系統太爛了，因為它們建立在最初的前提之上——即電子郵件只是大學裡科學家們彼此交談的工具，而科學家非常有禮貌，絕不會為了想賣你某個愚蠢的 App 而煩你五十二次。不，他們互相尊重而且品行端正，對吧？那是一個美麗的理想、美麗的思想、為那些規範和那些人所設計的美麗協定。然後你把它放進廣闊的世界裡，你才意識到：啊，並不是每個人都擁有這樣的素養與禮貌，尤其是當業務推銷員介入時，你需要更好的防禦工事。
對我、對我們、對我們許許多多的客戶來說，Hey 就是那座防禦工事。它是讓人重新愛上電子郵件的一種方式。
我發現擁有一個宏大的「為什麼」（Why）其實非常重要。這可以一直追溯到維克多·弗蘭克（Viktor Frankl）的《活出意義來》。找到一個「為什麼」，能讓你在寒冷、不舒服、惱人的大雪中堅持前行——而當你用電腦打造東西時，很多事情正是如此：冷冰冰、令人不適且煩人。雖然大部分時候不應該這樣，但偶爾總是會遇到。而如果你擁有一個非常強烈的「為什麼」——我們為什麼要打造這個？這是給誰用的？我們想做些什麼來讓世界變得更好？哪怕這個目標並沒有比「讓大家重新愛上電子郵件」更宏大，但只要你能以這種方式設定它，那麼無論你需要承擔什麼重擔，扛起來都會容易得多，也會愉快得多。
Gergely Orosz： 現在正是談談我們本季贊助商 WorkOS 的好時機。擁有一個強大的「為什麼」是推動你打造出偉大產品的動力，但在你構建完成並開始向企業客戶銷售之後，他們會期望擁有諸如 SAML 單一登入（SSO）、目錄同步（Directory Sync）、稽核日誌（Audit Logs）以及細粒度權限控制等功能。這些都不是小功能，它們是龐大的系統，可能需要數月時間來構建和維護。
WorkOS 提供了 API，讓你在幾天內而不是幾個月內就能獲得具備企業就緒能力的認證和使用者管理系統，這一切都旨在無縫融入你的產品中。這就是為什麼像 OpenAI、Perplexity 和 Cursor 這樣的公司都在使用 WorkOS。專注於打造你的產品，讓 WorkOS 來為你處理企業級基礎設施。
Gergely Orosz： 說到這裡，讓我們回到 David 的話題，聊聊舊有的思維方式與全新的思維方式。戴上你身為開發者的帽子，你能跟我聊聊你們當初是怎麼構建它的嗎？你說花了兩年時間，但一開始只有一兩個人在寫嗎？作為技術人員，你顯然大量使用了 Ruby on Rails，然後我猜可能也有一些原生開發的東西。但兩年時間看起來確實很長，特別是因為你們是一家小型、敏捷的公司，你是個優秀的開發者，你們招募的也是優秀的開發者，突然之間就過了兩年。是什麼讓它花了這麼長時間？當然，它是個美麗的產品，但從表面上看，我認為作為開發者我們可能會有這種想法——我看著它會覺得：一個才華橫溢的團隊花了兩年？這基本上是 Hacker News 對所有事情的吐槽，對吧？比如「我一個週末就能搞定那個」。
DHH： 最著名的就是當年關於 Dropbox 的評論，說「我一個週末就能搞出來」。當年初代 iPod 推出時也是，說什麼才 5GB 容量、沒有 Wi-Fi、傳輸速度還不如 Nomad 之類的。我能理解，因為我自己也有同樣的本能反應。我認為這是我們身為開發者的狂妄自大（Hubris），我們總以為自己是神，可以在眨眼之間讓任何事情成真。你確實可以——以現在來說，你做一個原型甚至比一個週末還要快，對吧？在幾小時內我們就能啟動一個 Agent 搞定。
Gergely Orosz： 是的。
DHH： 但是，想清楚你到底想要打造什麼，需要花費長得多的時間；而摸索出真正值得發布的成果，所花的時間就更長了。至少對我們來說是這樣，而且我認為對任何創造出優秀產品的人來說都是如此。
Hey 最初的技術構建工作，在技術端就只有我一個人。這其實也是我們絕大多數主要產品的啟動方式：要麼就只有我一個人，有時會多一位開發者，但始終是一個極小極小的團隊，直到我們摸索出了形狀（Shape）、確定了架構，並找到了產品未來的走向。
我發現，如果你把一堆人塞進一個方向還不確定的專案裡，你的速度反而會變慢。如果你不知道自己要什麼，一百萬個人也沒辦法幫你打造出來，你必須先弄清楚自己想要什麼。我們稍後可以聊聊這個，因為這正是 AI 最近的進展帶來劇烈改變的地方——現在要得出「我想要什麼」的速度變快了。
但對於 Hey 來說，當時技術端就只有我，然後是 Jason，以及一兩位設計師，一個非常非常小的團隊。我們試圖摸索出它的形狀，試圖明白如果你要挑戰 Gmail，你不能只是做一個「藍色版的 Gmail」，沒有人會買單，沒有人會對那種東西感興趣。它必須具有新穎性——不僅僅是新奇，它還必須優秀，必須解決那些人們甚至還沒用語言清晰表達出來的、他們在 Gmail 上遇到的問題。
因為人們對 Gmail 的抱怨往往被表述為「我討厭電子郵件」，正如我們剛剛談到的，這其實是一種誤導。我的論點是：你討厭的是 Gmail，而且不僅僅是 Gmail，而是大多數建立在「任何人都能隨意存取你收件匣」這種陳舊思維上的郵件系統。但要把這些想清楚、把產品形態琢磨出來，需要耗費不少時間。而且用這種方式反覆琢磨、在沒有無限產能的情況下慢慢推敲，本身也充滿樂趣。
最初的 Basecamp 也是用同樣的方式打造出來的，在技術端完全就只有我一個人。
Gergely Orosz： 這是一種 Shape Up 的思考方式嗎？
DHH： 這裡面確實蘊含著 Shape Up 的思想——試圖讓設計師帶著對「它該如何運作」的意圖去思考，而不僅僅是「它看起來應該怎樣」。當然，弄清楚外觀也是一部分，產品應該是美麗的、獨特的、具吸引力的等等，所以這也需要時間；但搞清楚它該如何運作才是首要的，找出核心中心點是什麼、最關鍵的部分是什麼，並把這些全部梳理清楚。
但無論是 Hey 還是我們做過的所有重大產品，我們都是從一個極小的團隊開始，通常在程式端就只有一個人，設計端有一兩個人。然後我們不斷推進、推進、推進，突然之間某個東西契合上了，我們就會覺得：「這太棒了，這裡面有戲。」接著就會進入一個小幅擴展階段，我們會再拉幾個人進來；而當我們推進到大約最後 20% 的進度時，我們就會說：「好，現在我們看清整個地形了，如果大家全體投入，我們就能快得多。」
Gergely Orosz： 有一點超級有趣，你可能會覺得這是理所當然的，但這與大多數募集創投資金（VC）的新創公司——那是我非常熟悉的領域——以及像 Uber、Facebook 這樣的大公司截然不同。在那些地方，專案通常是由產品經理（PM）主導，配合可能半個設計師，先擬定出規格書（Spec），然後開發者稍後才會參與進來。而我聽到的、對我來說非常新穎的做法是：你們是由一到兩位設計師和一位開發者組成。甚至你對設計師的看法都很不一樣。你最近招募了一位設計師 Zoltán，我私底下也跟他聊過，很棒的一個人。但我的感覺是，你對設計師的理解，可能與整個產業其他人的看法相當不同。
DHH： 確實非常不同。在 37signals，設計師的存在不僅僅是為了讓規格書看起來漂亮，他們是來挖掘「規格書應該是什麼」的人。在很多層面上，他們就是產品經理。在很多情況下，他們是「如何做」與「為什麼做」的發現者；有時是推導客戶的反饋，有時純粹靠敏銳的直覺，並將其提煉為「我們應該打造什麼」以及「它應該如何運作」。
最重要的是，他們還負責去構建它。他們負責寫 CSS，負責寫 HTML，通常還會涉獵 JavaScript 和 Ruby 代碼，以達到具備實用功能的狀態。現在有了 Agent 加速，他們甚至能搞定全部的事情——不一定是以最終合併進主分支的代碼形式，但就「這是它最終應該呈現的形狀與設計」而言，他們能獨立完成整個閉環。
但我確實認為我們在這一點上非常特殊。當我們試圖招募設計師時就發現了這一點：許多在其他公司工作的設計師，並不習慣同時戴上產品經理的帽子去構想我們該做什麼，以及戴上實作者的帽子去將其具體塑造為 CSS 和 HTML。我發現，當你將這三頂帽子合而為一，你得到的是一個真正懂得自己所用材質的人。他們知道這些材料如何延展、縫線應該往哪個方向剪裁，從而能夠自然契合網際網路的肌理。
當你直接在 CSS 和 HTML 中工作時，你會更貼合這種媒介的天性。我認為這很像珠寶設計師：如果你設計珠寶，你應該了解黃金的特性、知道它如何彎曲以及它的強度；建築師也應該對承重結構具備一定的工程理解，雖然這不代表建築師會把所有工程細節包辦然後直接開始灌水泥，你依然需要工程師協助，但你越了解所使用的材料，你就越有可能順應紋理進行創作，從而讓最終成果給人的感覺是正確的、美好的。
順便跳回 Apple 的話題。我認為這也是為什麼一些長期的鐵桿粉絲——比如 Daring Fireball 的 John Gruber 等人——對 Apple 的新方向感到失望的原因之一。Apple 過去代表著那些設計精緻絕倫的 macOS 原生應用，而現在原生應用幾乎成了一種瀕危物種，基本上快死光了。現在我們到處都是 Electron——我們稍後也可以聊聊這個，在我的評價裡 Electron 承受了太多不必要的抨擊，雖然確實有很多糟糕的實作，但它本質上就是個盒子裡的網頁。然而，那種失去原生質感的失望感，我認為根源也是一樣的：Mac 原生應用的手感有一種彈性延展度，按鈕的擺放、所有被稱為原生應用的細節，要麼感覺很真實，要麼感覺很人造；而如今幾乎全是人造感，已經感受不到真實的原生靈魂了。
我認為在 Web 領域也是同樣的道理。Web 是一個龐大得多的平台，因此受到了更多的關注，有更多的人在致力於追求它的品質；但在大公司裡，能擁有這種動態機制的團隊極其罕見，甚至根本不存在。我認為這其中的一部分即將迎來改變。Agent 加速將賦予設計師更強大的能力，因此整個行業正在逐漸向我們的根本立場靠攏。
有趣的是，在程式設計這端也是如此。當我談到 Basecamp 上線時在程式端完全只靠我一個人，在很長一段時間裡，這在網路上的某些群體看來顯得毫無野心、甚至是錯誤的，甚至有人覺得這根本是在說謊——他們會說「除非你有一個大得多的團隊，否則你不可能做出任何真實、有意義、有規模的產品，因為那只會是個玩具產品，對吧？」而我從一開始的洞察就是：那純粹是一派胡言，因為你們根本沒用過 Ruby on Rails，根本沒體會過使用更好工具所能帶來的加速。
現在大家都開始意識到了，大家正在發現：「喔，如果使用 Agent 加速，單獨一個人真的可以打造出極具價值的產品。」
Gergely Orosz： 是的。
DHH： 看到整個行業開始轉向「小團隊更好」的觀點，真的非常有趣。因為現在你在溝通成本對數曲線上所節省下來的開銷，開始變得極其重要。而這正是 Agent 加速深刻改變初階工程師與資深工程師之間利益平衡的地方之一。
Gergely Orosz： 我們來聊聊這個。但在深入探討之前，我非常明顯地感受到你極度看重軟體工程作為一門工藝；但我同時也感覺到，你把設計、使用者體驗設計、打造讓人感覺良好的軟體或硬體，同樣視為一門工藝。你在尋找這樣的特質，這兩者我感受得沒錯吧？
DHH： 完全沒錯。我的意思是，我認為美學即是真理。當某個事物是美麗的，它往往也很可能是正確的。我認為這在數學中適用，在物理學中適用，在許多不同的領域中都適用——當你得出某個具備正確美學品質的事物時，就像我們擁有一種直覺，引導我們走向那種層次的美，因為它恰好也是正確的、高尚的、值得追求的。
我也深信，這正是讓人感到快樂的原因。身邊圍繞著美麗且功能完善的物品，是幸福感的重要組成部分。事實上，我也可以從反面來說：焦慮與沮喪的最大來源之一，就是當周遭的一切都很垃圾時——當一切都很卡頓、當觸控螢幕沒反應、當你不得不重開機、當你打電話給旅行社而對方什麼都辦不了，因為他們那套陳舊破爛的 COBOL 系統不允許時。這個世界充斥著不僅僅是「劣化現象」（Enshittification）——也就是事物從原本的好變成壞——甚至充斥著徹頭徹尾的糟糕、純粹的差勁。
我認為這是現代文明痛苦病態的一個嚴重來源。如果我們的身邊能圍繞著更多美麗的物品、更美麗的系統——無論是在外觀美學品質上，還是同樣在內部美學品質上——我們真的可以實質提升人類的幸福感標準。因為我發現這兩者通常處於完美的和諧之中。
Steve Jobs 當年之所以那麼在意外殼內部的電路板，是因為他直覺地知道：那些會在意印刷電路板走線佈局的人，才會是在使用者介面細節上反覆推敲琢磨的人，才會是在打開機殼的人體工學體驗上極致講究的人。
因此我認為，如果你是一個被這種美學所吸引的人（我認為每個人都是，只是大家意識到這一點的程度各有不同），你基本上別無選擇，你會想要把所有東西都做得很美。對我來說，Ruby 尤其是一門具有開創性意義的語言，因為在我看來，它能寫出最美麗的代碼，幾乎沒有任何競爭對手能比得上。有些其他東西在某種程度上也能稱得上美，例如我看到 Smalltalk 的極簡風格時會覺得它非常美麗，但那並不是我想長久居住的房子；Ruby 才是我想長住的房子，因為它具備了那種美學特質，同時又不會對其意識形態過於僵化——這本身就是一個極其罕見的特質。
我現在更常發現的是，當某個人以這種方式沉迷其中時，他們往往會顯得有些狹隘偏執，這往往是取捨的代價。而我發現 Ruby 不知為何既能保持寬廣的視野，同時又高度專注於美感。但總體而言，我們必須擁有美好的事物，必須使用美好的工具工作，必須打造出流暢優雅的互動體驗。這正是我們看待身為工匠的自我方式：我們用心打磨，直到表面再也沒有任何一根木刺殘留。
Gergely Orosz： AI 是如何改變你的工作方式的？你認為它如何改變了你的工藝？或者我們來聊聊工藝本身——你在 37signals 招募的員工同樣非常在乎設計與軟體工藝的品質。它是如何改變你在這門工藝中所獲得的成果，或者在某些方面它是如何讓它變得更好或更糟的？我想先從……你知道的，你的觀點是如何改變的開始聊起。因為上次你深入談論這個話題是在 Lex Fridman 的節目上，那時候你非常合情合理地對 AI 抱持著極度懷疑的態度。當時是一套完全不同的工具，運作得也沒那麼好，我想你當時在節目上抨擊得相當猛烈，但從那之後事情發生了變化。
DHH： 這是一個微妙的觀點，也許聽起來有點像在為自己辯解，但其實我並不認為我的觀點有所改變。改變的是客觀環境與事實——這是我在那場訪談中以及在很多其他文章中都提到過的。從一開始，我就能看出我們這裡迎來了某種全新、新穎且將會徹底改變局面的事物。大約三年前 ChatGPT 的發布，無論是在當時還是現在，顯然都是你在人類歷史時間線上必須明確標記的一個節點。你會說：「這是計算機科學史或世界歷史上發生過的所有重大事件，然後碰的一聲，ChatGPT 發布了。」以這種方式與電腦互動，並看到它們進行推理——即便「推理」這個詞可能至今仍有爭議——但在我看來顯而易見的是，這些東西聰明得不可思議，在許多方面比我更聰明。
至於這種聰明究竟是來自於權重和資料的模式模仿？那又怎樣？我們根本不知道人類的意識是如何運作的，我們對人類的智慧或智能運作方式幾乎一無所知。所以，讓我們不要對究竟什麼才構成意識或智能過於武斷地妄下定論，至少我覺得去糾結這種區分並沒有什麼實用意義，即使琢磨起來很有趣。
但我發現早期的模型和早期的人機工學——也就是自動補全（Autocomplete），像是 Copilot 和編輯器裡的 Cursor 試圖猜測你的下一個字符，有時甚至會搞得一團亂，對吧？
Gergely Orosz： 是的。
DHH： 我發現那令人無比惱火。我覺得就像我們在進行一場對話，你卻根本不讓我把一句話說完，不斷插嘴試探：「這是你想說的意思嗎？這是你想說的意思嗎？」你心裡只想喊：「閉嘴好嗎！能不能讓我把一個想法完整表達完？」而且我認為，即便它偶爾能夠帶來加速，但它出錯的頻率實在太高了，以至於那種加速反而變成了一種騷擾。即便它在整體效益上可能有些許正向——但對我來說根本不是正向，或者說可能是我太快放棄了——總之我完全不享受那種過程。我覺得那些模型還不夠好，而且我認為使用模型的這種「自動補全」形式，對比後來的「Agent Harness（代理工具架構）」形式，簡直是糟糕透頂、令人煩躁。甚至在某個短暫的瞬間，我對整個行業的發展方向感到有些悲觀，因為我以為我們以後所有人都要這麼幹了——我們全都得坐在那裡不停地按 Tab、按 Tab、按 Tab。
不，謝謝，我可不想要那樣。
Gergely Orosz： 甚至 Cursor 都有……我甚至拿到過他們的一件週邊禮品，就是一個專門的「Tab」實體按鍵。
DHH： 沒錯！
Gergely Orosz： 那感覺非常……我從他們那裡拿到的，它真的很酷，設計得非常精緻，外觀非常漂亮，但是……
DHH： 但是非常反烏托邦。
Gergely Orosz： 反烏托邦。
DHH： 當我看到那個時，我記得那有一陣子成了一個迷因——說我們的鍵盤以後只需要三個鍵就行了，對吧？我想到了《辛普森家庭》裡的一集：荷馬在鍵盤上放了一隻機械飲水鳥玩具，只會不斷低頭啄下 Enter 鍵，因為他所需要做的一切就只是狂按 Enter。直到突然警報響起，核反應爐核心即將超載爆炸，而那隻鳥依然只是機械式地猛啄 Enter，最後整個廠區徹底燒成灰燼。我心想：「哇，這比喻真是太貼切了。」《辛普森家庭》真的能預言一切。
我非常不喜歡那種使用模式，儘管我對於整個技術發展的大方向依然保留著熱情，因為那確實令人驚嘆。我試圖將那種驚嘆轉化為一種「導師模式」，或者一個「不親自掌舵的結對編程夥伴」。有 ChatGPT 和其他模型在身邊隨時待命，感覺真的很棒——比如「我不是很完全理解這段程式碼，這是一段程式碼、這是一個問題，你能告訴我它為什麼會這樣運作嗎？你能告訴我這段代碼哪裡有問題嗎？」因為從第一天起，我就是這麼使用網際網路的，對吧？以前 Google 就是用來幹這個的——這是一個錯誤訊息、這是一個概念，也許我在 Stack Overflow 上找到某個陰陽怪氣的阿宅在向所有人炫耀他有多聰明，然後在最底部才找到了我想要的解決方案；或者我根本找不到，這就讓人相當挫折。而在 ChatGPT 模型中，我非常頻繁地能得到一個極其出色的解釋。
Gergely Orosz： 是的，這其實是我和一位獨立遊戲開發者 Jonas Tyroller 聊過的情況。他開發了一款非常酷的暢銷遊戲，我很喜歡玩。那正好是在大家都在瘋 Tab 自動補全的時期，他說他的工作方式就是直接關閉 IDE 裡所有的自動補全功能，因為那讓他很煩躁；然後每隔一陣子，他會去 ChatGPT 提問，或者進行更長篇的探討。他擁有這樣的模式：我在思考、我在做事，當我需要幫助時，好，這是具體的問題細節，我拿去詢問。不知何故，透過自主掌控，他整天都能保持在心流專注狀態中。聽起來你說的也是同一回事，那種自動補全在某種程度上剝奪了我們的專注。
DHH： 完全沒錯。我當時確實有點擔心未來的方向就是那樣——我們所有人都將淪為那隻機械飲水鳥，而我不想成為那隻鳥。那時候我想：「那我該去幹嘛呢？也許去種馬鈴薯？在我們丹麥這裡有著悠久的種植馬鈴薯傳統，也許我可以去幹那個。」
但幸運的是，後來發生了兩件事。第一，Claude Code 大約是在春季開始萌芽，在整個夏季持續發展，然後到了秋天，在利用 Agent 協助寫程式的全新方式上取得了一定的進展——透過 Agent Harness，這正是我們真正從「單純的 AI」過渡到「Agent」的轉捩點。突然之間，AI 擁有了工具，它可以使用 Bash，它可以使用你在終端機上擁有的一切工具，它可以為了獲取適當的資訊而連上網際網路呼叫外部資源。它所能做的，遠遠超過了單純去推理事先餵給它的文字或來源上下文檔案。
第二件事則是模型本身。對我來說，Opus 4.5 是我們在時間線上必須標記的另一個重要里程碑。它是第一個持續且穩定地以其輸出品質震撼我的模型。它在面對模糊輸入時所展現的分析品質，更重要的是它的輸出品質——它所生成的程式碼，達到了我幾乎不需要進行任何修改、甚至完全不用改動就願意合併（Merge）的水準。如果我真的想做修改，我只要告訴它，它就能記住，下次就不會再犯同樣的錯誤。
對我來說，這兩者的結合就是終極的解鎖。
Gergely Orosz： 而且你的標準非常高，你有著極高的門檻。
DHH： 難以置信的高標準。正如我們剛才長篇探討過的，產出物的美學對我來說至關重要。如果要我看著它、要我審查它——我等一下會再講另一個完全不需要考慮這些美學的軼事——但當我使用 Agent 處理 Ruby 程式碼時，我希望它們寫出來的程式碼看起來和我自己寫的一樣優秀。如果程式碼寫得很草率，我是絕不可能合併的，就像我不可能去合併一個尚未完全內化我們程式碼風格規範的初階開發者的成果一樣。所以我希望它達到同等的水準與表現，而早期的模型根本做不到這一點。
這並不代表早期模型不能產出能運行的軟體，至少有時它們確實可以，那非常令人印象深刻。我的意思是，我還記得當我第一次用它做出一個貪食蛇遊戲時，我心想：「我的天啊，我從六歲起就一直想做這個，我有這個想法，我想把它做成遊戲。」而我在短短大約三十秒內就看到了成果，它搞定了遊戲，我複製貼上 HTML 就能玩了，那是極其神奇的體驗，對吧？
所以我覺得那段爬坡過程非常耐人尋味，因為我們實際上花了相當長的時間，才摸索出 Agent Harness 與終端機介面這種產品形態。對我來說，那是巨大的解鎖——從「這很有趣，我想跟它聊聊天」，徹底轉變成「我想讓它來寫我的程式碼，從現在起我啟動的任何專案，我都將採取 Agent 優先（Agent-First）的方式」。
這是一個翻天覆地的轉變，而它就發生在去年 11 月 27 日左右，我相信那是 Opus 4.5 發布的日子。現在可能其他人會有不同的時間節點感受，有人覺得是 Opus 4.0，或者有人會談到 Sonnet 3.7，確實還有其他更早的檢查點；但我確實感覺到有一種普遍的共識——就像 Andrej Karpathy 和其他人所表達的那樣——是的，轉折點就落在 11 月底到 12 月初這段時間。
對於在大型科技公司工作的所有人來說，那正好是寒假。因為整個行業基本上會停擺兩週，除了少數需要輪值 On-call 的崗位之外，整個行業完全沒有任何生產業務推進，大家都在擺弄這個新技術。我的感覺是，大家之所以玩它，是因為你把自己那些從來沒完成過的業餘小專案丟給它，心裡本來就預期它根本做不完；然後他們全都被徹底震撼了——你竟然完成了。
那完全就是一個劃時代的斷裂點，對吧？如果這是一部電影，你這時會聽到唱針刮過唱片的刺耳煞車聲，心想：「等等，倒帶！剛才到底發生了什麼事？」
我覺得這是發生在每個人身上的集體震撼。然後大家在今年一月份重返工作崗位，所有人——特別是很多平時不太親自動手寫代碼的決策者，像是 CTO、工程主管等——他們都親自下場動手實測了。他們回來後開始下達指令或要求：「好，大家現在必須使用這個，因為我看到了未來，我真的親自體驗過了，你們必須親眼看看。」
這有點像回到了硬體剛推出的時代，大家試圖把最新的硬體塞到別人手裡，說：「你必須親身體驗一下，因為光用聽的你絕對不會相信。」對於這項技術也是如此，你真的無法憑空相信。我們可以在這裡高談闊論，但任何還沒試過、或者還沒迎來那個「頓悟時刻（Aha moment）」的人，我認為我們很難單靠言語去說服他們。這是另一種「言語顯得蒼白無力」的典型情境。你必須親自坐在 OpenCode 或任何你使用的 Harness 前面，使用頂級的前沿模型——就從前沿模型開始，從 Opus 開始。我強烈建議從 Opus 開始，它是目前最好的前沿模型；雖然其他模型在某些方面可能有各自的優勢等等，但如果你純粹是要處理一段程式碼，想看看目前的技術極限在哪裡——如果你的聽眾裡居然還有人沒這麼做過，我會感到非常驚訝，但如果真的還有，現在就是時候了。
而且我甚至不想帶有那種情緒——我在 X 上看到那種「除非你已經內化了關於 AI 的一切，否則你就已經被時代拋下」的焦慮言論，我覺得極度反感。閉嘴好嗎！首先，這顯然不是事實。你完全可以在接下來的三週內搞懂所有東西。這是這類專案或技術進展的另一個神奇之處：如果我們是在去年春天進行這場對話，所有人都在喊「MCP、MCP、MCP！」而你知道嗎？你現在完全可以直接跳過那整套東西，直接走向 CLI（命令列介面）和技能體系（Skills）。
永遠要記住這一點：那種「除非你事無巨細、按部就班地跟上即時發生的一切，否則你就落伍了」的錯失恐懼（FOMO），純粹徹頭徹尾是一派胡言。
話雖如此，我依然非常欣賞那些走在時代前面的人。對我來說，Shopify 的 Tobi Lütke 是最核心的一位。他看到這一點、看到隨之而來的變革，比我早得多。他不斷寄東西給我，像是「嘿，你看這個，你看那個」，真的是他一路把我拽進了這個領域。我確實認為這非常有幫助。身邊圍繞著那些信念更強的人，或者說他們的目光放得更遠的人，是很有益的。像我的目光往往放得離路面相對很近，就盯著我正前方的路；而有些人的目光放得更高遠，有時他們看到的東西可能並不會成真，但在這件事上，Tobi 在兩年前就精準預見了我們現在的走向。而我終於在 12 月看到了，因為前方的道路終於延展到了我的眼前。
很有趣的是，在這一路上我一直都在說：「對，等到模型足夠好、等到它們能搞定所有這些事的時候，那將會無比驚豔。」但在當時我心想，這大概還要等上 18 個月、兩年，也許甚至是五年。預測這些反曲點（Inflection Points）極其困難，我認為整個行業本身甚至都沒能精準預測到這個反曲點。你看整個矽谷和舊金山周邊地區全都專注於實現這一目標，但要精準預測曲棍球棒曲線究竟在何時開始向上翹起，是非常困難的。
然而它就這樣發生了。而現在，我的日常工作已經完全不同了。
Gergely Orosz： 那麼，你現在的日常工作究竟是什麼樣子？
DHH： 我現在的日常工作，就是在所有事情上全面轉向「Agent 優先」（Agent-First）。
Gergely Orosz： 全面走向 Agent 優先，現在正好也是提一下我們本季贊助商 Sonar 的好時機。當轉向 Agent 優先的工作模式時，必然會浮現的一個核心問題就是程式碼的品質。SonarCube 的製造商 Sonar，深植於一個核心信念：程式碼品質與程式碼安全在本質上是密不可分的。高品質的程式碼天生具備更強的彈性與韌性；而隨著 Agent 開始進行大規模的程式碼編寫，這個驗證層便成為了你最關鍵的安全邊界。
這正是 SonarQube Advanced Security 等解決方案發揮價值的地方。透過全新的惡意套件偵測功能，Advanced Security 提供了即時的熔斷機制，能在 Agent 將未經審核或高風險的第三方函式庫引入你的流水線之前，自動進行攔截。其成效也是有目共睹的：根據 Sonar 2026 年程式碼現況開發者調查報告，使用 Sonar 驗證程式碼的開發者，回報因 AI 導致服務中斷事故的機率降低了 44%。這真正關乎於弭平 AI 的開發速度與生產環境安全現實之間的落差。想了解 Sonar 還採取了哪些措施來幫助減少服務中斷、提升安全性並降低與 AI 及 Agent 寫程式相關的風險，請造訪 sonarsource.com/pragmatic。
說到這裡，讓我們回到 David 的 Agent 優先工作流。具體來說，你使用的是 Claude Code 嗎？
DHH： 我使用的是 OpenCode。
Gergely Orosz： 你使用 OpenCode？
DHH： 那是我的主力 Harness（操作外框）。我也會用一點 Claude Code。Anthropic 很遺憾地搶先取得了早期的領先優勢，Opus 目前是最好的模型，所以他們開始有點以一種「這是一場單局對決而不是多輪博弈」的狹隘心態在思考，把他們的訂閱權限從 OpenCode 拔掉了。因此，如果你想使用你的 Mac 訂閱額度，你基本上必須使用他們的官方 Harness。我不太喜歡這樣，我認為這是一個錯誤；但先撇開這點不談，讓我們單純慶祝他們擁有最強大模型的事實。
Opus 4.5、4.6 都非常棒，但對我來說 4.5 才是那個決定性的反曲點。這當然引發了大量的競爭，因為每個人現在都想追趕上來並超越他們。特別是你看 Anthropic 的營收——我想在今年年初大概是 90 億美元，幾週後就到了 140 億美元，現在好像已經達到了 190 億美元之類的，這簡直是你所能想像最瘋狂的火箭級飛躍。這激勵了大量資本投入到競爭對手身上等等，這非常棒，很高興看到這種競爭。
因此，即便我不喜歡他們所有的做法，即便 Claude Code 不是我最偏好的 Harness，你得學會在腦海中同時容納兩件相互矛盾的事情。這也是我對待 Apple 的態度：我對他們的運作方式、他們作為守門人的行為以及我們討論過的所有荒唐事感到極為不滿；但同時我依然保持著「我就是單純熱愛電腦」的心態，心想：「我喜歡新的 Neo，我甚至可能會去買一台新的 Neo，看看這台只要 500 美元的設備到底能做些什麼。」
對於使用 Opus，我沒有任何心理負擔。事實上，每當我覺得「這是一個非常棘手的難題」時，我現在就會直接找 Opus。但我同時也會使用其他模型，我融入自身工作流程的一件事，就是同時運行兩個處於不同運算速度的模型。
我使用 Tmux，在 Omakub 系統裡內建了一套版面配置：它會在螢幕左側開啟我的 Neovim 編輯器，右側則分割為兩個窗格。上方是運行著 Kimi K2.5 的 OpenCode，下方則是在 Claude Code 中運行的 Opus；而在最底部，我保留了一條終端機長條列。
幾乎所有事情，我都是在其中一個 Agent 裡開頭，我告訴它們我想要什麼。接著我切換到 Neovim，首先按下 <Space> gg，透過 LazyGit 查看它所產生的變更 Diff。如果看起來正確，我就直接 Commit，完成了，太棒了！有時如果看起來不對，它會去修正，或者我會親自進去修改程式碼。
但是，這個比例以及比例轉變的速度，依然令人瞠目結舌。就在去年 11 月初，我還是「程式碼優先」（Code-First）的一分子——所有事情我都先在編輯器裡開始寫，花上不管多久的時間；只有在某個時刻當我卡住、或者我想尋求第二意見時，我才會去請求我那親切的「機器人夥伴」（Clanker）給我一個參考意見。
現在完全不是那樣了。現在我是以 Agent 為起點，它會給我一份草稿，我審查這份草稿，必要時進行修改。而就在最近，我把這套邏輯推得更遠了。
我們目前正在為 Basecamp 開發 CLI 工具，這樣我們就能為 Basecamp 取得完整的 Agent 存取能力。這真的太驚人了。
首先，讓我稍微倒帶一下。一旦我被「Agent 究竟有多厲害、有多能幹」深深震撼（AI-Pilled）之後，我立刻試著把目光投向道路的終點，心想：我們真的還需要 MCP 嗎？我們真的還需要 CLI 嗎？我們真的還需要任何這類中介嗎？Agent 難道不能自己搞定一切嗎？
這是我安裝 OpenClaw 的時候。我在虛擬機器（VM）上安裝了 OpenClaw，心想：「我在這裡該做些什麼呢？讓我們看看能把它的極限推到多遠，看看它能自己做到什麼程度。」我想著：我希望這個 Claw 進入 Basecamp，我希望這個 Claw 進入 Fizzy，讓我試試像對待真人一樣去邀請它。
所以我只是對它輸入：「你能不能去註冊 Fizzy？我不會給你任何專用工具，我不會給你任何 MCP，我不會給你 CLI，我只是告訴你網址是 fizzy.do，去註冊吧。」
接著你就看到它喀噠喀噠地自主運轉起來，然後回報：「是的，我正在註冊，但它要求提供電子郵件地址。」或者「我正在嘗試註冊，它需要一個電子郵件地址。」
我心想：「喔對，你需要一個電子郵件地址，Agent 自己沒有電子郵件地址。」於是我說：「嘿，去 hey.com 註冊一個吧。」
我當時心想：「它這關肯定會失敗。」結果它繼續喀噠、喀噠、喀噠地運算，接著說：「我已經註冊好 Hey.com 了，這是密碼，請把它記在安全的地方。我現在也已經註冊好 Fizzy 了，我在收件匣收到了確認信。我們一切準備就緒了，你想讓我做什麼？」
我整個人傻住：「你在跟我開玩笑嗎？你竟然能一次成功（One-shot），直接透過瀏覽器自主搞定這些產品的註冊？」
現在回頭看，也許這不應該讓人感到意外，也許在 Sonnet 3 或某個早期模型上這就已經可行了，我不知道；但當你在自己的機器上、在自己的 Claw 上親身體驗到這一切，你只是透過 Telegram 對它下達指令，而它就能完全自主地去註冊各種軟體產品，那真的令人無比震撼。至少對我來說是極其震撼的。
接著我的下一步就是：「好吧，既然它能註冊 Hey，又能註冊 Fizzy，那讓我把它邀請進 Basecamp 吧。」所以我把邀請連結發到了它自己的電子郵件地址：「這是 Basecamp 的邀請連結，你能不能直接進入我們內部的『AI Labs』專案，向團隊自我介紹一下？說一聲：『嘿，我是 David 的助理，很高興見到大家，我已經稍微閱讀了前面的討論紀錄，看到大家對這些事情感到非常興奮。』」
然後你又只能再次發出驚嘆：「什麼？！這怎麼做到的？！」
那真的非常有趣，因為它向我證明了：即便這過程需要一點時間——它確實花了一點時間，以 Agent 的標準來說，它花了大概七分鐘，感覺漫長得像過了一整個世紀——但它完全有能力做到這一點。
而這似乎正是未來的終極形態。終極形態是：Agent 根本不需要我們為它們做任何特殊適應或妥協，它們不需要任何專屬鋪設的無障礙坡道，它們不是坐著輪椅來的；它們是裝著生化機械腿來的，大約再過兩秒鐘，它們的奔跑速度就會是你的五倍——我們稍後會談到速度這個維度。
但緊接著你也會意識到：「好吧，我不能只是坐在這裡無所事事地轉大拇指乾等通用人工智慧（AGI）降臨，讓我們為當下而構建吧。」這正是我們為 Basecamp 打造 CLI 的原因。我們正在為 Basecamp 構建 CLI，我們也將為 Hey 構建 CLI，我們將為 Fizzy 構建 CLI，我們甚至可能會為一些舊款傳統產品都構建 CLI。
而我之所以如此喜愛 CLI，正如我也如此喜愛這些 Harness 一樣，是因為它們驗證了源自大約 1971 年根本的 Unix 哲學：你應該只構建小型、專注的工具，讓它們能夠透過管道（Pipes）相互協同運作。這正是 Unix 哲學的核心本質。
這對我來說正是看到萬物皆有 CLI 的神奇之處。這並不是說有了 CLI 之後 Basecamp 本身變得更好用了——不，完全不是；而是因為 GitHub 也有 CLI，Sentry 也有（我不知道 Sentry 有沒有 CLI，但他們有 MCP），你可以把所有這些東西串接在一起。
現在你可以對著一個 Agent 說：「嘿，我們在 Sentry 裡收到了一些錯誤回報，你能不能去查看一下？然後在 Basecamp 上發布一篇詳細分析說明問題出在哪裡；接著去 GitHub 提交一個 Pull Request；搞定之後，再回到 Basecamp 留個言回報。」
現在我們有了一個中央基地——也就是 Basecamp——在那裡我們可以在 Agent 執行工作、查找資訊的同時，即時追蹤整個工作的進展。
再說一次，當我們試圖談論它並轉述這些體驗時，我想有些人能夠理解；而且現在 OpenClaw 在 YouTube 上也有足夠的展示影片等等，所以你至少能以旁觀乘客的視角感受一下。但只有當你親自在自己的產品、自己的任務、自己的提示詞（Prompts）上親手實測時，你才會徹底被震撼（Pilled）。你將會同時感到難以置信的興奮——興奮於我們竟然能夠讓沙子、矽晶片、權重矩陣以及這整套體系做到如此地步；但同時你也會對這一切將走向何方感到些許焦慮。
正是在這種拉扯的張力之中，我和其他所有被這項技術震撼的人共同生活著，對吧？等等，如果我們現在就已經達到這種程度了，那麼 18 個月後會是什麼樣子？如果過去短短 3 個月就徹底顛覆了我對電腦能力的全部認知，那麼接下來的 3 個月會是什麼樣子？接下來的 9 個月又會是什麼樣子？
Gergely Orosz： 是的，這……這正是我……在很長一段時間裡，我其實是有點站在你這邊的，而且我想我現在依然是這樣——我相信真正能運作的東西，我對各種預測總是抱持懷疑。摩爾定律（Moore’s Law）在某個時刻失效了，我經歷過那個時代，當時每個人都說它會永遠持續下去，你知道的，然後它就像我們所有人懷疑的那樣失效了。但接著它又找到了另一條出路。
DHH： 我認為關於摩爾定律這是一個很好的觀點，對吧？它在單核心層面上失效了。
Gergely Orosz： 是的。
DHH： 你能把單核效能推到多高？然後大家就想：「好吧，如果直接放……AMD 最新的晶片是多少？10 奈米或 Zen 晶片上放 256 核呢？」對吧？
Gergely Orosz： 而且即使單純的性能增長受限，我們也轉向了功耗控制、晶片尺寸以及所有這些維度。所以，是的，但對我來說，現在也很難一口咬定說「它就只會停在這裡」，因為我們親眼目睹了它的成長。我們知道他們正在採取的路徑——越來越龐大的訓練資料集，而且到目前為止這條路一直有效。
還有「苦澀的教訓」（The Bitter Lesson）這篇論文，我認為這是一篇短小精悍但極度值得一讀的文章。我想它可能是學術圈外最受歡迎的論文之一了。
DHH： 沒錯。
Gergely Orosz： 因為它直接揭示了一件我們不願意相信的事實：我們總是希望相信我們自身的知識、我們的理解力是高人一等的；相信像你和我懂得如何寫程式碼，或者像我投入了 15 年甚至更長的時間，這些經驗是極其特別的。但有時候事實證明，它其實沒那麼特別。
DHH： 其實很有趣的是，就在此時此刻，在這個時間節點的快照下，它在某種程度上依然是特別的。
這正是目前正在發生的有趣分化：初階開發者與資深開發者。在 37signals，我所見過最成功、最能切實發揮 Agent 加速效果的，正是那些最資深的人。這些人具備驗證能力，能一眼看出 Agent 所產出的內容是否適合部署給數百萬用戶使用。
昨天剛好有一篇報導，談到 Amazon 發生的一些重大故障事故。Amazon 內部的事故分析基本上直指核心：我們再也不能允許初階程式設計師在未經審查的情況下，直接把 Agent 生成的程式碼發布到生產環境了。
而這個問題的核心在於：首先，我認為這是目前整個行業絕大多數公司正在達成的共識——每當面臨這類任務關鍵型（Mission-critical）的場景時，我們目前還根本無法完全依賴 Agent 自主搞定一切；而初階程式設計師又沒有能力分辨其中的問題。
因此，他們的地位突然之間比 6 到 9 個月前變得更加岌岌可危了。因為資深程式設計師可以做到這一點，而這正是資深程式設計師能夠獲得如此巨大加速的原因。他們首先能夠與大量 Agent 平行協同工作，但最關鍵的是，他們能夠嚴格審查 Agent 的輸出品質，並對「這段代碼到底能不能跑、會不會出事」抱有高度的把握；如果不行，他們能給予精準的修正指引。
因為這正是當初讓他們成為資深工程師的根本原因。這本來就是他們的職責：擁有宏觀的洞察力、深厚的歷史經驗，以及對整體架構的全景視野——這一切是如何組合在一起的？這個方案行得通嗎？那個方案行不通嗎？過去，他們是對著初階工程師扮演這個角色的；但現在，他們可以對著 Agent 扮演這個角色。
而 Agent 在遵循指令與接受修正方向上，反應速度要快得多。突然之間，你擁有了能夠將個人生產力提升 5 倍、甚至 10 倍的資深開發者。
現在，這就帶來了二階效應（Second-order effect）：如果你成功讓一位資深開發者的效率提升了 5 到 10 倍，那麼該開發者每小時的時間價值就暴增了 10 倍。現在，把那一個小時拿出來——與其讓這個人整天跟 Agent 待在一起不斷發布新功能、不斷把事情做得更好，不如讓他們像以前一樣，花那一個小時去教導一個人類初階工程師如何把事情做得更好？在目前的等式中，存在著某種正在劇烈博弈的東西，而且目前還完全不清楚未來會如何演變。
一種可能的走向是：Agent 會變得越來越優秀，直到它們徹底不再犯錯。它們自身在交付可用代碼的能力上，就直接達到了資深水準。如果我們把時間往後看個 X 年，這也是我會押注的方向。因為這正是剛剛在汽車自動駕駛上發生的事情：現在特斯拉的全自動駕駛在平均表現上已經開得比人類更好了——不是所有人類，也不是在所有極端情況下，但總體平均而言確實如此。
如果我們連這種每天都要面對的致命風險、這種坐在一個時速 60 英里的金屬管子裡與其他金屬管子並駕齊驅、一旦有人犯錯就可能喪命的最高危險性事務，都能放心委託給 Agent；那麼它們大概也能搞懂如何讓程式碼正常運作，對吧？
所以我確實認為這一天終將到來。但誰知道是什麼時候？誰知道會以何種形式？而現在我們所處的階段是：絕大部分的技術紅利，正完全累積在最資深的開發者身上。
Gergely Orosz： 而且我也在想，這是不是就像自動駕駛一樣——你會發現永遠都有邊界條件（Caveats）。例如在真正重要的大公司內部：當你是一家只有零個客戶的新創公司時，這無所謂，你可以直接一次生成（One-shot），就算跑不動崩潰了也沒人在乎。但在一系列大公司內部——比如在 Uber，我剛好拿到了一些關於他們內部如何導入 AI 的詳細資料。他們引進了所有這些工具，像是 Claude Code 等等。但我們也意識到，當你把它丟進去時，他們內部有一大堆龐大的 Monorepo（單一程式庫），有自己的工單系統、有內部 Slack，有海量的資訊，還有無數關於「如何做與為何做」的 RFC 設計文檔；他們擁有由微服務交織而成的一大堆混亂架構——這正好是很多很多年前我們最初聯繫上的有趣話題。
但他們發現的是：他們必須構建大量內部系統，其中很大一部分就是用來輔助餵給這些 Agent Harness。現在它們運作得更好了。但你知道，這正是我們目前所處的現狀。這也是為什麼如果你是這些公司裡的資深工程師，或者是 Uber 的 Staff 工程師，當你突然跳槽到 Google，你在一段時間內都不會那麼有價值或高效，直到你摸透了那裡所有的系統為止。
所以我很好奇，這是否與自動駕駛有著完全平行的對照？你看自動駕駛運作得也很棒，我在舊金山和洛杉磯時，Waymo 開得太舒適了。我的特斯拉在洛杉磯每次都能平穩地把我們全家載到機場，我整趟路程都能安詳地坐著看路，完全不需要握方向盤。好吧，除了有一次我的 Waymo 被卡住了，因為一輛卡車停在狹窄的街道上，旁邊還有一輛車帶著自行車架；我心裡清楚不該走那裡，但它不知道，所以人類遠端操作員介入了。但總之，即使是 Waymo，你知道的，它們也受到條件限制：它們在相當晴朗的天氣下行駛，路線都經過高精地圖預先繪製。
所以我好奇在軟體工程領域，這兩者是否有著驚人的平行相似性？每家公司都有自己獨特專屬的技術環境，一旦你繪製出地圖、補齊了所有周邊工具、搞清楚了所有脈絡——你看自動駕駛花了整整十年，對吧？當 Uber 收購自動駕駛業務時我正好在 Uber，當時我們在新聞裡聽到的都是「明年司機這個職業就要徹底終結了」。
DHH： 「以後再也不會有方向盤了！」對吧？順便說一句，這真是一個令人驚嘆的軼事，因為它恰恰展現了 Elon 對其使命的純粹信念。因為在 2017 年他發表那一宣言時，底層甚至根本還不是現代 AI，而是 50 萬行純手工編寫的 C++ 程式碼，對吧？那種架構模式是永遠、永遠不可能帶領我們走向真正的全自動駕駛的。但他對那個願景懷抱著絕對的信念。
然後最終，瞧，真正的現代 AI 出現了，它表現得如此出色。如果你拿數十億小時的道路行駛數據對它進行訓練，它真的能夠做到，而且能做得比大多數人類更好。
事實上，我自認是個相當不錯的駕駛，但我不敢說我是最好的司機。因為我不耐煩的個性往往會驅使我去踩油門，這對乘客來說並不總是像對我個人那麼充滿樂趣。而當我讓特斯拉 Autopilot 接手駕駛時，它簡直是世界上最棒的專職司機。它就是完美，比你開得好，比我開得好，我認為甚至比英國女王的專屬司機開得更好。它的油門控制與減速平順度簡直如同神蹟，在自動駕駛這個狹窄的領域內，它實際上已經達到了 AGI 或甚至是超級智慧（ASI）般的水準。
當然，當我們看到這些案例和令人驚嘆的例子時，天啊——自動駕駛並不是花了十年才達到現在的 AI 水平，距離當年的宣誓確實過了十年，但其中前七年他們所做的事情，與現在 FSD 所使用的技術根本毫無關聯，因為基於純 AI 端的 FSD 運行其實根本還沒有那麼久。
但那個關鍵的反曲點——我記得大概是 FSD 13.1 還是哪一版，那是第一個讓你驚呼「哇，這真的相當不錯，但我最好還是保持專注盯著路」的版本。接著到了 13.2、14.0、14.2，在短短 18 個月的時間裡，我們就從「嗯，滿不錯的，但我得專心盯著」，跨越到了「為什麼車上還需要裝方向盤？」
當人們審視程式設計時，自然也會聯想到那種在極短時間內爆發的加速度。大家會想：「如果我們現在處於這個階段，資深程式設計師依然必須審查程式碼，否則 AWS 就會因為某個 AI 亂推了一堆莫名其妙的東西而引發四級或八級的重大事故；那麼，當寫程式的技術像 FSD 在那段時期一樣實現跨越式飛躍時，世界又會變成什麼模樣？」
不過我也認為，如果整天坐在那裡、把所有的精力都耗在思考這些推演上，人是會徹底發瘋的。這也是我在過去一年裡試圖做到的平衡：我對它的未來走向感到無比興奮，但我也同樣著眼於今天能做什麼、今天什麼能帶來樂趣，以及我們現在手頭正在打造的東西。我不會試圖去規劃 12 個月後我的生活會是什麼樣子——到那時也許我們已經擁有了 AGI，也許還沒有。
現在有其他人非常擅長去思考那些宏大的問題。我剛看了 Leopold 去年接受 Dwarkesh 的專訪，他思考的是「2030 年會是什麼樣子？那座 10 Gigawatt 的資料中心會是什麼模樣？」我心想：我非常慶幸我們擁有願意對這些進行深入思考的人才，因為那並不是我最喜歡待的位置，而且我認為絕大多數人其实都不太擅長擦亮水晶球去預測未來。
Gergely Orosz： 是的。
DHH： 確實沒有人那麼擅長。
Gergely Orosz： 身為一名軟體工程師，這確實讓人感到有些不安，因為很明顯這正是整個行業渴望前進的方向，大量的精力將會投注於此，許多軟體業務將建立在此之上，順便說一句，許多以此為目標募集創投資金（VC）的公司也將全力攻堅，他們要麼成功，要麼陣亡，這就是這些公司的宿命。但是在今天，你在 37signals 的軟體工程師身上看到了什麼？你手下當然大多是經驗豐富的工程師，儘管你也招募過初階工程師。他們的工作方式正在發生怎樣的變化？他們對工作的滿意度發生了怎樣的變化？因為這也是一個關鍵議題，對吧？我們一直在爭論：這些東西是不是讓我們在工作中感到更加痛苦？這到底是不是我們想做的事？這對你個人的感受又帶來了什麼改變？
DHH： 對，我認為這其實是最大的頓悟——甚至比 Agent 展現出的能力本身還要震撼，那就是我指揮運作它們時所體會到的樂趣。
去年夏天我在 Lex 的節目上時，我當時說：「你知道嗎？我不想成為 Agent 的專案經理（PM）。」因為那時我腦海中的心智模型，是去當人類的專案經理。我心想：那不是我喜歡做的事，我不想離生產一線那麼遠，我想身處其中，我想親自動手寫程式碼。
而我當時沒有意識到的是：調度指揮一群 Agent，給人的感覺其實完全不像是在當管理人類的專案經理；它更像是直接跨進了一套「超級機甲戰鬥服」（Super Mech Suit）。突然之間，我不只有兩隻手臂，我擁有了 12 隻手臂！我可以同時盯著 7 個螢幕，操作 5 個鍵盤。我依然是那個真正親手在構建的人，哪怕我並沒有親手在程式裡敲下這個或那個關鍵字。身為一名程式設計師，我被極致超速加速了。這是一種不同型態的程式設計師，但它依然保有著對美學的強烈親和力——至少當我在編寫 Ruby 程式碼時是如此；而且我能將這種美學追求，與在海量事務上取得遠遠更高的生產力完美結合在一起。
這也像是在評估與排查問題時，獲得了難以置信的「大腦外掛升級」。我被徹底震撼（Pilling）的其中一個關鍵時刻，是在 Omakub 3.4 發布前夕。我打開 GitHub，發現我們積壓了大概 250 個待處理的 Pull Request（PR）。我當時稍微嘆了口氣，心想：250 個 PR，就算我每個 PR 只花 15 分鐘，我要花多久才能把它們全部看完？
然後我想：「你知道嗎？讓我試試別的辦法。我來試試讓 Claude 去做。」我甚至都還沒接入任何複雜系統，我只是給出「審查此 URL」，而那個 URL 就是該 Issue 或 PR。
結果讓我大為震驚。我想大概只花了 90 分鐘，我就處理完了 100 個 PR！這並不是說我把這 100 個全合併了——事實上，我只直接合併了極少數，大概只有 10% 是原樣合併。然後大概有 20% 的 PR 是這樣：那位提交的程式設計師確實精準找出了問題，但他自己手寫的代碼我一看就知道不想保留，或者有時我自己一眼看不出來，我直接問 Claude，Claude 會指出：「啊，這裡的寫法不太對勁。」接著我就對 Claude 說：「你能針對這個問題進行『無污染重新實作』（Clean room implementation）嗎？這確實是個該修的問題，我們把它修好，但我們要用正確的方式修。」它立刻就能搞定，而且風格完全契合我在 Omakub 其餘部分所寫的規範。
現在，這倒不是什麼高深莫測的極致代碼，大多只是一些 Bash 腳本；但 Bash 代碼依然有其講究的形態、有你期望它呈現的樣貌，以及它是否能與專案的其他部分保持融洽的一致性。在這個案例中，Agent（當時使用的是 Opus）每次都能精準切中要點。
剩下的另一半 PR，則分別是 25% 我看完後意識到「我單純就是不需要這個功能，我們不該納入它」；以及 25% 是 Claude 向我分析：「這裡面或許有點想法，但目前的實作方式真的很不妥，而且我們目前沒有直接把它做成優秀特性的簡單途徑。」
90 分鐘內搞定 100 個 Issue 和 PR！我往椅背上一靠，心想：這在以前起碼是一整週、甚至好幾天的工作量啊！這到底是什麼魔法？！
更厲害的是，Claude 在至少一半問題上所做的分析，涉及了我個人根本一無所知的底層細節。在那樣的時刻，它無可否認地成了一位比我所能奢望的更聰明、更優秀的 Reviewer 與程式設計師。好吧，不能說「奢望」，但我當時確實做不到那樣的水準。
Gergely Orosz： 如果沒有它，你根本不會投入那麼多精力。這本來就是那些 PR 最初被擱置的原因。在很多情況下，你看著它會覺得：「我覺得這裡面有點東西，但現在我得去研讀這個 Debug 工具的文件，我得弄清楚這是不是正確的搞法，我不想草率合併一個會引發其他問題的代碼。」能夠在 Agent 加速下完成這件事，絕對是你程式生涯中最頂級的 20 個高光時刻之一。
DHH： 我很喜歡你用「Agent 加速」這個詞。而且聽起來，它對於那些「卡在你身上、但你不想做、或者你沒那麼擅長做、但又極難委派出去」的工作特別有效。因為你有一個團隊，對吧？但你之前大概率沒有委派出去，因為你心裡知道委派給其他人也不會做得更快或更好。
所以我很好奇 AI 是否有這樣的一面：因為我們經常談論……你知道的，各家公司，特別是大公司，極度熱衷於衡量指標，像是效率、PR 數量，他們想看到具體成效；但你有沒有想過，它真正的衝擊在於「讓我們去執行那些以前根本不會去碰的工作」？
這對我來說才是真正的核心殺手鐧（Kicker）！事實上，整塊大餅目前正在爆炸性擴大，不是緩慢增長，是呈爆炸式膨脹！我們在內部著手解決的專案數量，那些如果在過去我們連動念去開始都不會考慮的專案，實在是多到數不清。
我們有過一個極佳的專案：通常在做效能最佳化時，大家關心的是 P50、P95、P99。而 Jeremy——我們公司使用 Agent 加速最極致的人之一——突然問道：「那 P1 呢？請求的最底層基線（The floor）呢？我們能不能修復這個基線？現在的基線是多少？」他查了一下說：「好吧，目前我們的基線延遲是……我忘了具體數字，假設是 4 毫秒好了。其實，如果你有大量快速請求，4 毫秒累積起來也是很可觀的，它依然至關重要。」
然後他就說：「我們要來做 P1，我們要優化 P1！字面意思就是，所有請求裡速度最快的那 1%，我們要讓它們變得更快。」
他把延遲從我記得的大約 4 毫秒，硬生生壓到了 0.5 毫秒以下！他把效能提升了整整十倍！我當時心想：換作以前，我絕不可能批准這種專案。而他把這個 P1 專案當成隨手小副業，幾天內就搞定了。因為他現在有能力這麼做！他之所以能做到，是因為他有一種直覺、有一種預感，覺得這裡面大有可為；他放手讓 Agent 跑起來，提交了一大堆 PR——「好，我們修了這個，我們修了那個」。
我想整個 P1 專案總計下來（我可能記不太準，但我記得大概是）12 個 PR，修復了各式各樣的地方。當我單獨看每一個 PR 時，我會覺得：「嗯，確實，可以，這改動很合理。」而當我看到最終總和時，你發現他改動了 2500 行程式碼！你會驚呼：「你在短短幾天內就搞定了這個？！」
Gergely Orosz： 太震撼了。我從沒聽過有人去優化 P1，因為這聽起來就像是純粹的面子工程，在商業邏輯上根本說不通。這不是真的沒價值，因為每一滴優化都能累積，但你懂我的意思，對吧？
DHH： 我完全懂你的意思！而這恰恰完美解釋了為什麼大餅的爆炸性擴張，會突然讓我們開始審視那些過去連想都不會想去探討的問題。
這很有趣，我想起《魔鬼終結者 2》裡的那個場景：他們找到了第一部電影裡終結者的殘留晶片，Miles Dyson 說：「這東西給了我們很多以前根本不會去調查的新點子。」這裡面有一種奇妙的平行呼應——也許我們正在打造終結者，這是老生常談的陳詞濫調了；但與此同時，我們正在獲得以前從未有過的點子與雄心，因為去探索一個直覺預感的成本，瞬間降低了一千倍！
我現在也隨時都在做這件事：我會給它一些非常模糊、隨便的粗糙指令，純粹是因為「我有這麼一個轉瞬即逝的念頭，我甚至都還沒把它具象化為一段整齊清晰的 Prompt，我只是想先看點東西」。它執行完後，我看了一眼心想：「喔，算了，刪掉。」也就是直接把代碼 Revert 還原回原本的狀態。
如果在以前，我會對那 75 行代碼寶貝得不得了，因為寫出那 75 行可能要耗費我兩個小時的時間。現在，這些東西完全沒有任何沈沒成本的包袱，我可以隨口說：「先給我看個草稿。」
我現在覺得自己有點像個國王，你可以隨意吩咐：「給我呈上遙遠邊疆地區的分析報告，我們的稅收進度如何了？」那位僕人就會說：「遵命，陛下，我這就去辦，三週後向您回報。」只不過現在，你只需隨手一揮，Agent 就能帶著那些針對愚蠢問題或糟糕點子的答案回來；然後突然間，你發現那其實不是個糟糕的點子，它實際上是個絕妙的主意！你會忍不住驚呼：「什麼？！」
我前陣子就經歷了這件事，我甚至到現在都還沒正式把這個功能發布出去。Omakub 自推出以來，大家一直敲碗要求的一項功能就是「雙重開機」（Dual Boot）——也就是能夠在 Windows 系統旁邊並行安裝 Linux，這樣大家依然能玩所有的遊戲。
我之前一直的態度都是：「你知道嗎？我有不只一台電腦，所以當我想玩遊戲時，我直接用 PC 玩就好了，這不是我個人的痛點。我完全理解為什麼有一大堆人想要它，但我實在沒什麼興趣花四個小時去研究如何實作。」
而就在不久前，我心想：「等等，這不正是最適合丟給 Agent 的那種問題嗎？我根本不需要自己去搞清楚，直接讓 Agent 去搞清楚就好了！」
於是我最初啟動了這個流程，只是先讓它們拿出一套方案。這其實是一個相當巨大的系統變更，對吧？如果你搞砸了某個人的開機引導記錄（Boot Records），或者覆蓋了對方的磁碟分割區，風險極高！這也是我之前不想碰它的原因之一。其次，如果你希望在 Linux 分割區上啟用 LUKS 加密，但 Linux 分割區又沒有獨占整個硬碟時，配置起來非常繁瑣棘手。我不想承擔這種關鍵風險。我想著：這太適合讓 Agent 來處理了。
所以一開始，基本上就是讓 Opus 和 Codex 在那裡來回打乒乓、研擬方案。我先讓 Opus：「針對這個需求設計一套實作方案。」它深度思考了好幾分鐘，提出了一套優秀的計畫；接著我把這份計畫丟給 Codex：「來挑剔、審查這份計畫的漏洞。」然後我讓它們兩個在後台來回爭辯修正了幾輪。
最後我看著那份計畫，心想：「沒錯，這是一套非常優秀的方案，我們絕對應該這麼做。」我迫不及待想正式啟動這個功能了，直接宣布：「好，現在 Omakub 支援雙開機了！」不是因為我親自手寫了它，而是——感謝你們這些無比給力的機器人夥伴（Clankers）！
Gergely Orosz： 那種層次的企圖心與雄心，對我來說至今都還沒完全內化消化。光是這一點——比如「嘿，這裡有這些靈光一閃的想法或外部需求、一些我想做但可能遙遙無期的專案」，而你現在可以在去吃午餐的時候順手把一個念頭啟動起來交給它，那真是一個全新的世界。
這也是我認為很多人在思考的另一個原因：好的，模型確實在持續進步；但即便我們假設明天突然撞上了一堵牆，苦澀的教訓（The Bitter Lesson）不再成立了，真的存在某種極限——比如 19 兆個 Token 就是它們能學習的上限了（這完全不是真的，但假設它是），而我們不得不被困在現有這些模型上——我們依然會在接下來的整整十年裡，僅僅透過學習如何使用這些工具，從現有模型中壓榨出越來越多的潛能。
你其實可以在復古老電腦上看到這種現象。比如在 Commodore 64 上，當它在 1981 到 1985 年左右推出時（我想那是它的主要黃金期，我知道它生產得更久，但後來 Amiga 和其他機器相繼問世），上面就有很多很棒的遊戲。我的意思是，我是從 Commodore 64 的《功夫》等遊戲開始對電玩產生興趣的。而 20 年後，當某些人徹底摸透了所有的秘密、榨乾了那顆 1 MHz 處理器的極限效能時，他們為那些古老機器所開發出來的遊戲……
DHH： 在技術上令人震撼得多！
Gergely Orosz： 因為我們對硬體的理解深入了太多！我的意思是，你看 PlayStation 也是同樣的道理：主機發售時的首發遊戲，與 PlayStation 2 推出前在初代 PS 上發表的末期遊戲相比，看起來簡直像是不同世代的主機。我們完全可以在現有模型上持續進行這樣的挖掘。但我們大概不會擁有那種慢慢調校的樂趣，因為每隔三個月就會有一款全新模型橫空出世。
但這非常有意思，因為如果我們順著這個思路推進——我們當然知道新的東西會不斷湧現，但重點在於：我們將花費大量的時間去學習它們、應用它們、構建我們的內部系統、改變我們打造軟體的方式、承接全新的專案。如果你身處一個現有的團隊中，既然大家現在能夠完成更多工作、承接更大膽的專案，你如何看待團隊承擔更多任務、推出更多產品？你是在考慮擴大團隊規模，還是保持現狀？
DHH： 對於我們目前編制最好的評估是：同樣的一批人可以做到多得多。讓我們好好內化這一點。
但這其實也已經足夠了。我們原本就做得夠多了，我們本來就擁有足夠的利潤空間，如果我們有足夠多的好點子，我們大可招募更多的人。因此，我們從團隊中獲得的所有這些額外生產力，讓我們現在能夠去執行像 P1 這樣的專案以及其他令人驚嘆的專案，這些專案理所當然會更快地改進產品。
以往那種「需要兩個月才能交付一個重大功能」的老舊思維方式，已經徹底被掃地出門了。這當然會帶來劇烈的加速，這種加速將一路滲透到我們的軟體工程方法論與流程中。比如 Shape Up 最初是建立在六週（兩個月）的週期循環之上，現在這套模式的邏輯已經完全不同了。我們目前還沒有完全重寫那套操作手冊，因為這股加速度實在是太快了。
Gergely Orosz： 實際上沒有任何一家公司已經完全重寫了所有操作手冊。當你發布的速度變得如此之快時，你需要一種機制來掌控上線的內容，並衡量它是否真正發揮了作用。
現在正好也是提及我們本集主力贊助商 Statsig 的好時機。Statsig 專為高速發布的團隊打造了實驗功能與 Feature Flag（功能旗標）。Statsig 構建了一個整合平台，能夠同時實現功能實驗與持續交付。內建的實驗功能意味著每一次發布都會自動轉化為一次學習機會，並提供嚴謹的統計分析，向你精確展示各項功能如何影響你的業務指標。Feature Flag 讓你能胸有成竹地持續部署，而且因為所有功能都整合在同一個平台上，並共享相同的產品數據，整個組織的團隊都能協同合作、做出數據驅動的決策。若想了解更多，請造訪 statsig.com/pragmatic。
說到這裡，讓我們回到即將衝擊開發者的這場劇變。
DHH： 但我依然認為，如果軟體開發者不認為一場重大變革即將到來，那他們就是在自欺欺人。
在過去，開發者是決定產出數量的絕對瓶頸，因此他們能夠享有流向「瓶頸資源」的超高薪資待遇。如果這些瓶頸突然鬆動了——特別是如果我們稍微把時間快轉一點，當產品經理自己實際上就能夠產出可以上線並正常運作的代碼變更時——事情將會發生翻天覆地的變化。
如果讓我下注，我確實認為我們已經見證了「程式設計師的頂峰」（Peak Programmer）——這裡指的是那種透過學校教育或花費無數小時磨練技術、以此為生的專業程式設計師工會群體。我們將不再需要同樣數量的人來完成相同數量的工作。
現在，傑文斯悖論（Jevons paradox）——即當某種東西的價格下降時，你會得到更多、或者會產生對其更大的需求——確實是成立的。但這並不意味著所有的程式設計師都能因此全身而退，即便未來生產的軟體總量肯定會比以往任何時候都要多。
順便說一句，我認為 GitHub 最近承受了大量的非難和抱怨，很大程度上是有道理的。我看到一張圖表說他們的正常運行時間只有 92%，這聽起來很瘋狂，我不太確定那究竟是衡量了什麼指標；但我能體會，我對此抱有一絲同情。雖然我也認為他們犯了一些錯誤，但另一個現實是：全球目前正在產出的軟體總量正處於一枚火箭般的噴發軌道上。我們作為全球人類文明，正在產出比以往任何時候都多得多的軟體。
我的意思是，OpenClaw 本身，我想……他說過那是 40 萬行代碼？那在以前通常需要 10 年時間、2000 個人才堆得出來。
Gergely Orosz： 嗯，可能沒有 2000 個人，但確實需要非常長的時間。
DHH： 需要極長的時間，對吧？你看 Shopify 的核心 Monolith，有 300 萬行程式碼，那是花了 20 年的時間；如果你把所有在那上面工作過的程式設計師全部累加起來，可能真的有兩萬人。
是的，重大轉折正在發生。現在有海量的軟體正在被製造出來，我完全能理解為什麼他們那邊的系統會有些不堪重負地嘎吱作響，因為 Push 推送的頻率只會進一步加速，對吧？而我們現在甚至連暴風雨的前奏都還沒完全看到。
如果你看看 AI 的普及曲線，基本上全世界根本還沒有什麼人在真正使用它。我們在 X 自己的小同溫層泡泡裡會覺得「天啊，每個人都在用」——不，他們根本沒有！世界上絕大多數公司根本就還沒這麼做。儘管 ChatGPT 非常迅速地突破了 8 億用戶，顯然存在著廣泛的採用，但那根本無法與那些走在最前端的公司所做的事情、以及他們藉此獲得的加速度相提並論。
因此，我確實認為一般的普通程式設計師有理由去思考：也許我們已經走過了最美好的黃金歲月。在薪資價格上肯定會面臨下行壓力。因為一類是像我們這樣的公司——我們在想出新功能和做更多事情上擁有近乎無限的探索空間，我們可以把所有這些額外的生產力全部投入到「做更多的事情」之中；但世界上還有大量其他公司，他們就只是單純需要把某件特定的事情搞定。如果他們能以十分之一的成本完成那件事，那本身就是他們的優勢，對吧？他們只需要做好那件事，它的範圍被極其清晰地界定好了。
那是一個成本中心（Cost Center）。在任何軟體開發被視為成本中心的地方——而這實際上可能佔據了全世界絕大多數的軟體開發工作——他們都將直接面臨這些壓力。
Gergely Orosz： 是的，聽起來如果我現在是一名軟體工程師，而且我擔心……你知道的，只是想確保自己處於一個未來會更好的位置，你會希望讓自己要麼脫離成本中心，要麼在成本中心裡變得極具價值。顯然，磨練你的技能是必須的。
而且我也在想，未來會被錄用的軟體工程師的「畫像」（The shape of software engineers）是否正在發生改變？因為如果我回顧 90 年代，對吧？即使你看當時的電影，你也能看到那些刻板印象：他們是不跟任何人說話的阿宅，但他們懂得如何寫程式碼、懂組合語言。接著到了 2000 年代，招募依然主要看你會哪種語言。隨著時間推移，我想在 2010 年代，新創公司開始不再針對特定語言進行招聘，而是純粹考核演算法，因為具體技術進去再學就好。
而現在，我看到很多公司——一些最新獲得創投支持的公司——都在招募「產品工程師」（Product Engineers）。他們實際上在尋找具備同理心、溝通能力的人才，而「懂得如何寫程式」反而變成了一種理所當然的基礎配備。所以我好奇，如果我只是看著這條曲線演變，對吧？你開始看到……而且我在所有這些公司遇到的開發者，他們人都非常親切友善，溝通能力極強，並且經常直接與客戶對話；對大多數人來說，這甚至根本不是一件苦差事，越來越多人真心熱愛這麼做。
DHH： 那正是現在受制約的「瓶頸價值」（The constraint value）所在。現在的瓶頸價值在於：想清楚我們應該打造什麼、應該如何構建它、我們應該與哪些客戶交談、我們的焦點應該放在哪裡。這就是產品管理。
這對我個人來說也很有諷刺意味，因為在歷史上，我對「產品管理」這個職能其實沒有抱持過多高的崇敬。我總覺得裡面充斥著大量廢話，我覺得有很多掛著這個職稱的人可能根本沒做什麼實事，對吧？
而其中一個原因正是他們「做不了」，因為當時受制約的稀缺資源是「具體實作」。產品經理好不容易想出他們要做某個東西、想要某個功能，接著他們必須苦苦等待四個星期，讓某些極其昂貴的程式設計師把那個想法變成現實。在那四個星期裡，我想他們大概只能跑去找幾個人聊聊天——他們處於產能未充分利用的狀態，他們並不是那個系統的瓶頸，對吧？瓶頸完全卡在實作端。
這種局面絕對、徹徹底底即將反轉！現在，純粹的實作在未來某個時刻必然會被徹底解決。
我現在並不是聲稱它「此時此刻」就已經被完全解決了——任何敢這麼吹噓的人，肯定都還沒試過把未經審查的雙足 Agent 代碼直接部署到大型核心程式庫中。但吸取了去年夏天在 Lex 節目上的教訓，我絕不會再把脖子伸出去賭咒說「這在明年夏天之前絕不可能發生」。
再次強調，這純粹是常識判斷。常識告訴我們，通用情境下的實作會先被解決；對於邊角極端案例（Edge cases），花費的時間會長得多；而對於某些特殊場景，完全交給 AI 也許根本沒有意義。就像我知道自動駕駛在這種一般尺寸的汽車上運作良好，但對於大型卡車可能需要更長時間，或者如果你有專門用途你就得特別調校。但核心在於：那些需要人工介入的空間將會急劇縮小。
是的，我確實認為那種「我只想安靜坐著純寫代碼」的刻板工程師形象，你必須達到約翰·卡馬克（John Carmack）那種神級水準，才能繼續享有「我只想坐著純寫代碼」的特權。
Gergely Orosz： 而且甚至連約翰·卡馬克本人現在也是個超級 AI 信徒，極度熱衷於此。
DHH： 完全沒錯！
Gergely Orosz： 而且他也洞察到了某些他能把握的趨勢——例如大家到底願意掏錢買什麼樣的遊戲，對吧？他必須具備某種商業技能，或者身邊圍繞著懂得商業的人。
DHH： 完全正確！完全正確！但重點是，你字面意義上必須成為那種最頂尖中的頂尖；而且不僅僅是業內頂尖，你還必須比 Agent 表現得更優秀，對吧？你想要獲得「僅僅做一名實作者」的特權，你產出的品質就必須擊敗 Agent 現成開箱即用的能力。
Gergely Orosz： 那麼，誰才是那些最優秀的人？你是一個非常適合回答這個問題的人。因為每當你們公司刊登職缺時——甚至早在 AI 出現很久之前，我記得你就同時刊登過軟體工程師和設計師的職缺。順便說一句，我很想採訪你們招募的那位設計師。因為你公開了薪水，那是舊金山水準的頂級薪資，你把確切的數字明明白白標了出來，大家都可以查驗。你在社群媒體上有著廣泛的影響力，所以消息傳播得極廣，你們收到了大量的履歷申請。而且據我所知，你們把招聘做得非常好，極力做到公平公正，投入了大量的心血。
那麼，想要在 37signals 被錄取到底需要具備什麼條件？因為你們現在試圖招募的是頂尖人才。基於這一點，對於那些心想「好吧，我想在這個新時代成為最優秀的一員」的人，你會給予什麼建議？
DHH： 這是一個極好無比的問題。沒有人真正搞懂了這個問題，我們自己也還沒能徹底參透解法。我說這話的立場，是一個經營過一家我們必定看過數以萬計應徵者履歷的組織主管（當然，如果你管的是 Google，你看過的人數肯定數以百萬計）。
但我們招募的候選人總數其實非常少。我的意思是，在 37signals 的整個生命週期中，在此工作過的程式設計師總人數能有多少？我不知道，頂多 100 到 150 人，我甚至都……
Gergely Orosz： 你們現在的團隊規模有多大？
DHH： 我們整家公司目前有 60 個人。而程式設計師大概是多少？大概 20 個人左右，是的，大概就這個數字。
Gergely Orosz： 哇，那剩下的 40 個人是做什麼的？
DHH： 我們有設計師，大概有 10 個人。
Gergely Orosz： 哇！
DHH： 然後我們有客戶支援團隊，目前有 14 個人。接著我們有一系列後勤支援職能：人力資源（HR）、財務；然後我們有運維團隊（Operations），我們的運維團隊相當龐大，有 10 個人專門管理我們所有的伺服器。是的，基本上就是這樣。
但我估計，在我看過的數萬名候選人中，我真正共事過或僱用過的程式設計師總共也就 100 人左右。
而且即使是這所有的錄用者，長期來看也並非全部都順利契合。實際上我最近剛回顧過這個數據：我們的成功率（Batting average）充其量也就是略高於五成，五五開。所以即使是那些錄用的人……
Gergely Orosz： 你們經歷了所有這些篩選，因為你們有一套非常漫長且詳盡的招募流程，你們投入了大量的精力，對吧？
DHH： 沒有人能夠找到一種效率高到完全不犯錯的招聘方法。Google 在很久以前發表過一篇非常著名的研究論文，他們嘗試了各種不同的假設：我們能否根據常春藤名校的教育背景、大學 GPA 成績或所有這些維度來預測員工的未來表現？最終的結論基本上是：我們對此一無所知。我們無法根據其中任何一項指標來預測，我們無法根據 LeetCode 刷題表現來預測，我們無法根據任何此類指標來進行預測。
我想說的是，我顯然被慣壞了，因為我一直與一些非常優秀的人共事——不僅是在我們公司，在整個開源社群也是如此。
Gergely Orosz： 是的，確實。
DHH： 因此，我有時會對「一般普通程式設計師具備怎樣的能力」產生某種扭曲失真的認知。當我們進行招聘輪次時，我很多時候——不能說「有時」，我的意思是每一次——我都對絕大多數申請者的水準之低感到震驚，驚訝於他們在展現自己的專業風貌上投入的努力竟然如此之少。
這聽起來很容易讓人覺得像個老古板戰後嬰兒潮世代（Boomer）在說教，但這純粹就是求職的客觀現實：你必須讓自己脫穎而出。
我完全理解那種感覺令人很不舒服，對吧？誰會想把這看作是「機率基本上都在跟我作對」？但真正掉進「從純粹機率視角來思考這件事」的陷阱，本身就是一種嚴重的誤判。
因為我一次又一次看著這種算錯帳的事情發生：大家會說「好吧，你看你們有一千個申請者，但只有一個人能拿到這份工作，或者兩個人拿到，所以錄取率只有 0.1% 的機會」。
不，根本不是那樣！照那種算算法，你根本就是 0% 的機會！是的，零！
而那些真正優秀的人，他們很可能擁有 10%、20%、30% 的機會。這不是均勻分佈的，這不是抽樂透彩票！我們絕不是隨便從桶子裡抓一張出來說：「喔，那就是這個人了，因為他們剛好是從這堆人裡抽出來的。」完全不是這樣！
我們在一開始就會直接刷掉至少一半的申請，也許高達三分之二，純粹是因為他們根本沒有針對職缺具體回應，他們完全沒有遵循我們在職缺說明中寫得非常直白清晰的文字指引，對吧？顯然他們根本不適合這份工作，或者我們聞到了其他不對勁的味道。
然後大概還剩下三分之一的人，這時我們才開始檢視具體的作品與提交內容。以往我們會將名單縮小到大約 20 個人左右的候選池，給他們一份帶回家做的實作測驗（Take-home test）。
這種在家測驗非常棒。有些人討厭它，他們覺得這是在白嫖免費勞動力。我心想：「你他媽在胡說八道些什麼？我才不會拿你提交的代碼測驗去用呢！我難道要把它部署到生產環境去嗎？你以為我們是怎麼設計出那個代碼測驗題目的？那是因為那項功能早已存在於系統之中了啊！」
我這話可能說得有點尖銳，我也很能理解並同情那種「如果這份測驗不會有任何下文，我不想白白投入六個小時去做」的沮喪心態。好吧，我完全理解。
但你根本沒有其他繞過去的捷徑！因為如果你腦海中存在著一種幻想：你只要隨手寄出一份履歷，某個人就會打電話給你，跟你進行一場 30 分鐘的隨意閒聊，然後說「先生，你被錄取了」——我不知道那種事情歷史上究竟有沒有存在過，但至少在今天絕對不存在，在我涉足這個行業的整個職業生涯中它從未存在過。
Gergely Orosz： 這種情況唯一存在的時刻，就只有透過非常熟絡的強力內部推薦（Warm referral），對吧？在那種情況下你直接跳過了整個漏斗流程。而當你跳過整個流程時，通常只會發生在一家公司剛起步、你正在創立一家公司的極早期階段；而且往往是雙向的——風險極高，然後你說：「這是我哥們，我跟他連續共事了整整兩年，我閉著眼睛都能信任他。」
DHH： 這正是整個招募過程中最讓人認清殘酷現實（Black-pilled）的一點：如果我們審視長期的成功率，我們在長期員工中，來自「我跟這個人共事過兩年，我們應該僱用他」的人數，遠遠多於公開招募的成果。
對於我們來說，要從公開招募中找到能夠在我們這種環境下蓬勃發展的程式設計師，實際上一直極其困難。它確實發生過，我們確實透過這種方式僱用過人，而我也願意繼續相信這種方式。儘管當你開始算這筆帳時，機率看起來漫長得不可思議——天啊，我們看過數以萬計的人，其中只有多少人被錄用，然後其中又有多少人最終未能長久留下來，天啊，從那條路走到最後竟然只剩下寥寥數人，這確實很讓人沮喪。
但直接基於你所說的「強力內推」來招募，一直以來效果都極好，那裡的成功命中率高得驚人。
但這對一般人又有什麼幫助呢？對吧？這聽起來並不是個非常具體可行的建議，除了一點：讓你自己變得盡可能優秀，投入盡可能多的努力，並與他人好好共事。
因為我想提出一個反向論點：有些人腦海中有一種觀念，覺得如果他們在一個自己認為很爛的地方工作，他們就不應該認真努力。老兄，你這是在搬起石頭砸自己的腳！
如果你身處在一個糟糕的工作場所——我們甚至可以在這一點上客觀達成完全共識，那就是個爛地方——而你卻抱持著「好吧，那我應該能混就混、我應該試著摸魚、我應該整天掛在 X 或 Reddit 上」的心態，跟你一起工作的每個人全都在看著你！
你知道那個強力內推未來會從哪裡來嗎？它會來自某個同樣在一份糟糕工作中與你共事過的人，但對方看在眼裡，發現你即便在那個環境下，依然每天準時出現，盡最大努力去學習、去交付成果、去做這所有的事情！
這裡根本沒有捷徑，你單純就是必須讓自己變強。而如果你不去練習，你永遠不可能變強。如果你認為你的僱主配不上你的最佳表現，你是在欺騙你自己！即便那是個糟糕的地方，如果你都不去幫助那個地方變得更好，一家只招募能進一步拉高標準人才的頂尖公司，為什麼要僱用你？
這完全是一種自我安慰（Cope）。這兩種心態都是自我安慰：一方面抱怨「我待在一個爛地方」，另一方面覺得「所以我不想投入」。你當然可以感到煩躁，我並不是叫你必須深愛你的老闆。事實上我想說，我以前為其工作過的大多數人，我對他們都沒有多麼溫暖的感情；但我依然為了我自己的教化、為了我自己的學習成長、為了維持「我是那種每天準時出現並把工作做好的人」的自我認同，而拼盡全力！純粹是為了當機會來敲門、當我所有的天賦都被需要且所有的技能都已磨練得無比鋒利時，我已經做好了萬全準備，對吧？
Gergely Orosz： 這不正是你當初加入 37signals 的經過嗎？當時只是一份約聘合約工作之類的，你知道在約聘工作中你沒有任何股權……
DHH： 沒錯！
Gergely Orosz： 但你全心全意做好了。
DHH： 沒錯，而 Jason 最終意識到：「好吧，我最好分給這個小毛頭一些股權，否則他就要另謀高就了。」
這是一段開創性的代表故事，你不能把所有事情都從中以偏概全。順便說一句，所有創辦人的故事在這方面都是開創性故事；但其底層的根本原則依然是一樣的：準時出現、盡你所能做到最好、學習更多。
在某種程度上，讓我有些懊惱的是——我也許在一段時間內無意間推波助瀾了這種現象——那就是有一種觀念認為：「你可以成為一名優秀的程式設計師，同時卻不用真正熱愛寫程式；你在工作時間之外完全不需要去在乎編程。」
Gergely Orosz： 這難道是你以前的想法嗎？
DHH： 好吧，我當時之所以會那樣表達，是一場誤會，因為我當時是在反擊那種過度加班、每週工作 100 小時或 120 小時的瘋狂痴迷病態文化。順便說一句，那從來都不是我的經歷。我們當初並不是那樣創立 Basecamp 的，在這 25 年裡，我們一直維持在滾動平均每週 40 小時的工作制。
但是，正如我在一開始所說的，我是真的非常喜歡電腦。所以我在空閒時間會擺弄電腦，我在空閒時間會研究與電腦相關的事物。那不是工作——並不是說我全天候 24/7 都在為 Basecamp 的客戶開發交付新功能，完全不是那回事；但我會玩電腦、我會關注新事物、我會探索新系統等等。
我認為在 2010 年代有一段時間存在著一種誤解：大家以為你完全不需要做這些事，你只要每天打卡上班、做完工作，你就會變得無比搶手，因為寫程式是一項極具價值的活動，而且懂寫程式的人少之又少，所以市場上飢不擇食，甚至連那些幾乎不在乎技術的人都照單全收。
我認為那個時代已經徹底結束了——如果它曾經真的存在過的話（而且我認為它確實存在過）。各種程式速成培訓班（Bootcamps）就是完美的催化劑，或者說就像礦坑裡的煤礦金絲雀。順便說一句，這也是經濟運行的正常規律：當薪資極高時，意味著勞動力供給不足，因此我們應該將更多勞動力引入這個人才庫中。
Gergely Orosz： 完全沒錯。
DHH： 所以我對此沒有任何微詞，我只是想說：那個時代已經結束了。
Gergely Orosz： 不，我也這麼認為。我們在討論「這是否是程式設計師的黃金時代？我們是否已經走過了程式設計師頂峰？」我在想，「程式設計師頂峰」是否真正意味著：在過去，幾乎任何想進入這個行業且願意付出幾個月或幾年努力的人都能做到——你可以學會寫程式碼、你可以去念大學或去參加培訓班，或者投入時間，然後你就能在某個地方被錄用，因為面試根本不需要背景調查、我們根本不去查證。
我想這大概即將走到盡頭了。你確實需要推薦人與口碑。我認為越來越多的公司會將深度背景推薦調查作為流程的一部分。而且不僅僅是問「你曾在這工作過嗎？」，我接過一些像 Databricks 這類公司的調查電話，他們在背調方面極其出名——他們不只查證推薦信，他們會打破沙鍋問到底：「你不僅僅是願不願意再次與此人共事？他們的具體缺點是什麼？你在什麼職位上會僱用他們？」等等。
不，我完全能理解。
DHH： 奇怪的是，「程式設計師頂峰」聽起來像是一個會衝擊到所有程式設計師的現象；但事實並非如此。
最優秀的程式設計師——這裡甚至不是指全世界僅有的 10 個頂尖神人——而是那些「真正優秀」的程式設計師，在當下實際上比以往任何時候都更加珍貴！因為他們正是能夠從 AI 加速中壓榨出最多價值的人。
這對我來說正是扭轉我全部觀點的殺手鐧所在：我還發現——也許這不是普世真理，但至少在 37signals 內部以及我個人的親身經歷中是如此——我現在身為一名程式設計師所享受到的工作樂趣，超過了自 2000 年代初剛發現 Ruby 以來的任何時期！
這完全帶給我一種「我剛剛發現了 Ruby」的激動興奮感！在這麼多層面上同時以如此驚人的速度推進，能夠去探索 P1 效能極限、能夠去思考為 Omakub 實現雙重開機、能夠搞定所有那些事情，這讓工作本身變得無比享受。
而且我在我們團隊裡那些走在最前端的 AI 擁抱者身上，也看到了同樣的現象。也許他們內心也有這些焦慮，但這些焦慮很大程度上都被與全新強大能力共事時的純粹享受給拋到了腦後。
因此，這裡存在著一種分化：我們大家理所當然都會覺得「我們不知道未來會發生什麼」，對某些人來說這會引發一定程度的焦慮。我完全能理解，特別是當這關乎你的生計，你想著「我也希望七年後能付得起我孩子的大学學費，到那時會是什麼模樣？」我懂。
但你根本不可能把那種焦慮轉化為任何富有成效的產出，除非你把這股能量全力投入到「躬身入局（Leaning in）」之中！對吧？因為如果你只是乾坐在那裡胡思亂想、試圖預測七年後的世界會變成什麼樣，你就是在浪費生命。
所以這是唯一的道路：唯一的道路就是讓自己對此感到興奮。正如我們所說，這甚至不需要花費那麼大的力氣——如果你親自坐下來面對這些模型，從你的衣櫥深處翻出一個你從未完成過的業餘愛好專案，然後親自試一試，我實在想不出任何一個真正熱愛電腦的人，怎麼可能不覺得這個實驗無比有趣。
Gergely Orosz： 我在那些投入其中的人身上也看到了這一點。Kent Beck 就是一個極好的典範：他當了 52 年的程式設計師，而他說他現在無比熱愛寫程式。他找到了使用 Agent 去構建他一直想做的雄心之作之間的平衡——他正在構建他的 Smalltalk 伺服器，那在以前需要花上地老天荒的時間，而現在它離目標越來越近了，雖然它依然需要不少時間。而在這期間，他在湖邊的小屋放鬆，就這麼走出去盯著小鳥看兩個小時，然後再回來繼續做，太美好了。
DHH： Kent 順便說一句是我歷來最崇拜的偶像之一。那是在我剛開始學編程的時候，就在我接觸 Ruby 之前，我於 2001 年在丹麥的一個技術大會上看到 Kent 在台上演講。我完全被他對技術材料的掌握程度、他的無畏氣魄以及他身為演講者的非凡魅力給深深迷住了。這還是在我讀了《極限編程》（Extreme Programming）和許多其他著作之後。
《Smalltalk 最佳實踐模式》（Smalltalk Best Practice Patterns）是我向任何想學習如何組織方法、如何設計類別以及所有底層細節的程式設計師強烈推薦的第一名書籍。那是 Kent 在 95 年還是 96 年出版的書，直到今天它依然是我有生以來最喜歡的戰術編程模式書籍。
所以聽到他也徹底被 Agent 震撼，同時還能在大自然中欣賞小鳥，真的太棒了。我的意思是，我也在努力這麼做。
其實現在存在著某種緊繃感：我發現大多數全力投入的人，他們工作得比以往任何時候都要賣力。我自己現在也體會到了這一點：當你花一個小時監督指導這些 Agent 就能產生如此巨大的成效與影響力時，那真的極度令人陶醉。如果你大腦裡有一個在代碼成功發布時會被觸發的多巴胺循環迴路，那個迴路現在基本上處於極度過載亢奮的狀態。
而我必須對自己說：「你知道嗎？這並不是像限時特賣那樣。AI 下個月依然會在這裡，再下個月也依然會在這裡。我不能搞得好像這是一場限時搶購、我必須在接下來的兩週內收割掉所有多巴胺一樣。」
我實際上認為，這正是目前那些走在最前面、最深度投入的人所面臨的主要挑戰：記住那句名言——「這已經是它們未來最爛的時刻了」，對吧？你最好想方設法不要讓自己被它完全吞噬，儘管它確實令人如此興奮。
Gergely Orosz： 是的，「被吞噬」真的是一個大問題。就像 Steve Yegge 一樣，他看起來比以前疲憊了不少，在影片裡你能看出來，但他很誠實，他說他深深被捲了進去，他正在瘋狂推進，他的朋友們也是。當你處於邊緣前沿時，你就在那裡。你顯然已經徹底被 AI 震撼了，但你是如何找到保持平衡的方法的？比如抽身離開。我知道你以前談過睡眠的重要性，顯然你連鬧鐘都不用？
DHH： 沒錯，我不用鬧鐘。雖然我妻子現在會用，因為孩子們需要按時去學校；但對我來說，每晚八小時的睡眠是你對自己大腦認知能力所能做的最好投資。
每次只要我沒睡滿八小時，我就會被強烈提醒：如果你把睡眠從八小時縮短到六小時，那是多麼糟糕的一筆交易！我會想：好吧，在這種情況下我會清醒 18 個小時，但為了透過削減睡眠多擠出那一兩個小時，我在接下來整整 18 個小時裡得承擔多麼沉重的精神拖累？這是一筆極其拙劣的數學帳，完全毫無道理。
有時這是不由自主的。在面對這波 AI 浪潮時，我確實經歷過幾次——非常罕見，我一隻手就能數得出來的次數——我失眠了，大腦轉速太快停不下來。這對我來說很不尋常，現在依然很不尋常，但我確實體會過幾次，對吧？
所以我能理解某些興奮感的來源，但我還是要說：你最不該拿來交易的就是睡眠，接著你絕不該拿你的健康去交換。你不該為了做更多的 Agent 工作，而試圖省下每週三小時的鍛鍊時間，那是一筆極其划不來的交易。
保持良好的身體狀態——如果你想讓上面的大腦保持敏銳，沒有什麼比讓系統的其他部分即使不在顛峰狀態、也至少維持在良好可持續的水準更重要了，對吧？
我確實認為現在有些人面臨著被活活累垮的危險，而這是一件我們將要長期面對的事情。放慢腳步，老兄！這再說一次，不是限時特賣。在未來的十年裡，我們會看到越來越多、情況會變得越來越瘋狂。所以千萬不要為了任何事情去揮霍你的健康、不要揮霍你的睡眠、不要揮霍你的飲食！因為即便從短期來看，那也完全行不通。你不可能在三週內透過每晚少睡兩三個小時來讓自己變得更高效，然後妄想三週後自己還能剩下任何清晰的邏輯思維——你會變成一團徹底的爛攤子。
Gergely Orosz： 那麼讓我們來做個收尾。我們聊了很多我們不知道的事、很多未知的領域；但讓我們以「你所確切知道的事」來結束。
你很久以前就可以選擇退休了，大可以躺平放鬆、去聽聽鳥叫。究竟是什麼驅使著你每天繼續做、繼續構建、每天早上起床？在 AI 出現之前，你會打開你的終端機，正如你分享過的，你會親自寫代碼；現在你則是指揮調度 Agent。究竟是什麼在驅動著你？展望未來，有哪些事情讓你感到興奮？
DHH： 我的動力始終來自於對電腦的熱愛。這純粹是我度過時間最好、最有趣的方式。
我可以把時間花在很多事情上，我也確實把時間花在很多事情上——我不只玩電腦，我開賽車、我花大量時間陪伴我的三個孩子，我們享受所有那些生活；但如果我每天要用一項活動填滿八個小時，我的首選永遠是電腦。從我字面意義上五歲開始，無論是玩電玩，還是現在感覺有點像電玩的調度所有這些 Agent——稍微玩一點像《星海爭霸》那樣調度部隊……
Gergely Orosz： 操控微操（Micro）！
DHH： 沒錯！所以我就是單純非常喜歡電腦。因此，無論我是出於經濟原因需要這麼做與否，我都將繼續玩電腦，探究它們的運作機制並親手創造東西。
我認為這是有些人對財富抱有的另一個巨大誤解：他們把財富設想為某種終點檢查站——一旦你達到了，你就可以在純粹的悠閒娛樂中躺平，彷彿那就是幸福一樣。我們擁有上百年的心理學研究明確告訴我們：不，那只會帶來痛苦與空虛！如果你擁有世界上所有的時間，卻沒有目標、沒有使命，休閒消遣根本無法填補內心，它不會成為一種充實的生活方式。
每一個賣掉公司的創業者身上都生動展現了這一點：他們在海灘上躺了三個星期，然後就又重新殺回賽場了，對吧？因為這實際上不僅僅是他們為了實現某個目標而採取的手段，這本身就是目標！它本身就是使命！這是一種滿足感，這是身為人類的一種自我肯定——我不是一團躺在路邊的廢肉，我是一個有用的人，我將自己的才能發揮到了極致。
所以我將繼續做下去。無論是我親自坐在鍵盤前打字、還是調度這些 Agent、無論是它們指導我還是怎樣，只要能玩電腦，我就會繼續玩下去。
更具體地說，在過去的三個月之後，我現在正全力投入於「讓軟體具備 Agent 可存取性」（Agent accessibility）。這是我過去幾週一直在做的事：我們一直在打造新的 CLI。這也讓我明白：我們現在確實還沒完全達到 AGI，對吧？你可能會想「只要叫 Agent 做個 CLI 就好了」，它確實會做，但還沒辦法達到完美，對吧？我希望它達到剛剛好的水準，而 Agent 依然需要一點人工協助，我非常樂意為這些 Agent 提供協助。
我們很快就會為 Basecamp 發布一款極其出色的 CLI——也許在節目播出時它就已經發布了——其餘產品也會跟進。我想要全力以赴擁抱這一切：我們如何盡可能多地利用它？
而且現在，我本質上也是個無比好奇的人。我每天早上醒來都有一個新的儀式：那就是不要在剛睜開眼時就掏出手機狂刷 X。我認為那樣做其實不好，但要忍住不這麼做需要巨大的意志力，因為我實在太好奇到底發生了什麼！現在每天都有太多事情在發生了，我想知道！我想去了解！我想樂在其中並成為其中的一部分！
所以我預見不到這一切會終結，我預見不到對電腦的熱愛會蒸發殆盡。事實上，如果說有什麼改變的話，那就是我現在看到了這份熱愛正在蓬勃綻放——我比五年前更加喜歡電腦了，這真的很神奇。
Gergely Orosz： 太棒了，David，這場對話太精彩了，非常非常感謝你！
DHH： 好的，謝謝你的邀請，這真的很棒。
Gergely Orosz（結尾評論）： 這是一場引人入勝的對話，我非常喜愛 David 所展現出的充沛能量。我希望他在面對面時散發出的這種感染力，也同樣傳遞給了身為聽眾的你。
我非常欣賞 David 的坦誠：他對 AI 的立場之所以改變，並不是因為他的根本哲學變了，而純粹是因為工具終於變得足夠優秀、能夠處理真正有用的工作了。
用於自動補全的 AI 對經驗豐富的開發者來說非常惱人；而另一方面，能夠獨立產出品質極佳、可用代碼的 AI Agent，現在則變得非常實用。
然而，David 一再回歸到品味、判斷力與工藝。他絕不是在提倡「就放手讓模型隨便胡亂寫代碼」——恰恰相反，他擁有極高的品質門檻，他要求產出必須是他真正感到自豪、願意合併的代碼。感覺 AI 反而可能讓「優秀的判斷力」比以往任何時候都更加珍貴。
我也非常喜歡 David 對於 37signals 設計重要性的思考。在 37signals，設計師負責弄清楚該打造什麼、該如何運作，並且越來越多地直接決定它該如何被實作。我在想，37signals 將設計師視為某種開發者、將開發者視為某種設計師的思維，是否已經領先了整個行業一步？
最後，我發現 David 認為「我們可能已經迎來了軟體工程師頂峰」的觀點非常耐人尋味。David 認為我們未來將產出比以往任何時候都多的軟體，但他的觀察是：工程師僅僅因為自己是生產瓶頸就能要求超高薪酬待遇的時代，可能即將畫上句點。
我個人的看法是：市場上對於那些能夠構建出「能獲利的軟體」的專業人士，肯定會保持高度的需求；但這將意味著軟體工程師不僅要擅長編寫代碼或使用 AI 生成代碼，更必須能夠監督構建複雜的系統，並同時兼具美學品味與商業敏銳度。
如果你想聽更多來自 David 的深入分享，請查看節目資訊中與他錄製的 Bonus 額外單集連結；也可以查看資訊欄，閱讀 Pragmatic Engineering 關於軟體工藝與實用構建軟體方式的深度專題文章。
如果你喜歡本集 Podcast，請務必在各大平台及 YouTube 上訂閱；如果你能在節目上留下五星好評，我們將不勝感激。感謝大家，我們下一集再見！