Factory AI 共同創辦人暨技術長 Eno Reyes 在本場演講中提出一個核心論點：限制 AI 程式碼代理（Coding Agent）發揮的瓶頸，不是模型能力本身，而是組織的自動化驗證（Validation）水準。他從「透過驗證實現自動化」的概念出發，說明為什麼軟體開發高度可驗證，並呼籲工程組織投資改善驗證基礎設施，才能真正釋放 AI Agent 的潛力。

---

原影片連結：https://www.youtube.com/watch?v=ShuJ_CN6zr4

影片重點

• 軟體開發是目前最具「可驗證性」的領域，這也是為什麼 Coding Agent 是當今最先進的 AI Agent
• Andrej Karpathy 提出的「Software 2.0」概念：從「透過規格說明建構」轉向「透過驗證實現自動化」
• 驗證的非對稱性（Asymmetry of Verification）：許多任務驗證比解決容易得多
• 大多數程式碼庫的驗證覆蓋率僅 50-60%，對人類夠用，但對 AI Agent 而言遠遠不夠
• 開發流程正從傳統開發轉向「規格驅動開發」（Specification-Driven Development）
• 投資驗證基礎設施帶來的不是 1.5x 或 2x 的效率提升，而是 5x-7x 的飛躍
• 一個有主見的工程師（Opinionated Engineer）可以透過定義驗證標準，有意義地改變整個企業的開發速度
• 軟體工程師的角色正在轉型：從直接寫程式碼，變成策劃 AI 構建軟體的環境與約束

詳細內容

[00:00] 開場：Factory AI 的使命

Eno Reyes 是 Factory AI 的共同創辦人暨技術長，公司成立於兩年半前，使命是「為軟體工程帶來自主性（Autonomy）」。他表示本場演講的目標是讓聽眾帶走一些可以應用於自身組織、團隊和產品的洞見，而且這些觀點不限於特定工具，適用於所有涉及 AI 的開發工具。

[01:05] 從 Karpathy 的推文談起：透過驗證實現自動化

Eno 引用 Andrej Karpathy 的推文，談到「Software 2.0」的概念。核心觀點是：AI 系統能解決問題的邊界，本質上取決於你是否能定義一個目標（Objective），並在可能的解決方案空間中進行搜索。傳統軟體工程透過「規格說明」（Specification）來建構——輸入是 x，輸出是 y。但如果轉換思維，改為「透過驗證實現自動化」（Automation via Verification），能夠建構的東西就會大不相同。

[02:15] 驗證的非對稱性

Eno 引用 Jason 的文章談到「驗證的非對稱性」（Asymmetry of Verification），這與 P vs NP 問題密切相關。許多任務驗證起來比解決它們容易得多。最適合 AI 處理的問題具備以下特點：存在客觀事實（Objective Truth）、驗證速度快、可以大規模並行驗證、低雜訊（驗證結果高度可靠）、具有連續性訊號（不只是對或錯，而是有程度之分）。

軟體開發恰恰高度滿足這些條件，這就是為什麼軟體開發 Agent 是當今世界上最先進的 AI Agent。

[03:30] 軟體驗證的現有基礎設施

過去 20-30 年，軟體產業已經建立了大量自動化驗證和測試基礎設施：單元測試（Unit Test）、端對端測試（End-to-End Test）、QA 測試等。而且這個邊界還在擴展中——像 Browserbase 這樣的公司和電腦使用代理（Computer Use Agent）正在讓驗證複雜的視覺或前端變更變得更容易。此外，OpenAPI Spec 等文件標準也是可以自動驗證的元素。

Eno 提出了一份自我檢查清單：你的程式碼格式有自動驗證嗎？有 Linter 嗎？有 AGENTS.md 檔案嗎？這些對專業工程師來說看似理所當然，但他認為可以做得更進一步。

[05:00] 為什麼 50-60% 的覆蓋率對 AI Agent 不夠

大多數軟體組織的測試覆蓋率大約在 50-60%。這對人類開發者來說夠用了，因為人類會手動測試、依靠經驗判斷。你的公司可能有一個不穩定的建置流程（Flaky Build），每三次失敗一次，所有人暗地裡都很討厭它但沒人說——在大型工程組織中這已成為被接受的常態。

但當你開始將 AI Agent 引入軟體開發生命週期——不只是互動式編程（Interactive Coding），還包括程式碼審查（Code Review）、文件撰寫、測試等所有環節——這種不足就會嚴重限制 Agent 的能力。

[06:30] 驗證嚴格的組織 vs 一般組織

Eno 觀察到，目前世界上最好的公司已經引入了非常嚴格的驗證標準，因此他們使用 Agent 的能力遠遠超過一般開發者。傳統的開發流程是「理解問題 → 設計方案 → 編碼 → 測試」，但如果有嚴格的驗證機制，使用 Agent 的流程就會變成：指定驗證約束和需求 → 生成解決方案 → 自動驗證加上個人直覺判斷 → 持續迭代。

[07:45] 規格驅動開發的興起

這種從傳統開發到「規格驅動開發」（Specification-Driven Development）的轉變正在滲透到各種工具中。不同的工具都開始支持規格模式（Spec Mode）、計劃模式（Plan Mode）。有些 IDE 整體架構就圍繞著這種規格驅動流程設計。將規格驅動開發和嚴格的驗證結合起來，才是構建可靠且高品質解決方案的關鍵。

[08:30] 組織應該做出的決策

Eno 提出了一個尖銳的問題：作為組織，你的最佳決策是什麼？是花 45 天比較所有可能的編程工具，然後判斷某個工具因為在 SWE-bench 上多了 10% 的準確率就稍微好一點？還是改善組織實踐，讓所有這些 Coding Agent 都能成功，然後隨便選一個開發者喜歡的工具？

