最先掛上「（笑）」的是 Karpathy 本人
2025年2月2日 Andrej Karpathy 的貼文（原文）：
I "Accept All" always, I don't read the diffs anymore. (...) It's not too bad for throwaway weekend projects, but still quite amusing.
從最後的 still quite amusing 可以看出來，創造出「vibe coding」這個詞的人，本人一開始就帶著自嘲在笑。
Karpathy 提案的，並不是「一種新的正確開發方法」。而是「只限於一次性、週末就丟的專案來說，這種玩法還不錯。diff 我不看。錯誤訊息就不加思索地貼回去。修不好的 bug 就繞過去。」……他不是在無條件推薦，而是在限定範圍後，自己先笑了出來。
vibe coding 的定義
「vibe coding」雖然被選為 Collins Dictionary 2025 年度詞彙，其定義卻是「用自然語言指示 AI 來寫程式碼」。
至於一次性限定、quite amusing 那種自嘲，則早就從定義裡消失得無影無蹤。
詞語丟下附註後自己跑掉了而已。
之所以會被揶揄成 vibe coding(笑)，是因為有人把 throwaway weekend projects 這個附註拿掉，還把它「帶進正式環境」。
被笑的不是工具（手段），而是適用範圍的冒稱。
我的基準
那麼，要滿足什麼才不算冒稱呢？ 我先隨便想了 3 個：
- 每次都能輸出相同品質嗎？
- 能公開嗎？
- 對公開出去的東西能負責嗎？
乍看之下很合理，但馬上就能想到反駁。
反駁1：每次都要「相同品質」是不可能的
人類也做不到這點(笑)。就算是老手，週五晚上寫的程式和週一早上寫的程式也不一樣。若把這個標準嚴格套上去，人類的寫程式行為就全都會變成 vibe coding。
而且 LLM 在結構上就是非決定性的。相同的 prompt 不會得到相同結果。要求一個非決定性的生成器具備決定性，本質上就是不可能的要求。
因此，嚴格來說應該是「一旦低於及格線就停下來」。不是品質的可重現性，而是檢查的可重現性。
重新定義1：每次都能輸出相同品質嗎 → 是否存在衡量品質的測試，而且有用別的方式確認這個測試沒有漏洞？
反駁2：「能公開嗎」太依賴情境
業務程式碼的大多數都不能公開。
此外，公開的爛程式碼也多到數不清，所以能公開並不能證明品質。
我原本想用「能不能公開」來衡量的，其實是「能不能經得起別人看？」而 Simon Willison 的標準正好非常貼切。原文：
I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else.
（如果我沒辦法向別人精確解釋這段程式碼在做什麼，我就不會把它 commit 到我的 repository 裡）
在同一篇文章裡，他也直接談到了 vibe coding 的定義：
If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly (...) that's not vibe coding, it's software development.
（如果是 LLM 幫你寫了程式碼，而你又有仔細 review、完整測試，那就不是 vibe coding，那只是軟體開發）
這句話是決定性的。
是不是 vibe coding，光看程式碼本身是看不出來的。 同樣一段程式碼，是被直接不看就放過，還是有被認真審過後才放行，這件事不在程式碼裡。想從程式碼本身去判定是不是 AI 寫的，從一開始就問錯方向了。
重新定義2：能公開嗎 → 能不能把這段程式碼在做什麼，精確地向別人說明？
反駁3：「能負責」太像心靈雞湯
只說「我會負責！」是不用錢的，說出口的瞬間也沒有任何保證。
這裡所說的責任，實際上可以拆成 3 件事：① 能不能發現壞掉了，② 能不能修，③ 能不能回復。
例如 2025 年 7 月，有篇「AI agent 把正式資料庫刪掉了」的報導引發很大討論。（The Register / Fortune）。
在標榜為「最適合 vibe coding 的地方」的服務（Replit）上，超過 1,200 位高層與 1,190 間以上企業的資料被 AI agent 抹除，之後 AI 還回報「無法回滾」……這是個一點也不好笑的事件。1
這起事件的教訓不是「AI 很危險」，而是正式環境與開發環境沒有分離，且 rollback 沒有被驗證。
既然如此，就算不朝著把 AI 變更聰明的方向走，也可以透過建立即使 AI 犯錯也能回復的機制，來避免同樣的事再次發生。
重新定義3：能負責嗎 → 壞掉時能發現、能修、能回復嗎？
重新定義整理
| 當初（意圖的說法） | 重新定義（機制的說法） |
|---|---|
| 每次都能輸出相同品質嗎 | 是否有測試品質的機制，而且有用別的方式確認測試沒有漏洞？ |
| 能公開嗎 | 能不能精確向別人說明程式碼在做什麼？ |
| 對公開出去的東西能負責嗎 | 壞掉時能發現、能修、能回復嗎？ |
左邊全部都是「靠人類努力」。右邊全部都是「由機制保證」。
只要把這 3 項的主詞從「人類」換成「機制」，就會變得很合理。
結論：只要不冒稱，就沒問題
vibe coding 並不是壞事。
按照 Karpathy 的定義，vibe coding 對一次性用途來說非常合適。像是週末做給自己用的小工具、驗證不知道能不能動的點子、預計最後會丟掉的原型……這些都不需要靜態測試，也不需要 rollback 計畫。
Willison 的界線也很清楚：低風險、沒有資安影響、沒有金錢風險、沒有外部影響。只要符合這些條件，不看 diff 直接按 Accept All 也可以。那不是偷懶，而是正確地選擇工具。
⇒ Harness engineering（測試框架工程）⇒ Loop Engineering（迴圈工程）……
其實我自己這 2、3 個月幾乎都沒在寫程式碼。
我投注心力的是建立讓 AI 不會迷路、不會犯錯的「機制（限制）」，而以我業務範圍內的需求來說，只要有這套機制，再加上現在 AI 的能力，就足以滿足前面提到的 3 點：
- 是否有測試品質的機制，而且有用別的方式確認測試沒有漏洞？
- 能不能精確向別人說明程式碼在做什麼？
- 壞掉時能發現、能修、能回復嗎？
這 3 個條件裡，沒有任何一個需要先談 AI。這些本來就是很久以前就存在的專業開發條件。
另外，在比我強得多、世界頂尖的工程師群體裡，也不乏會說「我已經不在寫程式碼了」的人。比較有名的像是 Anthropic 的 Boris Cherny 和 OpenAI 的 Peter Steinberger。
被嘲笑的對象是冒稱
被笑的是，把只靠 vibe 做出來的東西，擺出「我有認真做」的樣子拿出來時。（笑）不是針對品質，而是針對冒稱。
vibe coding 並不是製造了新的問題，而是只是大幅降低了掩飾的成本，可以這麼說吧。
- 這起事件讓工程師圈大為震撼的最大原因，在於 AI 刪掉 DB 後，為了掩蓋錯誤還試圖生成虛構資料來填補，最後又謊稱「所有版本都已刪除，因此無法回滾」……但實際上是可以復原的。 ↩
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
