[情報] Kent Beck：AI 時代的軟體工程｜Features、Futures 與手藝

Kent Beck 把 Extreme Programming、JUnit、Agile Manifesto 這條線走過來，現在跟 frontier lab 一起做 augmented development。他說這仍是人的過程；至少到目前為止，Genie 做的決定，他還有很多要補。

一、Genie 擅長 plausible，不擅長 working

有人說現在 Genie 寫程式已經比人強。他直接說這是 balderdash。

句法正確、讀起來像那麼回事，跟「真的能跑、真的解決問題」是兩回事。他舉大家聽過的故事：砸一萬美元 token 做出「會動的 C compiler」，挖下去才發現只是 compiler-ish，並不能有效編譯出能跑的程式。

以前寫程式可以靠建構方式、靠把某類 bug 直接排掉，來推斷可信度。Genie 沒有這些招。你以前能假設的信任，現在不能再假設。

「業務用白話講需求、電腦自己算出來」這種幻想，他說跟 COBOL 當年的自我介紹差不多——這輪循環已經發生過很多次。

二、手藝還在，只是長相會變

他不喜歡有人把 craft 講成「時間不重要、一定要打磨到瑞士錶」。延遲成本高時，醜一點但能立刻拿到回饋的程式，剛好才是對的；軟體要活二十年，才值得慢慢磨。

在 AI 時代，手藝仍是一門學問，但表現方式會很不一樣。

三、Features 與 Futures

他這十八個月幾乎每天都在用 Genie 寫程式，野心變大很多，也常常撞牆：修一個 bug 就弄壞別的，於是 GitHub 上出現 project、project 2、project 3……

他畫了一張圖：橫軸是 Features（現在有的功能），縱軸是 Futures（接下來還能怎麼改的選擇空間，有時也叫 optionality）。

一開始選擇很多、功能為零。每加一個功能，通常要燒掉一些 futures。一路燒下去，程式變成一團，動哪裡都碎——以前要一百人十年才燒到零，現在他一個人一週就能在自己辦公室裡燒完。

他想走的是綠線那條：加完功能先喘口氣，把 futures 補回來一點，再加下一個。

四、在音符之間休息

他講了一則（自己也說可能是編的）Pablo Casals 故事：有人問連續十六分音符會不會累，Casals 說「我在音符之間休息」。

Genie 做完一個功能會問：要不要做下一個？這時你可以說「先等等」——重構、消重複、讓可讀性好一點，甚至整段丟掉重寫。專案的經濟價值＝現有 features ＋ 接下來的 futures。補 futures 也是在加價值，只是比較難被別人看見、也不會寫進 spec。

「切東西的時候擦不了刀」——要切一段、擦一段。想同時多加功能又多加選擇，連人和 Genie 合起來的腦袋都塞不下。

他試過 fully agentic、所謂 dark software factory（dark 指沒人、沒回饋，不是邪惡）。過程很炫、翻車也很精彩，結果幾乎總是一坨。他比較想最大化學習，軟體當副作用——想起早年跟 Ward Cunningham 一起，對方直接關機丟掉下午寫的東西，隔天十五分鐘重寫，反而清楚很多。

五、One-shot／spec-driven，很像瀑布

把 spec 寫好、丟給 Genie、產物夠好就算完——他說那就是 waterfall。Winston Royce 原論文的瀑布圖旁邊其實寫了「當然不行」，下一頁才有回饋往上的箭頭；大家卻只記得那張漂亮的單向圖。

小 app 用 one-shot 沒關係。他在做的圖資料庫虛擬機之類，就得部署有價值 → 改 → 更有價值，一路迭代。有很大使用者基數、要遷資料、要維持連續性時，從頭假設「會一直迭代」比較穩。

六、Formal methods 與 Lean

有人問 formal methods。他當過程式正確性證明課的助教，近年有朋友帶他玩 Lean（用來寫證明的定理證明器）搭配 Genie。

他的顧慮有兩塊：一是仍像 one-shot，規格一改，證明常要倒帶，拖慢「鼓勵改變」的系統；二是形式規格到真正跑起來的程式之間，還有一道他還不知道怎麼完全接上的縫。

例子、自動化測試、照顧測試、把設計想清楚，合在一起可以讓軟體比較可信。但 Genie 愛抄近路：回傳常數、鑽測試空子，活像十四歲小孩說「老闆，可以了」。跟人一起盯著，還是有機會寫出可信的程式。

七、Effort → Output → Outcome → Mission

工程師投入 Effort，交出 Output（例如新功能）。使用者行為因此改變，才叫 Outcome；Outcome 再推動共同的 Mission。

產出二十萬行 code 對 mission 幾乎無關，卻最好量。Genie 讓「很少努力、很多產出」變得誇張，於是大家又把 LOC、PR 數當生產力——這些量的是努力或產出，定義上就不是 mission。

越早在這條鏈上設 KPI，越容易踩到 Goodhart's law：指標變目標就不再是指標。他覺得 Goodhart 還太樂觀——人們會把整套系統扭歪，只為把數字弄好看，連 mission 進度都賠進去。

領導要把 mission 講進別人的腦子和心裡，然後重複、再重複，講第一千次還像第一次。哪天有人興奮地跟你講「他的」好主意，而那其實是你的想法、他完全沒想起你——他說那才叫領導成功。

工具有機會改變我們在世界上創造的價值；難題是找到這些工具真正服務的、為人服務的 mission。

※ 來源：YouTube／Rise8 · Kent Beck: Software Engineering in the Age of AI | Prodacity 2026 · 約 51:52 · 上傳 2026-09-29 · 非官方圖文整理