金凱瑞主演過一部電影「沒問題先生」（Yes Man），劇情是一個生活陷入各種困頓的人，為了改變現況，去參加了一個「YES」心靈成長講座，而講師要他接下來一年內凡事只能說「Yes」，否則將會遭遇很可怕的厄運。
在這個「Yes」約定下，金凱瑞飾演的角色開始看到和過去不同的風景，當他因為必須不斷 YES 而做了意外之外的選擇後，許多好事接連發生，不過事情也越來越失控，甚至連 FBI 都找上門了。
現在開發人員採用 Agentic AI development 的開發模式，有時也像是個 Yes Man。基於安全防護的設計，AI 常常執行到一半就會停下來問 Yes 或 No 來取得繼續執行的授權，有時是為了讀取程式碼的內容，也有可能只是去查一個網站上的文件資訊。這個過程其實很煩，一旦工作的情境需要大量的授權時，開發人員就得一路 Yes 下去，和金凱瑞飾演的角色一樣。
想想我們用 AI 是為了能更快完成複雜的事，腦中展開的皇圖霸業是多麼雄偉、量子宇宙轉動地多麼奇幻玄妙，結果 AI 不停跑來打斷源源不絕的心流，而且不是來要求指示什麼深奧問題，只是要我同意能不能在 tmp 資料夾寫個腳本程式。
啊你就寫呀，這小事問屁問。
有怨如斯，多情應笑我，但應該也不是只有我。
於是開發圈流傳著各種讓 AI 可以停不下來的祕方，試圖不要頻頻按 Yes，甚至連 Agentic AI development 的代表產品 Claude Code 官方最近也推出了 auto mode，讓整個授權簡化，好讓開發人員的心流，或說 AI 的幹活，不會輕易地停下來。
按 Yes 背後也有判斷力
但一直按 Yes 會不會授權過度，畢竟推到極致，你盲目授權就跟養龍蝦（OpenClaw）很像，但凡有資安意識的人，都知道讓 AI Agent 自己做不停的風險有多高——弱點攻擊、機敏資料與個資外洩、成本失控……，大概想的到的資安風險安上去都能成立，而且一環扣一環還可以循環放大。
因此無人值守的 AI agent 在企業或重要專案的開發上現在是不可行的，開發人員終究得在電腦旁邊盯著 AI 看看他在做什麼，即便外人看起來，就是小學生也可以勝任地按 Yes，但 Yes 有輕如鴻毛，也有重如泰山。我們要談的，當然是泰山的部分。
我想應該有不少開發人員和我有類似的經驗，原本就是一路 Yes（心煩地）按下去，結果就在某個時刻，黑畫面流過一些不尋常的文字流：現在這個情境，他應該是要往這個方向處理，為什麼他在做這個？閃示的訊息和你過去的經驗產生越來越多的矛盾，不應該呀！心裡警訊如雷聲大響，於是手起指落，按下了 ESC 鍵當個攔路虎，飛快地打字質問 AI：「你現在做什麼？」
這個攔截，也許只是節省了 token，讓 AI 不在錯誤的方向白努力。但有可能要做的是更高風險的事情，像是之前 AWS 發生 AI coding agent Kiro 為了修改 Cost Explorer 的一個小 bug 而刪除正式環境重建（可惜發生時 AWS 的開發人員沒有來得及按下 ESC 鍵），或是網路上常常流傳覆蓋 AI 的指令去執行 rm -rf / 把本機系統和資料刪光光。開發人員在一旁值守，姑且不論跟 AI 討論來推動程式碼進展需要的專業知識，即便只是按 Yes、No、ESC 這種選擇題，都是一種「判斷」，而這個判斷力，正是 Agentic AI development 時代，開發人員最重要的價值。
親手寫 Code 煙硝味的背後
用什麼來判斷開發人員的價值是個大戰場，而最近的一場戰役開始於 Andrej Karpathy 在 2025 年 2 月創了「vibe coding」這個詞，他認為 AI 時代的開發方式就是：
- 告訴 AI 你想幹嘛
- 讓 AI 寫 code
- 透過提示詞修改
這過程完全靠 prompt 與 AI 對話寫程式，code 不是開發者勞動的重心。
而 2025 年年底時，測試驅動開發的大師 Kent Beck 更是直言 AI 產 code 的速度太快，人類根本來不及逐行檢視，因此驗證程式的行為比起看 code 更重要。雖然沒有明言不用看 code，但至少也大大降低了人類檢視 code 這個行為的重要性。
然而有另一派強力擁護開發人員必須親力親為寫 code。他們奉開發界聖經之作 Clean Code 作者 Robert Martin 的名言「Code is the design」為不能交換的核心價值，認為架構是存在 code 裡面，維護架構也是透過 code 進行，因此 code 必須容易理解才有辦法維護，好的開發人員就是要把 code 寫得讓自己以外的人都能好讀。
Robert Martin 和 Kent Beck 兩人都是在敏捷宣言上簽過字的人，但顯然在 AI 介入開發的時代，對什麼是好的開發方式產生本質性的差異。
Andrej Karpathy 提出的觀念基本上已經是現實，而不是想像。但能這樣做，跟要不要這樣做，以及這樣做好不好，則是 Martin 與 Kent Beck 及其擁護者對未來的選擇。
顯然我是比較站隊 vibe coding 這邊的，我覺得以寫 code 能力來說，幾個模型的程式開發能力都在一般水準之上，講白話一點，模型寫 code 的能力就是比你好。但我們也常常聽到 AI 寫出來的東西有問題、寫爛了，笑話著 AI 不行云云。但這就是忽略了 Karpathy 提出的第三點，爛 code 是可以改的，能把 AI 用好是開發人員的能力，反之用了 AI 得到的還是爛 code，那也是開發人員的能力。
而且逐行寫 code 看上去雖然透明，過去也有一些方法來驗證這些 code 的品質，但倚賴的也是開發人員的能力。兩個開發能力有限的人，也可以嘴上說的一套好 clean code，做起來的品質卻不是那麼一回事，跑起來可能也 bug 百出，但是彼此也還能舉杯激賞彼此走在正確的道路上。
如何做事流程以及用什麼工具與框架，抽象來看都是為了「防呆」，因為人就是會犯錯，AI 也是，而人犯錯與 AI 犯錯的機會孰高孰低即便有爭議，無論如何導正才是關鍵，而這終究需要的是判斷力，來自開發人員的判斷力，即便只是按下一個 YES。