Hunger DX Podcast：Uncle Bob 談 AI 時代的程式開發

資料來源：Hunger DX podcast，〈Uncle Bob: Why I Stopped Reading Code and Building Harnesses〉
https://www.youtube.com/watch?v=5kCISBJwoZo

節目背景：Hunger DX 是 Aviator 共同創辦人主持的開發者體驗 podcast，來賓 Robert C. Martin（Uncle Bob），1964 年 12 歲開始寫程式，《Clean Code》作者。整集圍繞一個核心問題：當 agent 寫掉大部分程式碼，人類該站在哪個層次？

1. Uncle Bob 現在怎麼工作

不用 IDE，幾乎不看程式碼，主要工具是終端機裡的 agent CLI（目前用 Grok，也用過 Codex、Claude）。
他做的事：告訴 agent 要什麼、怎麼達成、用什麼工具、套什麼約束與門檻，然後盯著它跑，盡量只看它產出的架構，不往下鑽到程式碼。
核心假設：人類處理程式碼太慢了。要跟上 agent 的速度，人必須退後一步，守住高層監督；程式碼層級已經不屬於人的領域。

2. 他為什麼改變立場

兩年前他公開說 AI 不是程式開發的未來；一年前試過，覺得 agent 做事很蠢。
轉折點在今年 1 月左右：agent 開始「做得更好——不是很棒，但更好」，之後幾乎每個月都在進步。
他過去兩三個月陷在一個「坑」裡：努力建一套約束來把模型框住。現在發現模型已經長到不需要那些框了。

3. 三大約束（仍在用，只是放寬執行強度）

約束	作用	現況
單元測試	像複式簿記，agent 必須「把事情說兩次」；他多次看到 agent 弄壞測試後自己退回來改方向	沒有單元測試 agent 就會「跑進仙境」
CRAP 指標（2007 年提出）	結合測試覆蓋率與循環複雜度，複雜又沒測的函式分數會暴衝	門檻從 4 → 6 → 現在覺得 12 也行
變異測試	覆蓋率只證明「被執行」，變異測試證明「真的被測到」；要求 agent 殺掉存活的變異體	有些殺不掉、有些不該殺，但大致都要殺

4. 怎麼讓測試對齊「意圖」而不是只求通過

主持人提出：agent 若誤解任務，會寫出一套自洽但錯誤的測試。Bob 的兩個答案：

人是最終仲裁者：緊密迴圈，agent 改完他就跑系統、實際操作，不喜歡就要求改。agent 看不到畫面、不像人那樣互動，很多人因工程的細節會被忽略，必須靠人補。
Gherkin，但要由人撰寫：他讓 agent 建了 Gherkin 的解析與執行工具，形成第二套「由人撰寫或至少審閱」的測試。但他踩過大坑——曾讓 agent 自己寫、自己測 Gherkin，結果發現人離 Gherkin 越遠，Gherkin 就越怪，最後變成近乎無意義的系統描述。agent 寫的是「看起來像人話的 agent 語言」，讀的時候會點頭，但其實不通。目前立場（他自嘲下週可能又變）：Gherkin 必須由人全部撰寫。

5. 為什麼放寬複雜度門檻——程式碼現在是寫給 agent 讀的

原本堅持 4 的原因是人類短期記憶有限，只能同時處理五到七件事。
agent 沒有這個限制，能同時操作幾十個事實。
他放寬的量尺是：看 agent 會不會被搞混——弄壞測試、弄壞別的東西，跟人被任務飽和時的表現一樣。
主持人點出推論：這等於宣告程式碼只給 agent 讀、不給人讀；某些人讀不懂的複雜度是可接受的。Bob 同意。

6. Code review 與軟體團隊的未來

他現在 95% 的程式碼從沒看過，偶爾開個小視窗看某個模組。
他的大膽猜想：一個人現在能做一個團隊的工作，所以對團隊的依賴會劇變——不再是五六個人緊密溝通，而是各自獨立、產出大得多的元件，只在很窄的介面邊界上溝通。協作量下降，功能量上升。（他自己也說可能完全相反。）
主持人不同意：他在紐約談 code review 時的重點是建立心智模型與知識分享，權衡取捨與設計決策仍需要團隊協作，而且那正是不寫程式碼之後最有趣的部分。

