Kent Beck：AI 時代工程師該具備的特質，TDD 精神不但沒過時反而更重要了

Kent Beck 這個名字，寫過測試的工程師應該都不陌生。TDD 的發明者、Extreme Programming 的推動者、JUnit 的共同作者。你可能會以為這樣一個「測試教父」等級的人物，面對 AI 輔助開發的浪潮，會站出來捍衛手寫測試的傳統。但事實剛好相反，他不但沒有抗拒，反而是最早開始擁抱 AI 工具的那批人

他最近在 Modern Software Engineering 頻道跟 Trisha Gee 有一場深度對談，聊的是 AI 時代工程師到底需要什麼技能。整場對談聽下來，有一個核心訊息反覆出現：你過去累積的那些「不會寫在履歷上」的能力，現在才是真正值錢的東西

而 TDD 所培養出來的思維模式，正好是這類能力中槓桿效應最大的一項

九成的操作技能過時了，但一成的判斷力價值翻倍

Kent Beck 在對談中很坦白地說，過去他引以為傲的事情，像是把 IDE 重構快捷鍵背得滾瓜爛熟、一天手動做上百次重構，這些在 AI 輔助開發的世界已經不值錢了

但他話鋒一轉：

知道「該做」重構這件事，比以前重要太多了

仔細想想，這個區分很重要。「怎麼做」跟「該不該做」是兩回事。AI 可以幫你秒速完成 extract method、rename variable 這類操作，但它沒辦法替你判斷「現在是該停下來整理程式碼，還是先往前衝完這個功能」

Kent Beck 把這種判斷力拆成幾個面向

• 時機感 (Timing)：什麼時候該暫停腳步做重構？什麼時候該先把功能趕出來？
• 品味 (Taste)：什麼是好的設計？這段程式碼「聞起來」哪裡不對勁？
• 長短期的拉鋸：眼前要加功能還是該先清理架構？
• 設計原則的引入時機：何時該把某個 pattern 拉進來用？

這裡有一個容易被忽略的重點：AI 把開發速度拉高之後，你面臨這類設計決策的頻率跟著暴增。以前可能一週碰到一次「要不要重構」的抉擇，現在一天會碰到好幾次。每一次判斷的對錯，影響也會更快地顯現出來

判斷力的槓桿效應，就這樣被放大了

用選擇權取代技術債的思考方式

聊到程式碼品質的時候，Kent Beck 丟出了一個我覺得很有意思的觀點：他偏好用「選擇權 (Optionality)」來取代「技術債 (Tech Debt)」這個比喻

為什麼？因為大部分人聽到「債」就覺得是壞事。主管聽到技術債，第一反應是「你們當初怎麼搞的」。但如果換個框架來看，事情就通順多了

Kent Beck 認為，開發工作其實同時在產出兩種價值：功能 (Features) 和選項 (Options)。功能大家都看得到，做了一個新頁面、加了一支 API，成果很具體，報告寫起來也好看。但選項是隱性的——「因為我把這層抽象做好了，下次要加類似功能的時間會少很多」，這個價值存在，只是不容易量化

AI 把整個開發的時間軸壓短之後，「要投資選項還是先交付功能」這個決策冒出來的頻率變高了，而且每一次的選擇造成的影響也會更快浮現。你投資了選項，可能隔天就享受到好處；你沒投資，可能隔天就撞牆

所以在跟團隊或主管溝通的時候，試著把「我們有一些技術債需要還」換成「我們需要投資一些選項，讓下一波功能開發更快」。聽起來差不多，但框架一換，對話的品質會很不一樣

自信是需要刻意練習的技能

Kent Beck 在對談中提到了一個讓他擔心的趨勢：就連那些已經在用 AI 工具而且用得不錯的資深工程師，也開始對自己產生懷疑

過去 Geek 文化裡的自信有個很紮實的來源：「我花了好幾年深入鑽研某個領域，所以我有信心，不管未來出什麼新技術，我都能搞定。」這種信心來自於你知道自己學習能力夠強，因為你有成功學過困難東西的經驗

但 AI 工具的出現動搖了這個根基。當你發現 AI 可以在幾秒內寫出你要花半小時才能寫好的程式碼，一種微妙的不安感就開始蔓延

Trisha Gee 自己也很誠實地分享了這個感受。她花了十年教人怎麼用 IDE 快捷鍵來提升開發效率，現在有時候會冒出一個念頭：「以後還需要 IDE 嗎？那我過去十年在做什麼？」

Kent Beck 的回應很直接：自信本身就是一種技能，需要刻意練習和維持

