「有一段時間，我懂這麼多程式，反而是我的減分項。」
說這句話的是 David Heinemeier Hansson（下文簡稱DHH），Ruby on Rails 的創造者、37signals 技術長。過去 20 多年，「寫程式」對他來說就是一個字一個字雕琢漂亮的 Ruby 程式碼，他也因此成為手工程式碼最有名的信徒之一。而在 8 月下旬的《Lex Fridman Podcast》第 501 集裡，他說自己最近三個月改用英文寫程式，新版 Omarchy（他自己打造的 Linux 桌面作業系統）裡出貨的程式碼，沒有一行出自他的手。
難的不是承認 AI 會寫程式。難的是承認自己那套「怎麼做才對」的判斷，正在失效。
他把這場變化的起點定在一個確切的日期：2025 年 11 月 24 日，Claude Opus 4.5 發布。他兩天後才試用，丟了幾個任務，然後往椅背一靠，腦中只剩一個念頭：剛剛發生了什麼事？
在那之前，AI 對他只是自動補全或聊天機器人，他形容那只是多了個小幫手，工作方式沒有改變。Opus 4.5 之後，他說輸出品質「近得詭異」，接近他自己會寫的東西。到了今年春天出現 sub-agent（把一個任務拆給多個 AI 分身同時處理），原本要跑很久的工作縮短到五分之一甚至十分之一。
但這兩個階段他都還在駕駛座上。真正的斷點是今年夏天。Anthropic 的 Claude Fable 5 與 Opus 5、OpenAI 的 GPT-5.6 Sol，在 6 月到 7 月之間接連上線。他說從那時起，他不再告訴 AI 要去哪裡，只告訴它自己遇到的問題，路線由 AI 決定。用他的話說，他在「產出程式碼、選擇路徑」這件事上，已經變成非必要的一環。
他拿早期衛星導航打比方：剛問世時它比看地圖強，但你得盯著，怕它把你導進港口，當年報紙還真的在寫這種新聞。現在呢？車子已經自己在開了。
面對AI，為何寧可把話講得含糊？
回到開頭那句話。DHH 說在第一個階段，用 25 年的經驗指揮 AI 照自己的方法做，確實很有生產力，所以他也慢了一步才察覺下一個階段已經到了：改成描述問題、而不是規定路徑，拿到的解法反而比他自己開的路更好。
這不只是他個人的體感。打造 Claude Code 的 Boris Cherny 在今年 Y Combinator 的活動上提到，為了搭配 Opus 5，他們把原本的系統提示詞（給模型的預設指令）刪掉了八成，模型表現反而更好；他的說法是，當前的前沿模型正被那些為上一代較弱模型設計的產品綁住手腳。
換句話說，DHH 認為當前正解不是把指令寫得更精確，而是回到敏捷開發在 2000 年前後就講過的那句老話：沒有人知道自己要什麼，直到他真正得到它了。 所以他的建議是，一開始盡可能含糊地讓 AI 生出一個東西，然後去用它，你才會在使用的過程裡才會發現自己真正要的是什麼。
那人類還剩下什麼？他的答案是「差異評估」。給人三個選項，他一秒就能挑出喜歡的那個；但選項一多到 22 個，人反而會當機。這種近乎直覺的判斷，他認為就是所謂的品味。
他自己也知道下一句聽起來很像陳腔濫調，但還是說了：「如果有一種程式語言比 Ruby 更美，那就是英文。」而他對使用這種語言的建議是，不要像對機器人下指令那樣把話講死，適度的模糊反而能讓對面那個智慧體，交出你原本說不清楚的東西。
為什麼公司規模越大，未必越會長出好軟體？
主持人 Lex Fridman 問了一個好問題：如果 AI 這麼強，為什麼 Photoshop、Premiere 這些大家天天用的軟體，功能更新速度看起來完全沒有加快？
DHH 給了兩個理由。第一，只要是一群人一起做事，瓶頸很少落在實作，而是人的頻寬與溝通。產品經理、幾個設計師、上面的副總、再上面的技術長，每個人都想參與形塑，生產力就死在那裡。他說要拿到那種 10 倍甚至 100 倍的加速，你必須直接跟 AI 互動，中間不能再夾一個人，因為太慢了。
第二，多數組織根本不是卡在實作，是卡在點子、願景和品味。他拿微軟當例子，並說自己是刻意挑他們來講。幾十年來近乎無上限的工程產能說明的是，光有寫出大量程式碼的能力，並不會自動長出好軟體。
他自己公司的失敗實驗，是這段論證裡最有說服力的部分。今年 2 月，37signals 開發 Basecamp 5 時做過一個嘗試：既然設計師知道自己要什麼功能、要什麼樣子，那就讓他們直接去 vibe coding（把需求講給 AI、完全不看實作）。結果一堆 pull request（程式碼修改提案）個別看都還說得過去，加起來卻把系統架構弄壞了，最後得靠人力一行一行收拾回來。
他從中得到的結論是，要在已經有規模的既有程式碼庫上這樣做，你還是得是個程式設計師。至於那些成熟的大公司，他歸因於「創新者的兩難」，它們的管理層級與流程，是為一個已經不存在的時代調校的，「而超級油輪轉不了彎。」
漂亮程式碼還值不值錢？
DHH 澄清了一件事，他過去 25 年斤斤計較每一行程式碼，理由從來不是美學，是經濟。漂亮的程式碼好懂、簡單、好改，所以小團隊才能快速演進產品，改一個地方不會冒出一堆 bug。
問題是這個論證有個前提，就是「人類在做修改」。這個前提沒了之後，他認為現在唯一還站得住的理由是 token 還很貴。白話說，架構乾淨的系統能讓 AI 不必每次都重新理解整套程式，下一次改動才會跟這次一樣便宜。他也看過反例：第一個 pull request 品質中等，再往上疊幾個，整個系統就變成他口中的一團爛泥。
他用一個比喻收尾。假設把一位在 Commodore 64（1 MHz 處理器、64K 記憶體）上寫程式的人裝進時光機送到 2026 年，交給他一台現代電腦，他會有一陣子不知所措。他所有的技巧與直覺並沒有變錯，是過期了。他認為手寫程式碼會變成騎馬：仍然有人騎，也仍然美，只是不再是一門經濟活動。
他本人沒有太多感傷。「我做了 25 年，夠了。」他還補了一句挺有意思的觀察：他這輩子寫的程式碼幾乎都是公開的開源專案，所以那些程式碼進了訓練資料，現在有人會直接叫 AI「用 DHH 的風格寫」。
他已經不自己看 pull request 了
談到開源，他搬出宗教改革當比喻：程式設計師曾經是夾在一般人與電腦之間的祭司階級，而 AI 讓人可以直接接觸。
他手上有數字。Omarchy 第四版在 8 月 14 日推出（他自己叫它 Quattro），開發的這三個月合併了超過 1,000 個 pull request，外掛市集在三天內長出 330 個外掛，另外還有大約 400 個尚未處理的提案，一週內翻了一倍。他說很多貢獻者根本不是傳統的程式設計師，或者是其他領域的工程師，那些點子過去只會留在他們自己的腦袋裡。
他已經不逐一審查了，改由 AI 先篩掉重複、錯誤和沒價值的，只把「要不要合併」這個決定留給自己。對於「維護者被 AI 生成的提案淹沒」這種抱怨，他的反應相當不客氣：這是白送上門的貢獻，你可以不要，抱怨這個等於嫌牛排太多汁。 他甚至說他寧可收 AI 寫的提案，因為品質比較整齊，會寫測試、會說明為什麼要改；而且要拒絕的時候，不必顧慮任何人的感受。
Lex 追問，那誰來維持程式碼的水準？DHH 沒有迴避，他說當然需要有人把關，但他認為這件事在開源世界從來就是如此，並不是 AI 帶來的新問題。
程式設計師要失業了嗎？
面對「程式設計師怎麼辦」，DHH 先給了樂觀的一邊：傑文斯悖論指出，當一樣東西變便宜，需求反而會上升。他舉自動櫃員機為例，當年行員很怕被取代，結果 ATM 讓開一家分行的成本下降，銀行反而開了更多分行、請了更多行員。
但他沒有停在這裡。他接著提 1800 年代末的機械化收割，以及在英國砸毀織布機的盧德份子，並說那些人的恐懼是合理的，因為他們是技術純熟、待遇不錯的專業人士。然後他把話講得很直：生產力提升的字面意思，就是更少的人做同樣的事。對被裁掉的那個人是悲劇，對整體經濟卻是好事。
他給的建議分成兩種人。如果你愛的只是把邏輯正確組裝起來的那個機械過程，那部分正在消失；如果你愛的是把東西做出來，他認為需求只會更多。至於怎麼面對焦慮，他的說法是不要試圖預測兩個模型世代之後的世界，最聰明的人也做不到，硬要推演只會把自己逼瘋。
資料來源：《Lex Fridman Podcast》第 501 集逐字稿、Anthropic Claude Opus 4.5 公告、Anthropic Claude Fable 5 公告、OpenAI GPT-5.6 公告、《Phoronix》、Y Combinator Boris Cherny 訪談
本文初稿為AI編撰，整理．編輯/ 李先泰