7. 動態 UML 工具（Bob 現場展示）

把專案拆成 UML 式的圖，工具與 agent 互相連動，可展開、收合、下鑽到程式碼、再拉回來。
圖上直接標紅：CRAP 太高、變異分數太低、方向錯誤的相依關係（紅箭頭）。
可玩「what if」：告訴 agent「我不喜歡這樣排，換個分層」，agent 產出一個提案結構，滿意再讓它變成真的程式碼。
觀點反轉：UML 以前是寫碼之前的靜態產物，現在是寫碼之後的動態檢視工具，用來檢查 agent 做了什麼、收拾它造的孽。
兩人都認為這可能成為新的 review 與協作介面：在圖上圈出「這裡好、這裡壞」，讓 agent 重排。軟體工程師真正在意的——切分是否恰當、把高變動與高穩定的部分解耦——在這種圖上看得到。

8. 團隊需要什麼紀律

第一件事是一套大家同意遵守的規則，除非開會決定才能破例：單元測試、把覆蓋率推高、CRAP 低於門檻、變異測試達標，並驗證確實做到。
大型企業系統可加上 Gherkin，或在 GUI 迴圈裡加人工審查。
要避免的是vibe coder：靠 prompt 弄出「看起來能動」的東西，卻不確定它真的能動。

9. Harness engineering 被高估了

他過去幾個月建了一套嚴格的 harness：規格 agent、編碼 agent、審查 agent、架構 agent 排成流水線互相交接；大量時間花在防止它們彼此「洩漏」資訊——一旦洩漏，所有 agent 最後都變成同一個 agent。
看板上卡片在泳道間移動，他十天前還很得意。然後驚覺效率低得要命。
關鍵破綻：他從來沒用 harness 來建 harness，全程都是直接驅動單一 agent，而且那個 agent 越來越強。
轉折時刻：和 Grok 做了 45 分鐘深度討論，agent 會反駁他的提案、說明為什麼不行、再提反方案，像在跟資深工程師對談。既然願意給單一 agent 這麼高的信任，為什麼要把它關進一個把它當「低階奴工」的 harness？——「我腦中的模型錯了。」
主持人補充：Steve Yegge 的 Gas Town 也正要收掉。
「軟體工廠會不會完蛋？」Bob：他已經不知道什麼是軟體工廠或 harness 了。現在的模型是一個人 + 一個 agent + 一個視覺化工具，就能有信心說「這可以上 production」。

10. 指數曲線與物理極限

他從 1960 年代就活在摩爾定律的指數曲線上，驅動力是電子元件不斷縮小，極限是原子與光速。
AI 的指數曲線靠的是電力與土地不斷增長，物理限制嚴峻得多，他不知道能撐多久（笑稱所以馬斯克要上軌道）。
主持人反問：到達均衡後是否會轉向優化、重新「縮小」？Bob：我們腦袋裡就有實例——兩磅、20 瓦。

11. 責任歸屬

agent 完全不負責任，只有人能負責，未來幾年都是如此。
開發者要用自己的技能與經驗檢視 agent 的產出，然後簽核，承擔所有後果。
但他要在程式碼之上一層負責：UML、Gherkin、CRAP、覆蓋率、變異測試，確保系統可部署且合理。審查程式碼本身 (a) 已經不太有用 (b) 嚴重拖慢速度。「語法交給 agent，其他一切我們仍握在手裡。」

12. Clean Code 第二版

第二版是在他轉向 AI 之前剛寫完的，內容大致同第一版、多了很多範例。
他認為所有基本原則仍然成立：乾淨的切分、好的相依關係、好的命名、妥善的註解。改變的只是門檻與邊界，這正是他目前在探索的。
確保這些規則被正確套用，是人類開發者的責任。
結尾：人類從來也不完美，agent 只要跟人一樣好就夠了——Bob 覺得以平均水準來看，agent 可能已經更好；若指數曲線延續，「agent 終將打敗棋王」。