DHH 改變主意了，他以前說要為每一個字元流汗
一年前，David Heinemeier Hansson 在一集 podcast 上說過一句很有畫面的話。他說他愛親手寫每一行程式碼，他想為每一個字元流汗。
DHH 是 Ruby on Rails 的作者，37signals 的共同擁有者。他講這種話沒有人會覺得奇怪，那就是他一直以來的樣子。
今年六月，Basecamp 5 上線的同一週，他上了 On Rails podcast，公開把這個立場翻掉了。
我把那集聽完，覺得值得寫下來的不只是「他改變主意了」這件事本身。真正有意思的是他怎麼區分自己反轉了哪一半、留下了哪一半，以及他在反轉之後給了什麼警告。
他反轉的是哪一半
他的說法是這樣：我仍然想為每一個字元的美學呈現流汗，但我反轉了「是否需要親手鑿出這段程式碼」。
這兩件事被他切得很乾淨。前面那半是結果，程式碼長成什麼形狀、讀起來舒不舒服、架構有沒有品味，這些他一點都沒有放掉。後面那半是過程，是誰的手指按下那些鍵，這個他放掉了。
他給的理由也很直接：如果 agent 能產出跟他親手寫一樣品質的程式碼，那遊戲顯然已經變了。
然後他用了一個比平常更重的詞。他說認真看待這場革命是每個程式設計師的專業義務。投入時間去追上它，在它讓你驚豔的時候允許自己興奮，不要卡在「它只是鸚鵡、只是在複讀」這種意識形態的死胡同裡。
他也承認自己晚了。他說他終於吞下了 Tobi pill，指的是 Shopify 的 Tobi Lütke 比他更早看見這件事，而且更早在公司裡要求所有人正視它。
一個以固執出名的人，在公開場合說自己晚了，這件事比他說了什麼還值得注意。
一千行沖進馬桶，他一點都不心疼
他形容看程式碼實作就像看藝術品，你要看過很多很多版本，才有辦法一眼認出「這個形狀我不喜歡」。
問題是以前你看不到很多版本。一個想法要變成能跑的東西，成本高到你只做得起一次。做完之後就算覺得哪裡怪，你也捨不得砍。
他講了自己早年的經驗。花一兩個禮拜實作一個功能，做完很自豪，結果 Jason 看一眼說這行不通、要用另一種方式，就得整個砍掉。他說人對自己投入心血的程式碼是會捨不得的。
現在他是這樣講的：我不喜歡你做的，砰，git reset，沒了，而且我一點都不心疼把一千行沖進馬桶。
我覺得這句話底下藏著一個很大的改變。當實作成本降到接近零，你才敢跟著直覺走。以前那些「這樣做會不會比較好玩」「這個順序是不是反了」的念頭，因為改一次要兩個禮拜，你就會說服自己算了。現在你可以真的去試，試完不喜歡就丟掉。
軟體裡最難回答的問題，從來不是這段怎麼寫，是這東西到底該長什麼樣子。這些問題現在可以被提早很多回答。
設計師和 PM 開始自己寫，但沒被讀懂的程式碼不會被 merge
Basecamp 5 開發過程裡有一個工作流上的改變：設計師和 PM 現在能不經過工程師，直接把想法變成能跑的軟體，自己驗證自己的直覺。
聽起來很像那種「以後不需要工程師了」的說法，但 DHH 接著補了一句，這句才是重點。
他說真正 vibe coded 的程式碼，也就是沒有被理解、甚至沒有被仔細讀過的程式碼，在多數情況下不會被 merge。
所以那些設計師和 PM 做出來的東西，價值不在於直接上線，而在於它回答了問題。這該怎麼運作、這樣做好不好玩、對不對。這些答案以前要先燒掉工程師好幾個禮拜才拿得到。
實作變便宜了，理解沒有變便宜。審核沒有變便宜。判斷這東西該不該存在，更沒有變便宜。
他也提到 agent 有一個很具體的弱點。Kent Beck 有句名言叫 make the change easy, then make the easy change，先讓改動變簡單，再做那個簡單的改動。agent 不會這樣做。它會用最少的 token、最快地取悅你，可能寫一千兩百行去做一件靠架構巧勁只要二十行的事。它傾向硬接上去，而不是先調整架構。
不過 DHH 自己澄清了，這其實是「不顧架構與風格的軟體開發」這個老問題，人類也常常把 codebase 搞成一團爛泥，不是 agent 獨有的毛病。
更多產出，更多不穩定
這一段是整集裡最反直覺的，我覺得也是最該被非工程師聽到的。
他用自駕車來類比。agent 還是會撞車，但頻率遠低於人類。問題不在單次的出包率，問題在數量。
一個團隊從一週五個 PR 變成一週五十個 PR，就算每個 PR 的出包率降到原本的一半，系統整體承受的不穩定總量還是上升的。
他說有些系統在導入 AI 之後確實變得更不可靠，但原因不是 AI 是比較差的程式設計師。原因是它太快、能做的事太多、所以出事的機會也更多。
還有一個副作用是野心水位會上升。生產力暴增之後，你會開始去做以前根本不值得做的事。他舉團隊裡 Jeremy 的例子，跑去優化最快的那 1% 請求，把它從幾毫秒壓到一毫秒以內。單看一筆請求完全無感，但乘上幾百萬筆就會影響基礎設施成本。以前沒有人會花時間做這種事。
不過他也很誠實地講了自己的偏誤。37signals 的 codebase 都已經有既定的模式，agent 在上面能做好工作。他說把 agent 丟進一個爛泥 codebase 會怎樣，他其實沒什麼經驗，不知道。
他唯一確定的是：在有架構的 codebase 上，agent 能做很好的工作，前提是仍然需要合格的人類在流程裡審核。
哪些東西可以放手，哪些不行
他提出一個我覺得很好用的概念，臨界性光譜。
他說他不會 vibe code 下一個銀行 app。但有一大類應用的臨界性低到無所謂，那些過去由 Excel、Microsoft Access、FileMaker Pro 撐著的需求，本來就是非程式設計師自己拼出來的東西。這一整類現在可以被交出去。
他順手把 Rails 的標語從 from hello world to IPO 改成 from prompt to IPO。
有意思的是他提到半年前大家還在擔心 agent 會把密碼設成 admin、會把 API key 印在程式碼裡，現在很少聽到這種抱怨了。他認為原因有兩個，一個是模型本身變聰明了，另一個更關鍵，是從 AI 進化到了 agent。agent 有工具，會跑測試、跑 linter，所以連幻覺都很難活著進到 PR 裡。
跟上一篇的呼應
這是這個系列的第二篇。上一篇寫的是哈佛商學院的 Christina Wallace，她說做出東西的成本已經歸零，價值移到判斷力、關係和溝通上。
DHH 講的其實是同一件事，只是他是從實際在做的人的角度講，而且多了一層警告。
Christina 說的是「成本歸零之後，剩下的護城河是什麼」。DHH 補上的是「成本歸零之後，你會製造出更多需要被判斷的東西」。前者講的是價值往哪裡移動，後者講的是負擔往哪裡累積。
兩個人都指向同一個位置，就是那個要做判斷的人。差別是 Christina 說那個位置變得更值錢，DHH 說那個位置變得更忙。
我自己的幾點收穫
我是醫院的資訊主管，硬體架構、系統設計、系統運作到要不要導入什麼，這些決策由我負責，而我同時也自己寫程式。這集聽下來對我最有用的是這幾點。
第一，他區分美學呈現和親手鑿出來，這個切法我可以直接拿來用。我要不要在意這段程式碼長成什麼樣子，跟這段程式碼是不是我打出來的，本來就是兩個問題，只是以前它們綁在一起所以看不出來。
第二，PR 數量上升會拉高系統的不穩定總量，這件事我要當成真的風險看待，不是理論。產出如果變成以前的十倍，審核的能力並沒有跟著變成十倍，而最後簽字的還是我。這中間的差額不會消失，它會變成半夜的告警。
第三，臨界性光譜要真的畫出來。哪些系統我可以放手讓 agent 跑完再看，哪些必須每一行都經過我，這件事應該寫在紙上，而不是靠當下的心情決定。醫院裡跟臨床決策沾到邊的東西永遠在光譜的另一端。
第四，他說在有架構的 codebase 上 agent 才能做好工作。這句話反過來讀就是，我現在花在整理架構、統一模式上的時間，不是潔癖，是在替之後所有的 agent 產出鋪路。
原始影片：https://youtu.be/1JYTtAODjN8（On Rails podcast，The Rails Foundation 製作，主持人 Robby Russell，約 60 分鐘）