Vibe Coding 與 Agentic Engineering 的融合

軟體開發的格局正經歷一次巨大的變革。我們正見證兩種既不同又相互重疊的範式的出現：「vibe coding」——根據對期望結果的整體感受，提示 AI 產生可運作軟體的行為——以及「agentic engineering」，在此範式中，AI 代理被整合進具結構的多步驟開發生命週期，並設有嚴格的品質關卡。

當這兩種方法融合時，核心的張力隨之產生：當產生程式碼的成本降至近乎零，而審查與驗證的成本仍頑固地居高不下，我們該如何維持軟體的完整性與可維護性？

定義分野：Vibe 與工程

要了解當前的摩擦，我們必須先定義這些術語。Vibe coding 的特徵是「一次性」或「少量示例」的心態。它屬於原型、輕量 PoC（概念驗證）以及個人專案的領域。目標是即時功能；只要它能運作且「vibes」正確，就直接上線。

相較之下，Agentic engineering 關注的是問責與流程。它將 LLM 視為一位高度能幹（雖偶爾不穩定）的初級開發者，而非魔杖。在此模型中，AI 被嵌入一條包含以下階段的管線：

• 專案規格： 對史詩與使用者故事的詳細分解。
• 確定性品質關卡： 自動化測試、效能基準與靜態分析。
• 對抗式審查： 人類或代理式對程式碼的優雅度、安全性與商業價值進行審核。

審查者的兩難

從業者提出的最迫切關切之一是「審查負擔」。隨著代理產出的程式碼量增加，潛在錯誤的「乾草堆」也隨之擴大。

「即使程式碼能編譯且運作，但在某些邊緣情況下執行錯誤，或存在安全漏洞，或引入技術債務或可疑的架構決策，這些都較難被發現，卻絲毫不會減輕審查負擔。」

這會形成一個心理陷阱：「偏差常態化」。當 AI 連續產出十個正確的端點時，人工審查者會傾向不再仔細檢查第十一個。然而，專業工程的本質在於抵制這種衝動。風險不僅是單一錯誤，而是可維護性的系統性崩潰——未來的程式碼庫可能會變成「由 LLM 產生、數十億行程式碼且無人閱讀的混亂巨獸」。

轉移工程焦點

如果撰寫程式碼的行為正被商品化，那麼人類工程師的價值將流向何處？資深開發者的共識指出，應轉向更高層次的抽象：

1. 架構作為主要槓桿

當架構的「底層節點」（例如標準的 JSON API 端點）可以由 AI 依樣畫葫蘆時，工程師的角色就轉變為設計系統，使這些元件能無縫結合。卓越的新標準是將程式碼架構設計得如此明確，以致 LLM 能實作功能而不引入微妙的交互錯誤。

2. 從程式碼打造轉向驗證打造

工程師不再花數小時打磨單一函式，而是將這些時間投入於打造「量身訂製、全面的驗證機制」。這包括重疊的測試層級——端對端（E2E）、整合測試與效能指標，使得代理工作之正確性可透過數學或實證方式證明。

3. 上下文管理

代理的效能取決於所提供的上下文。新興的「agentic engineer」角色在於管理業務需求、架構決策記錄（ADRs）與領域知識的流入 AI 提示視窗，確保輸出與專案的長期願景保持一致。

經濟與組織影響

向 AI 輔助開發的轉變不僅是技術層面的變化，更是經濟層面的變革。管理層日益擔憂軟體的「鐵三角」（快速、低成本、高品質）已被打破，認為現在可以同時兼得三者。這導致一種危險的激勵結構：在未相應提升品質保證資源的情況下，要求十倍的生產力。

此外，「vibe coding」的興起可能衝擊 SaaS 模式。若公司能以低成本透過 vibe coding 製作完全符合其工作流程的客製化內部工具，則支付給通用、「足夠好」的第三方 CRM 或 ERP 的動機將減弱。

結論：前進之路

無論稱之為 vibe coding 或 agentic engineering，基本的事實仍然不變：製作軟體極其艱難。AI 是現有經驗的強大放大器；它讓專家能更快前進，也讓新手能建構更多。然而，最終產出的責任仍屬於人類。目標不是消除審查流程，而是使其演進——從逐行手動檢查，轉向對代理的策略編排與對其結果的嚴格驗證。