Paul Everitt 談向代理工程（Agentic Engineering）的轉型

核心論點：從「感覺編碼」（Vibe Coding）到「代理工程」

軟體工程目前正經歷著一個生產力悖論：雖然 AI 允許大幅增加程式碼輸出，但這尚未轉化為持久的組織價值。產業目前正處於「感覺編碼」（vibe coding）階段——基本上是寄望於 AI 生成的程式碼能正常運作——這往往導致品質下降，並導致企業專注於透過裁員來追求短期利潤，而非長期創新。

為了解决這個問題，產業必須轉向 代理工程（agentic engineering）。這是「建造『建造工具』的東西」的實踐。代理工程並非使用 AI 來取代人類開發者，而是專注於建立系統、腳手架（scaffolding）和護欄（guardrails），以增強人類能力並確保 AI 代理（agents）在嚴謹的工程學科內運作。

生產力悖論與組織失敗

儘管擁有強大的 AI 工具（「神盒」），許多組織仍無法實現系統性價值。Paul Everitt 指出了幾個關鍵的失敗點：

• 編碼瓶頸謬誤： 引用諾貝爾獎得主 Daron Acemoglu 和 Grady Booch，Everitt 指出，編碼本身從來不是軟體工程的主要瓶頸。加速程式碼生成僅解決了工程過程中的一小部分問題。
• 品質與信任問題： 信任存在顯著差距，僅有 3% 的開發者表示對生成結果的準確性有高度信心。這造成了「挑戰者號」（Challenger-style）災難的風險，即代理在沒有人類監督的情況下將錯誤的程式碼直接推送到生產環境。
• 「Token 最大化」問題： 員工可能會為了增加 token 使用量或輸出指標而操縱系統，導致管理層對 AI 成功的認知與工程師的實際體驗之間出現脫節。
• 目標不一致： 許多公司正將 AI 作為「大規模裁員」的藉口來推高股價，而非利用這項技術來創造以前無法實現的產品。

代理工程的實踐定義

代理工程不在於編寫程式碼的行為，而在於管理 AI 代理的系統設計。它將工程師的角色從手動建造者轉變為系統架構師。關鍵的實踐組成部分包括：

評估與測試

• 評估優於「點擊按鈕」： 工程需要客觀的衡量。開發者必須實施嚴格的評估（evaluations）來確定代理是否在特定的預算和輪次（turns）內生成高品質的程式碼。
• 代理的紅綠測試（Red-Green Testing）： 透過先寫一個失敗的測試，工程師可以精確定義「成功」的樣子。接著，代理會模仿工程師的測試風格，並朝著定義好的綠色狀態（green state）努力，從而減少在程式碼庫中「漫遊」的時間。

工具與基礎設施

• 安全沙箱（Secure Sandboxing）： 代理不應只是簡單地在程式碼庫中進行 grep，它們應該在安全、低延遲的沙箱中生成並執行特定的工具程式碼（例如使用 Python 的 Rust-based 子集，如 Monty）來解決問題。
• 掌控掌控架構（Harness Engineering）： Everitt 強調，「如果你不擁有你的架構（harness），你就無法擁有你的記憶。」掌控編排（orchestration）和執行環境對於維持對代理行為的控制至關重要。

系統設計與模組化

• 以代理為中心的架構（Agent-Centric Architecture）： 大型舊有程式碼庫可能需要重新組織。在代理的世界中，模組化看起來有所不同，需要支持並行子代理（sub-agents）和高度專業化的上下文工程（context engineering）的結構。
• QA 代理： 與其讓人類成為品質保證的瓶頸，工程師應該建立 QA 代理，讓它們透過瀏覽器或開發者工具協定來收集自身的檢測工具（instrumentation），以便為人類審查做準備。

號召行動：奪回工程學科的定義權

Everitt 主張，軟體社群必須奪回「工程」作為一門嚴謹科學與實踐的定義權。他挑戰開發者超越目前的炒作週期，並建立 代理設計模式（agentic design patterns）——一套用於構建 AI 驅動系統的標準化、可重複使用的架構模式。

目標是將領導層的敘事從「更多程式碼，更少的人員」轉向「透過增強來實現創新」。透過專注於系統設計和工程學科，開發者可以確保 AI 被用於建造宏偉的新解決方案，而非僅僅是榨取利潤率。