來發個舊聞…

vibe coding, where 2 engineers can now create the tech debt of at least 50 engineers —

前陣子看到這張圖之後, 開始看到各種討論, 討論 vibe coding 的品質會造成程式碼難以維護的問題, 也帶出 (糞? 氛?) code 產生速度太快，測試跟不上的問題..

多年思考架構設計問題, 讓我養成一個好習慣, 就是看到 “現象” 時我會先思考問題的 “源頭”，想通問題的成因後再來想解法。沒弄清源頭時，問題通常會解不乾淨。看到這邊不對勁，修補一下，下次就換別的地方故障… 這種 “兵來將擋、水來土淹” 的對應方式，大概也都無法根本解決問題。

那麼，這題的根源是什麼? 我分享一下我的看法:

源頭還是一樣, 在於程式碼的 “品質”。軟體工程很多技巧，或是架構設計的思維，都是導向一開始就把品質做好。包含修正 bug, 一開始就修正，跟產品上市後才修正，花費的成本是指數上升的。

那麼, vibe coding 怎樣才能一出手就生成夠好的品質? 勤勞的寫測試絕對不會是解方，因為測試，只是後面的一道防線而已。真正的關鍵，我還是會回到 SOLID 等等這些軟體工程原則。

如果你沒有能力 review 你手上的 code, 那麼你對品質也是沒有掌控能力的。SOLID 曾經是程式碼品質 (尤其是架構層面的設計品質) 的鐵律之一。他藉著一系列的原則，讓你能創造出 “好維護” 的程式碼。只要你還需要 review / maintain 這份程式碼，你就逃不掉顧好程式碼品質這件事，從一開始就預防技術債，是你的責任，不管你有沒有用 AI 都一樣。

各位可以反思一下:

當你在 vibe coding 時，你的 prompt 有把任一個 SOLID 的原則放到 需求內嗎? 一年前的臉書，我看過無數篇這類型的 “炫耀文”… 大概都是這樣:

我只花了 3 分鐘, Chat GPT 就幫我寫了一個 貪食蛇 | 踩地雷 | 俄羅斯方塊 | blah blah …, 實在太厲害了… —

這就是產生無法維護的程式碼典型範例。不是說這樣的 code 很差 (畢竟他會動)，但是這樣的 code 對於創造它的主人而言，是沒有辦法維護的。因為你完全沒要求 AI 啊，AI 只會用最省 token 的方式 (訓練資料怎麼寫他就怎麼產?) 你只會得到一個可以動，可能是對別人好維護，但是對你不是的 code。你需要的修正或擴充方式可能跟別人不一樣，而你完全沒把這部分需求描述清楚

(話說你知道怎麼描述嗎?)

因此，除了最終的畫面之外，完全沒有任何非功能性的要求敘述，你能期待他的 “品質” 嗎?

所以換個角度講，以我來說, 我會這樣做:

我會先在腦袋裡想像, 我想要什麼樣的品質的程式碼? 這程式碼我需要怎樣維護? 將來可能需要如何擴充? 調整? 以俄羅斯方塊來說，我可能會設想要能改變不同的遊戲速度，不同的遊戲規則，支援單打雙打模式，定義計分方式等等。

這些額外的要求，我能依據我的經驗，先設計出:

1. 幾個關鍵功能的 interface
2. 幾個關鍵資料的儲存結構 ( schema, entity, structure … )
3. ….

所以，我不會一次叫他寫完所有程式碼 (雖然這樣真的很爽)，我會 top down 的方式逐步展開，切成幾個步驟慢慢完成，過程中我會 review 每個階段都如我預期才會繼續往下。

先讓 AI 給我 class diagram, sequence diagram 等等，目的是讓我最方便能夠 review 的型態，我滿意了才產生 abstract class, interface, entity 等等 “空殼” 的程式碼。

到這邊我就會進行 code review 了，沒問題我在繼續往下長。

接著來談談測試，如果我真的要遵循 TDD, 先寫測試再寫程式, 那麼這步驟你就該開始叫 AI 按照 interface 幫你寫 unit test 了。同樣的，寫測試時我不會無腦的叫 AI 幫我把測試補完，我會叫他先列出我想要的測試目標，測試情境，我看過沒問題後才會讓他補完 code ..

測試告一段落後，接著就是逐步繼續長完程式碼，邊長的過程我會邊 run 測試，看看我長了一段程式碼之後，是不是對應的測試就從紅燈變綠燈? 有沒有其他綠燈變回紅燈了?

不斷的重複這步驟，直到我滿意為止…。

這樣的方式，你會發現有沒有用 AI 輔助，大流程都差不多。唯一差別是我不用一行一行的敲出 source code 了。我省了 coding 的過程，但是我沒有省掉設計架構與思考程式碼邏輯的部分。

用這方法，透過 vibe coding 得到的 source code, 我不覺得他會難維護，因為 AI 完全是照著我的想法設計出來的啊 (照我的想法怎麼可能會有問題 XDDD)，我只是擁有一個高度自動的 IDE 幫我寫 code, 而這些 code 我腦袋早有設計結構了, 我只是用上面的步驟，讓 AI 能乖乖地聽我的話，照我的意思幫我寫完。

( 對比一下，你完全不要求程式碼品質，只講 “幫我寫一個貪食蛇” 的差別 )

所以，會有技術債，問題在於你根本就沒把 “程式碼品質” 當作需求之一， AI 也會偷懶的，你沒有要求的東西，他也不會花 token 幫你思考的.. ( 這點跟真人一模一樣啊 )。

然而，沒有經驗的人，應該是講不出這樣的需求的，自然也給不了正確的 prompt … 沒有把程式碼品質當成你的目標之一，自然也寫不出好的程式碼…。

沒有 “程式碼品質” 這個前提，有技術債是理所當然的。用大量的測試案例，能改善嗎? 當然可以。這就像一棟危樓，不斷的搭鷹架，不斷的修補，一定能改善外牆磁磚剝落，漏水等等問題。但是你也別指望根治，除非重作結構的部分，否則今天補完東牆，明天西牆會繼續出問題。

其實這題能衍生出很多議題跟技巧的… 我先列一下摘要，我再分成幾天慢慢來寫..。我想繼續寫的主題在下方，而跟這篇相關，過去聊過的幾則 PO 文，我放在留言。

各位朋友有意見或想法，也歡迎留言跟我討論 :D

– 以後想繼續聊的主題:

1. AI 怎麼有效的做到 API 自動化測試?

上個月我在直播時挖掘了 LLM 進行 tool use 的步驟，既然 LLM 都能按照意圖呼叫 API 了，如果我的意圖就是對 API 做測試呢? 這想法冒出來之後，還真的被我試出來了，挺有意思的，改天整理好來聊聊這主題

1. vibe coding 可以省掉 “架構設計” 嗎?

有哪些 code 可以讓 AI 替你寫，有那些你一定要親自設計 (至少要讓 AI 寫好給你 review)? 各種重要的介面 ( interface, contract, schema 等等 ) ，尤其是這些規格會影響多個獨立系統時，你一定要控制好他。這跟 AI coding 無關，因為出問題時是多個系統的負責人要各自叫他的 AI 來改.. 只要有人的溝通，就有約定的問題 ( protocol, contract )

1. …. (懶得打了，以後再補 XDD)