Vibe Coding 的臨界性光譜：什麼時候可以放手，什麼時候得有人把關

摘要

在 On Rails podcast 上，DHH 提出一個判斷「該不該放手讓 AI agent 全自動 vibe code」的框架：
臨界性光譜（criticality spectrum）。重點不是「能不能信任 AI」，而是
「這個系統出錯的後果有多嚴重」。後果輕的應用可以真正放手——指揮開發的人甚至完全不看程式碼；
後果重的系統（銀行、Basecamp 規模）則仍需合格人類把關。他並把 Rails 標語改成
「from prompt to IPO」，預言會出現「應用全靠 vibe code、一路做到 IPO」的公司。

核心主張：把應用攤在一條光譜上

DHH 不把問題切成「AI 能不能寫正式程式」的是非題，而是攤成一條連續光譜，兩端是他自己舉的具體錨點：

他的原話：

「我不會 vibe code 我下一個銀行 App，但有一整類應用，它們的臨界性低到——這根本不是什麼大事。」
（"I wouldn't vibe code my next bank app, but there's a whole class of apps that exist at a level of criticality where that's just not a big deal."）

換句話說，同一套 AI 工具，套在玩具 App 和銀行系統上，合理的放手程度完全不同。
判斷依據是「壞掉會死人／賠錢／外洩嗎」，而不是工具本身。

為什麼現在敢這樣講（半年前還不敢）

DHH 點出風氣的轉變：6～9 個月前大家還在擔心「agent 會洩漏所有 API key、會把密碼設成 admin」。
現在這種抱怨少很多了，他歸因於兩件事：

1. 模型本身變聰明——正常開發流程裡就是不太會犯這種低級錯。
2. 從「AI」進化到「agent」——agent 有工具，會跑測試、跑 linter。 所以即使產生幻覺，幻覺也進不了 pull request：agent 自己把 code 跑過一遍就發現不對了。

他補充：prompt injection 仍是真實風險，偶爾也還會幻覺；但「幻覺直接混進 PR」這件事，
基本上已被工具鏈擋掉。

flowchart TD
    A["要開發一個應用"] --> B{"出錯的後果<br/>有多嚴重？"}
    B -- "低臨界<br/>（玩具 / MVP / 驗證市場）" --> C["放手 vibe code<br/>人可以完全不看 code"]
    B -- "高臨界<br/>（銀行 / 大規模 / 敏感資料）" --> D["合格人類逐步審核<br/>agent 輔助但不全權"]
    C --> E["達到 product-market fit"]
    E --> F{"經濟上跑得通了？"}
    F -- "是" --> G["雇工程師 review<br/>補安全性、修組態"]
    F -- "或" --> H["agent 已強到<br/>能自行把關"]
    G --> I["臨界性隨成熟上升<br/>把關力道跟著加"]
    H --> I
    D --> I

「from prompt to IPO」：臨界性會隨產品成熟而上升

DHH 把 Rails 的標語從舊的 "hello world to IPO" 改成 "from prompt to IPO"，並預言：

未來幾年一定會出現「應用是 vibe code 出來的」公司一路做到 IPO——
vibe coding 就是你達到 product-market fit 的方式。

關鍵在於這是分階段的，臨界性不是固定的，而是隨產品長大而升高：

• 早期：低臨界、要快速驗證市場 → 放手 vibe code，不看 code 也沒關係。
• 一旦經濟上跑得通：再雇用工程師 review，確保「密碼不是 admin、Redis 沒有對整個雲端全開」 這類問題。或者到時 agent 已經好到能自己處理這些。

也就是：早期容許犯錯換取速度，做大之後補上合格人類審核。把關力道跟著臨界性一起爬升。

這其實是 Rails 一貫的精神

DHH 把這套邏輯接回 Rails 二十年的價值觀：Rails 從第一天就「擁抱臨界性光譜」。

它吸引了大量非傳統背景的人入門（他舉例：原本是生物學家、音樂家），因為 Rails
把學習曲線壓平、內建處理掉安全性等麻煩，讓新手犯的錯大多不會是致命的——
你想犯「其他語言裡最蠢的錯」都犯不了，因為框架已經幫你擋掉。

他說這跟「現在 agent 的 on-ramp」幾乎一模一樣：降低門檻、容許犯錯、讓更多人能上路。
他明確反對那種「你得先翻過 200 公尺高牆，才准進高級程式設計師的伊甸園」的社群文化——
他要 Rails 保持「平的（flat）」，讓不懂很多東西的人也能起步、上路、犯點錯、學起來。

連 Rails 框架本身，他都歡迎 agent 來貢獻功能、改善 codebase——
但強調「核心、committer、contributor 團隊裡非常合格的人類，還會需要審核很長一段時間」。
這正是臨界性光譜的體現：開放擁抱，但高臨界處（框架核心）仍要人把關。

一句話總結

後果不嚴重的應用，放手讓 agent 全自動寫（甚至不看 code），用最快速度驗證市場；
後果嚴重的系統，仍然需要合格人類把關。
而且臨界性會隨產品成熟而上升——Rails 的角色，是把整條光譜的門檻都壓平，讓兩端的人都能玩。

反向連結：DHH 談 Basecamp 5、Vibe Coding 與 Rails 的未來