答案顯然是後者。有了驗證標準後，你才能引入更複雜的 AI 工作流程。如果你無法自動驗證一個 PR 是否合理、程式碼是否不會搞壞生產環境，那你就不可能同時並行多個 Agent，也不可能將大規模現代化專案分解成多個子任務。

[10:15] 程式碼審查與文件的重要性

如果你想要高品質的 AI 生成的程式碼審查，你需要為 AI 系統提供文件。是的，Agent 會逐漸變得更擅長自動判斷是否要執行 Lint 或測試，也會更擅長在沒有明確指示的情況下尋找解決方案、更擅長搜索。但它們不會憑空創造出驗證標準。

這就是為什麼 Eno 認為軟體開發者將繼續深度參與軟體建構過程——角色正在轉型：從直接寫程式碼，變成策劃軟體構建環境、設定約束、建構自動化流程、持續引入更多有主見的（Opinionated）規範。

[11:45] 八大自動化驗證支柱

Eno 提到了八個自動化驗證的支柱，組織可以逐一檢視自己的達成程度。關鍵問題包括：你的 Linter 有多好？是否有好到 Coding Agent 產出的程式碼能達到資深工程師的水準？你有 AGENTS.md 檔案嗎？這是幾乎所有 Coding Agent 都支援的開放標準。你是否有能在 AI 產生低品質程式碼（AI Slop）時失敗、在高品質程式碼通過時成功的測試？

他特別提到，如果你有工具能追蹤哪些開發者使用了什麼工具，你可能會發現初階開發者完全無法使用這些 Coding Agent。原因不是他們能力不足，而是有些小眾實踐（Niche Practices）缺乏自動化驗證。

[13:30] Google/Meta 與一般組織的差異

Eno 以 Google、Meta 為例：一個剛入職的新人，幾乎零上下文（Zero Context），就能提交一個讓 YouTube 按鈕邊角變圓的修改，而且有相當把握不會讓十億用戶的 YouTube 掛掉。這是因為在程式碼被部署之前，必須經過瘋狂數量的驗證。

現在的差別是，我們有了 Coding Agent 可以識別這些驗證缺口在哪裡，而且能夠自動修補這些問題。你可以要求 Coding Agent 找出 Linter 不夠嚴格的地方，也可以要求它生成測試。

[14:30] 「品質不佳的測試也比沒有測試好」

Eno 引用了 Factory AI 工程師 Alvin 的一句話：「A slop test is better than no test」——品質不佳的測試也比沒有測試好。他承認這有點爭議，但論點是：只要測試存在，當修改正確時它能通過，且大致符合你想要構建的規格，人們就會逐步強化它。其他 Agent 也會注意到這些測試並遵循其模式。你越有主見，這個正向循環就越快。

[15:30] 正向反饋循環

Eno 描述了一個強大的反饋循環：更好的 Agent → 改善環境 → 更好的 Agent → 更多時間改善環境。這就是新的開發者體驗（DevX）循環，組織可以投資於此，而且它會強化你採購的所有工具——無論是程式碼審查工具還是 Coding Agent，都會受益。

這也改變了領導者的思維模式。傳統上，工程專案的投入是「營運支出」（OpEx）——我們需要更多人來解決問題。但現在你還可以投資於這個環境反饋循環，讓每個人都變得更有效率。

[17:00] 一個有主見的工程師可以改變整個企業

Eno 強調了一個關鍵洞見：如果你是那個能說「這是我的意見，這是我希望軟體被建構的方式」的人，你的能力比以往任何時候都能更大規模地擴展。一個有主見的工程師（Opinionated Engineer），透過定義驗證標準和自動化規範，可以有意義地改變整個企業的開發速度。

[18:00] 展望未來：從一小時的修復循環到 5x-7x 的效率提升

Eno 描繪了一個願景：客戶問題進來 → Bug 被提交 → Ticket 被 Coding Agent 接收並執行 → 結果呈現給開發者 → 開發者點擊批准 → 程式碼合併並部署到生產環境——整個循環只需 1-2 小時。這在技術上今天就可行，限制因素不是 Coding Agent 的能力，而是你的組織的驗證標準。

投資驗證基礎設施帶來的不是 1.5x 或 2x 的效率提升，而是真正的 5x、6x、7x。但這需要組織主動投資——AI 不會自動賜予你這些，這是你作為組織必須做出的選擇。如果現在就做出這個選擇，Eno 保證你的組織將進入開發速度的前 1-5%。

我的想法

Eno 的演講點出了一個很多團隊在「AI 工具焦慮症」中忽略的盲點：與其花時間比較哪個 Coding Agent 的 benchmark 分數高 3%，不如回頭審視自己的程式碼庫是否準備好讓 AI 來工作。這個觀點非常務實，因為它把控制權交回到工程團隊手中。

「A slop test is better than no test」這句話值得深思。在追求完美的工程文化中，很多團隊寧可不寫測試也不願寫「不完美」的測試。但在 AI Agent 的時代，有測試和沒測試的差距，遠大於好測試和普通測試的差距。這是一個值得調整的心態。

不過，值得注意的是，Eno 作為 AI 程式碼工具的創辦人，他的觀點自然帶有商業立場。他將責任從「工具不夠好」轉向「你的環境不夠好」，這對工具廠商當然有利。現實中，兩者都很重要——工具能力和環境準備度需要同步提升。

最後，「一個有主見的工程師可以改變整個企業」這個說法令人振奮，但也暗示了一個挑戰：在大型組織中，推動驗證標準的統一需要跨團隊的共識和持續的文化建設，這往往比技術本身更難。