在上週六 #NETConf 最後, 有一場 “爐邊會談”, 幾位講師 (包括我) 在台上當場回答大家的問題

其中有一題我印象深刻, 同時我也補充一下當下沒有講到的觀點:

現今一堆各領域產品開發者推廣Vibe Coding，但大部分缺乏Code review能力，你們怎麼看這現象？謝謝😊

當下, 我的回答是:

我把 AI 也當作人來看待, 因為他有很多跟人相同的特性, 有幻覺, 會犯錯, 記憶力有限｡ 不過 ai 能力一直在進步, 平均能力跟速度都比人快, 就把他當作思考比你快 10x 的同事來看待｡

Vibe Coding 降低的是開發門檻, 我會把他對比成: 你把開發需求 “外包” 給 AI 了, 你用 “vibe coding” 的方式跟 ai 描述需求, 就是在外包｡ 你要外包你就要有能力驗收, 最基本的就是 code review… (當年我也 review 過人力外包的 code …)

我認為 code review 是確認品質的 “手段” 之一, 確認 “品質” 才是目標｡ 你不一定要 review 所有的 code, 但是你一定要有能力確保每個環節的品質是否如預期｡

談這題的當下, 我做了一個比喻:

如果藉由 vibe coding, 你的 coding 產能變成 5x, 你有能力 review 完 5x 的 code 嗎? 如果辦不到, 你該減少產能 (例如 3x 就好), 空出來的時間想辦法完成 3x code review .. 如果達不到這平衡, 你的產出就是不穩定的, 你就得找更有效率的確認品質方式｡

另一種常見的方式, 就是測試.

如果你能同時引用 AI 輔助 testing (如我寫過的 vibe testing 文章, 或是董大偉老師示範的 playwright mcp), 多了一層把關, 你的品質能多一層保障

如果你能分層設計, 例如我把 vibe testing 用在 api test 上, 你能從源頭 (測試左移) 確保品質, 越左移你能花越少的成本把關品質

如果能再往左移, 可以在程式碼生成的時候就同時生成 unit test, 一個需求產生了 50 個 function, 產生了 50000 行程式碼, 產生了 5000 行 unit test code, 如果你 review 完 5000 行 test code, 這些 test 就能幫你把關 50000 行的 code 的品質

如果再左移一點, 搭上 SDD, 你可以在確認規格的同時就產生測試｡ 你如果能在這階段就先 review 測試案例, 你可以花更少的精力就能保障更大範圍程式碼的品質

回頭想想, 這些並不是 “新” 技巧, 其實就是很普通的軟體工程概念而已, 軟體工程談的是用工程方式來避免人類常犯的錯誤, 我只是拿他來對應 “AI” 而已 (所以我都說我把 AI 當真人看待)｡ 而你能不能善用這些技巧, 看的是基礎工程能力, 而不是看你有多熟 AI …

– 本來要貼現場照片的 不過看到保哥貼給我的 AI 後製圖, 還挺好笑的 XDD 就拿這張替代吧 :D