你的核心能力從來就不是那些快捷鍵，也不是你能背出多少 API 語法。而是你這些年累積下來的判斷力、品味、拆解問題的直覺、跟人協作的經驗。這些東西不會因為 AI 出現就消失，反而是 AI 時代最稀缺的資源

但你得主動提醒自己這件事，不能等著自信自動回來

TDD 的思維在 AI 時代反而內化成了開發的核心

這是整場對談中我覺得最精彩的部分。很多人以為 AI 會讓測試變得不重要，Kent Beck 的看法完全相反

測試的意識比手寫測試更關鍵

Kent Beck 分享了一個親身經歷。他有一系列叫「Genie Sessions」的 AI live coding 直播，就是開著直播用 AI 工具即時開發。開發的當下感覺很順暢，AI 給的程式碼品質也不錯。但事後回頭仔細一看，發現有大量程式碼沒有被測試覆蓋，很多邊界案例也漏掉了

這個經驗讓他意識到一件事：在 AI 時代，關鍵不在於你有沒有親手寫每一行測試。關鍵在於你腦中有沒有 「測試覆蓋率」這個概念，有沒有那個意識去主動審查測試的品質

他舉了一個具體的例子。你可以這樣跟 AI 說：

跑一次覆蓋率測試，然後幫我寫出那些「只有在未覆蓋的程式碼正確運作時才會通過」的測試

這個 prompt 聽起來有點繞口，但 Kent Beck 說效果出乎意料地好。而重點是：你得先知道 coverage testing 是什麼，才有辦法下這種指令。AI 不會主動幫你想到要做這件事

工具箱裡的每個工具，現在一天可以用好幾次

以前你可能一年才跑一次 mutation testing，一年才做一次 fuzz testing。這些技術不是不好用，而是設定和執行的成本太高，一般專案根本負擔不起那個時間

但 AI 改變了這個等式。這些工具的使用門檻大幅降低之後，你可以一天用上好多次

Kent Beck 在對談中把這個觀點講得很清楚：你腦中的每一項測試技巧——mutation testing、fuzz testing、coverage testing、property-based testing——它們的價值沒有因為 AI 而縮水。AI 把使用成本降低了，這些工具反而變得更實用

以前你知道 mutation testing 但因為成本太高所以很少用，等於知識躺在那邊生灰塵。現在你可以隨手就跑一輪，這些知識終於可以天天派上用場

真正的差異化優勢，是你知道這些工具存在，也知道什麼情境下該拿出哪一個

寫 Prompt 跟 TDD 根本是同一件事

Trisha Gee 在對談中提出了一個我覺得很精準的類比：跟 AI 互動的時候，你得把腦中的想法「寫出來」。這個動作本身就會逼你去釐清：「我到底要做什麼？我在找什麼？為什麼要這樣做？」

這不就是 TDD 的精神嗎？TDD 之所以有效，一個很核心的原因是它強迫你在動手寫實作之前，先用測試把意圖表達清楚。你寫下一個 expect(result).toBe(expected) 的時候，其實是在逼自己想清楚「我到底期望什麼結果」

寫 prompt 給 AI 是一模一樣的道理。你不能只說「幫我寫一個 function」，你得講清楚這個 function 要接收什麼、回傳什麼、邊界條件怎麼處理。表達得越精確，AI 的輸出品質越好

Kent Beck 還補充了一點：在 prompt 裡面陳述高層目標是一項值得培養的新技能。即使那個目標跟你現在要做的小任務沒有直接關係，把它寫出來有兩個效果。第一，幫助你自己記住大方向，不會做到一半忘了為什麼要做這件事。第二，AI 有時候會根據你的高層目標，主動推導出你還沒想到的子任務

小步驟的節奏依然適用

Trisha Gee 分享了一段自己的親身經歷。在學 TDD 之前，她常常寫程式寫到一半就迷路了——「等等，我現在到底在幹嘛？為什麼要這樣寫？」。TDD 的小步驟幫她解決了這個問題。每次只專注在一件小事上：寫一個測試、讓它通過、重構。這個節奏讓她不會偏離方向

跟 AI 協作的時候，小步驟一樣重要。只是形式變了。不再是手動的「紅、綠、重構」循環，而是變成更高頻率的 prompt → review → feedback 循環。你給 AI 一個明確的小任務，看它產出的結果，給回饋調整，然後進入下一輪

核心精神沒有變：每一步都小到你能掌控，每一步結束都回頭確認方向對不對

好奇心是被低估的高槓桿技能

Kent Beck 在對談中用了一個很傳神的比喻：AI 就像你身邊有一個無限耐心但偶爾有點醉的家教

