Vibe Coding 是 2025 年最糟糕的想法？Dave Farley 的深度批判

當 OpenAI 創始人暨前特斯拉人工智慧主管 Andrej Karpathy 提出「Vibe Coding」這個概念時，軟體開發社群掀起了廣泛討論。這種主要依賴「看、說、執行、複製貼上」來與 AI 助理互動的程式設計風格，看似讓程式開發變得更加容易，但軟體工程專家 Dave Farley 卻對此提出了嚴厲批判

Dave Farley 的批判觀點

在這部影片中，Dave Farley 深入分析了為什麼他認為「氛圍式程式設計」是 2025 年最糟糕的軟體工程概念之一。儘管 Karpathy 的這番話可能帶有諷刺意味，但這個概念卻在開發社群中迅速傳播開來

軟體開發的真正挑戰

撰寫程式碼不是最困難的部分

Farley 指出，軟體產業長久以來存在一個根本性的誤解：認為撰寫程式碼是最困難的部分。這種觀點讓非技術人員和部分開發者都相信，只要能夠產出可執行的程式碼，就等同於解決了軟體開發的核心問題

然而，真正的挑戰在於

深入理解問題本質：準確掌握需要解決的業務問題
建立解決方案的概念模型：將抽象的需求轉化為具體的技術架構
精確地將人類需求轉化為電腦可執行的指令：這需要深度的思考和設計能力

程式語言的本質與價值

程式語言並非隨意或因潮流而變得複雜，它們是經過數十年演變而來的思考工具，具有三大核心目標

協助我們組織對問題的思考
將我們的理解傳達給其他人類
指示電腦執行特定任務

相較於自然語言的模糊性，程式語言更為簡潔、嚴格且精確。期望透過自然語言的豐富性來精確定義電腦行為，實際上是對軟體開發本質的誤解

AI 輔助開發面臨的三大挑戰

1. 如何精確定義需求

自然語言的模糊性使得需求規範難以達到軟體開發所需的精確度。當我們使用「氛圍式程式設計」與 AI 對話時，往往無法清楚表達我們真正想要的功能

2. 如何確認成果符合預期

由於大型語言模型是從海量的程式碼（包括好、壞、甚至糟糕的程式碼）中學習，它們往往缺乏對「好程式碼」的判斷力。AI 產生的程式碼更需要強大的自動化測試來驗證其正確性

3. 如何維持可控的增量式進度

人類程式設計師透過小步迭代來構建複雜系統，但 AI 往往從頭產生完整的程式碼。這種做法與傳統的軟體開發流程不符，缺乏「往返編輯能力」(round-tripping) 來支援程式碼的持續演進

歷史的教訓與借鑒

Farley 將 AI 從頭產生程式碼的特性，與過去一些失敗的抽象化嘗試進行比較

1990 年代的第四代程式語言 (4GLs)
模型驅動開發 (model-driven development)
當前的低程式碼/無程式碼平台

這些工具的共同弱點是假定程式碼一次性完成且無需修正，忽略了「程式碼會隨時間演進」這一基本事實

可執行規範：未來的解決方向

即使有 AI 輔助，軟體工程的基本原則依然重要。Farley 建議採用「可執行規範」(executable specifications) 來引導 AI，這意味著

提供精確、可重複執行的範例
明確描述系統在特定條件下的行為
將程式設計的重點從實作細節轉移到系統意圖的清晰定義

自動化測試、持續整合 (Continuous Integration) 和持續交付 (Continuous Delivery) 對於 AI 產生的程式碼而言，甚至比人類編寫的程式碼更為關鍵

我的觀點與思考

從 Dave Farley 的分析中，我們可以看到「Vibe Coding」雖然降低了程式開發的門檻，但卻可能掩蓋了軟體工程的本質問題。在我過往的實體分享中，我也提到了類似的觀點

真正值得思考的是：我們如何讓 AI (或 agent) 在協助開發時，使用更好的方法來解決這些根本問題，而不是迴避它們

一些可能的方向包括

強化需求分析階段：使用更結構化的方法來與 AI 溝通需求
建立更完善的測試策略：確保 AI 產生的程式碼品質
採用增量式開發方法：即使使用 AI，也要保持小步迭代的開發節奏
重視程式碼的可維護性：不只關注功能實現，更要考慮長期的維護成本

結語

軟體工程正在快速變化，但其根本挑戰——精確規範、成果驗證和增量式進度——依然存在。任何新的程式設計方法都必須有效地解決這些問題

「Vibe Coding」的流行反映了開發者對更簡單開發方式的渴望，但我們不能因此忽略軟體工程的核心價值。AI 應該是我們思考和設計的助手，而不是思考的替代品

正如 Dave Farley 所強調的，程式語言是思考的工具，而軟體開發的真正挑戰在於理解問題和設計解決方案。無論技術如何演進，這些基本原則都不會改變

支持創作

如果這篇文章對您有幫助，歡迎透過贊助連結支持我持續創作優質內容。您的支持是我前進的動力！

圖片來源：AI 產生