「無限耐心」很好理解，你問一百次它都不會不耐煩。「偶爾有點醉」是提醒你，它給的答案不一定百分之百正確，你還是得自己判斷

他分享了一個有趣的故事。他在做 GPU Key-Value Store 的 live coding 時，從來沒有寫過 GPU 程式。功能做完之後，他突然好奇「這東西底層到底怎麼運作的？」就請 AI 用童話故事的形式來解釋 fetch 操作。結果 AI 真的寫了一個關於女王、城堡、信使和圖書館的故事，把整個記憶體存取的流程講得清清楚楚

Kent Beck 說他不是在建議大家用童話寫技術文件。他真正要強調的是：意識到你隨時可以這樣探索，這本身就是一種能力

想知道某個演算法的內部原理？問 AI。想了解某個框架為什麼用這種設計？問 AI。學習變成了情境式的，你在需要的那個當下學，而不是事先花兩天研究一個你可能用不到的東西

不過他也提醒了一件事。現在的工程文化太強調效率，一件事做完就急著衝下一件。但如果你能學會在任務跟任務的空隙中，利用 AI 去滿足自己的好奇心、去探索那些「不急但有趣」的問題，長期累積下來的回報會非常可觀

軟技能被嚴重低估，但 AI 時代讓它的槓桿加倍

Trisha Gee 在對談中戳中了一個業界的老問題：每個工程師的履歷都會寫「良好的溝通能力」，然後接下來三大段都在列技術技能。但光是「溝通」這兩個字就包含了一堆不同的面向，非同步文字溝通、面對面的口語表達、團隊內部溝通、向上管理、跟客戶溝通。大部分人可能擅長其中一兩種，但絕對不是全部

Kent Beck 從更根本的角度來看這件事。他認為開發者的核心角色，從來都是矽晶片跟終端使用者之間的橋樑。客戶說「我要一個大紅色按鈕可以跑報表」，你得把這句話轉化成一個使用者真正能用、而且會想用的東西

不管你是手寫 Java 還是寫 prompt 給 AI，這個橋樑角色完全沒有改變。而這也是為什麼「讓業務人員用自然語言寫程式」這個願景，過去幾十年來從來沒有真正成功過。翻譯需求、釐清模糊地帶、做出取捨，這些是工程判斷和溝通的問題，不是語言能力的問題

在 AI 時代，以下這些軟技能的槓桿效應會更明顯

• 向業務方提出釐清問題的能力：需求模糊就開工，AI 也只會幫你更快地做出一堆錯的東西
• 推回不合理需求的勇氣：速度加快不代表什麼都該做
• 優先排序的判斷：「我們什麼都做得到，但不可能同時做所有事」
• 說「不」的能力：然後清楚解釋為什麼
• 設定期望值：讓所有利害關係人知道接下來會發生什麼事

快速回饋循環：所有技能的使用頻率都在加速

Kent Beck 在整場對談中反覆提到一個核心觀察，我覺得這是理解所有其他論點的底層邏輯：AI 輔助開發的本質，就是把所有事情的時間軸壓縮了

以前你可能花一個月才準備好一個可以拿去收集使用者回饋的版本，現在可能每天就能產出一個。這個時間軸的壓縮，連帶影響了每一項技能的使用頻率

• 收集回饋的能力：從每月一次變成每天一次，你有更多機會練習，但也更容易暴露弱點
• 傾聽和消化回饋：回饋來得更密集，你得更快地吸收、整理、轉化成行動
• 切片的能力：面對一大堆需求，知道先做哪一塊能最快驗證假設
• 設定節奏：什麼時候該加速衝刺、什麼時候該慢下來消化，拿捏的難度也跟著上升

如果你已經具備這些能力，AI 會幫你把優勢放到最大。如果你還在摸索，其實現在正好是最適合練習的時候，因為你有更多的迭代機會

寫在最後

回頭看這整場對談，Kent Beck 跟 Trisha Gee 想說的事情其實很一致：AI 改變了我們寫程式的方式，但軟體開發的本質沒有變

你在 TDD、重構、測試策略裡面培養出來的思維方式，釐清意圖、小步快跑、持續驗證、維持程式碼品質，這些東西沒有過時。形式從「手動執行」變成了「指揮 AI 執行」，但使用頻率反而更高了

過去你用雙手來實踐這些技能，現在你用判斷力來驅動 AI 完成同樣的事

如果你已經在這些領域有所累積，AI 會幫你把過去的投資兌現得更快。如果你才剛起步，現在開始練習判斷力、品味、好奇心也不遲。AI 把迭代速度拉快了，犯錯的成本變低了，練習的機會也變多了

---

圖片來源：AI 產生