讓程式碼庫具備「Agent Ready」能力：by Eno Reyes（Factory AI）

講者 Eno Reyes (CTO & Co-Founder of Factory) https://www.linkedin.com/in/enoreyes/

本篇為閱讀 AI Engineer Youtube channel 的摘要

1) 開場：Factory 的核心使命與今天要帶走的東西

講者 Eno 一開始說，他非常興奮能分享一個 Factory 內部「非常在意」的主題。兩年半前 Factory 創立時，他們就把使命定義為：把「自主性（autonomy）」帶進軟體工程。

他也坦白承認，這個使命裡面有很多「帶重量、帶含義」的字眼，現在聽起來可能有點像 buzzword。但他今天的目標，是希望大家在大約 20 分鐘之後能帶走一堆可直接套用的洞察：

  • 可以用在你的組織與團隊建設上
  • 可以用在你所顧問/建議的公司上
  • 如果你在做 AI 相關產品，也能得到「如何思考建構自主系統」的觀點
  • 以及：如何讓你的工程組織能非常成功地使用 agents

他補充一個「額外的好處」：今天講的內容理想上不會只適用於 Factory 的產品，也不會只對某些特定工具有效；只要你用到任何「涉及 AI」的工具，這些原則都應該適用。

2) 從 Karpathy 的觀點切入：Software 2.0 與「可驗證性」

Eno 先從 Andrej Karpathy 的推文談起。

Karpathy 談到一個想法：Software 2.0 來自於「驗證（verify）」能力。這個概念正好也是現在矽谷在想的事情之一：最前沿的模型在 post-training 階段，常常會納入很多「可驗證（verifiable）」的任務。

Eno 認為這裡最有趣的一點是：
AI 系統能解決問題的前沿與邊界，本質上取決於一件事：你能不能「清楚指定目標」，並在「可能解空間」裡做搜尋。

他用對比方式說明我們過去熟悉的軟體開發方式：

  • 我們習慣用「規格（specification）」來建軟體：
    「演算法做什麼」
    「輸入是 X、輸出是 Y」

但如果你把心智模型從「靠規格建構」稍微移到「靠驗證來做自動化（automation via verification）」，你能建的東西就會有點不一樣。

3) 驗證的不對稱（Asymmetry of Verification）：為什麼這跟 P vs NP 有關

Eno 接著提到 Jason 的一篇很棒的部落格文章，談的是verification 的不對稱性。他說這對了解 P vs NP 的人很直覺：在計算與軟體的歷史中，很多人都談過——

  • 有大量任務是「驗證比解題容易很多」
  • 也有反過來的情況（但他此處重點放在前者）

而「最有趣、最值得利用的」那類「容易驗證」問題，通常具備以下特性（他逐點描述）：

  1. 有客觀真相（objective truth）
  2. 可以很快驗證真偽
  3. 可擴展（scalable）：一次驗很多件事、甚至平行驗證都容易
  4. 低雜訊（low noise）：你驗證成功的機率很高、很可靠
  5. 有連續訊號（continuous signals）：不是只有二元的 yes/no
    可能是 30%、70%、100% 的正確程度或符合程度

4) 為什麼「軟體開發」是高度可驗證的領域（也是 agents 最前沿的原因）

Eno 說他同時提 Karpathy 與 Jason 的原因，是因為：軟體開發本身就是高度可驗證的。

他直接下結論：
這就是為什麼「軟體開發 agents」是現在世界上最先進的 agents。

原因在於：過去 20 ～ 30 年，軟體領域投入了大量工作在「自動化驗證/確認」上。舉例包括：

  • Testing：單元測試（unit tests）、端到端測試（end-to-end tests）、QA tests
  • 而且驗證的前沿還在擴張：
    有很多很酷的公司（他點名例如 browser base、computer use agents 等）正在讓「驗證更複雜的視覺或前端變更」變得更容易
  • Docs（文件）：
    有一份「開放 API 規格（open API spec）」可以被自動化處理，也可以被驗證
  • 他說他還可以繼續列很多，但他更想把它當作一份「自我檢查清單」

5) 一份實務檢查清單：你到底有沒有把「驗證」做到足夠強？

Eno 建議大家把這些當成 checklist 來問自己：

  • 你是否有對程式碼「格式」的自動化驗證？
  • 你有沒有 linters？

他也承認：對專業軟體工程師來說，這些看起來像「當然有」。但他要大家再往前一步，因為關鍵在於他前面說的「continuous validation」：

5.1 更進一步的問題：你的 linter 夠「意見強烈」嗎？

他提出一個更尖銳的問題（幾乎是挑戰式的）：

  • 你的 linter 是否「夠 opinionated」到一個程度：

讓 coding agent 寫出來的 code，永遠都能達到你資深工程師的品質水平？

他自己也追問：
「怎麼做到？那到底代表什麼？」

5.2 更進一步的問題：你有沒有能抓出「AI slop」的測試？

他又提出另一個非常具體的標準：

  • 你有沒有 tests 會在 **AI slop（他用 slop 這個詞，指低品質 AI 產出）**被引入時就 fail？
  • 而當 高品質 AI code 被引入時，這些 tests 會 pass？

他強調：這些「額外的 validators」是多數程式碼庫其實缺乏的。

6) 為什麼人類勉強可接受的工程現況，會讓 agents 直接卡死

Eno 解釋：很多事情人類可以「靠手動」消化掉，所以就算沒有自動驗證也能運作。

他舉了幾個大型 codebase 常見的狀況（非常貼近現實）：

  • 你的公司 test coverage 可能只有 50% 或 60%，但「夠用」
    因為人會手動測
  • 你的 build 可能很 flaky：每三次就會失敗一次
    全公司其實都默默討厭它，但沒人講

他說這些在大型 codebase 裡都是真的。而當你擴張到超大規模組織——例如 44,000+ 工程師——這種「bar 只有 50% 或 60%」甚至變成一種被接受的常態。

他也承認：多數軟體組織其實可以在這種較低門檻下擴張，某種程度上是「還行」。

但重點來了：
一旦你把 AI agents 引入 SDLC（軟體開發生命週期），而且不只是互動式寫 code，而是「全面」——包含：

  • code review
  • documentation
  • testing
  • 等等

這些既有的缺口會直接打破 agents 的能力上限。

7) 驗證夠嚴謹的公司，agents 能力會「顯著高於平均」

Eno 說，多數人可能只看過 agents 在「驗證做得不錯」的 codebase 裡運作。

他觀察：現在世界上一些最強的公司，已經引入非常嚴格的 validation criteria，所以他們能使用 agents 的能力，會顯著高於一般開發者。

8) 開發迴圈的位移：從「理解 → 設計 → 寫 → 測」到「規格/約束 → 生成 → 驗證 → 迭代」

Eno 描述傳統開發 loop：

  1. 理解問題（understanding）
  2. 設計解法（designing）
  3. 寫 code（coding）
  4. 測試（testing）

但如果你有非常嚴格的驗證，當你用 agents 時，流程會改變成：

  1. 指定約束與驗證方式：你希望怎麼被驗證、你希望建出什麼
  2. 生成解法：產生能達到結果的方案
  3. 驗證：
    • 用自動化驗證（automated validation）
    • 加上你自己的直覺判斷（your own intuition）
  4. 迭代：持續在這個 loop 裡迭代

他把這種轉變稱為：
從傳統開發走向 specification-driven development（規格/約束驅動的開發）

他說這種轉變正在「滲透」到各種工具中：

  • 各種工具開始有 spec mode
  • 他們的 coding agent（他提到：droid 是 factory 的 coding agent）也有 specification mode、plan mode
  • 甚至有整個 IDE 是圍繞這種 specification-driven flow 來設計的

而如果你把「嚴格驗證」+「spec 驅動流程」結合起來，這就是建出可靠、高品質解法的方法。

9) 組織層面的關鍵選擇：比起挑工具 45 天，更該投資讓所有 agents 都成功的環境

Eno 提出一個組織決策的對照題（非常直白）：

  • 你應該花 45 天比較市面上每一個 coding tool，最後選出某個因為在 Sweebench 上只多 10% 準確而略勝一籌的工具？
  • 還是你應該改變組織實作方式，讓所有 coding agents 都更容易成功，然後再挑一個開發者喜歡的工具，甚至讓大家自由選擇眾多好工具？

他的方向很明確：後者更重要。

10) 沒有可自動驗證的 PR 成功標準，就別談平行 agents 與大規模拆解

他進一步指出：當你有足夠的 validation criteria，你就能在組織內導入更複雜的 AI workflows。例如：

  • 同時平行跑多個 agents
  • 把大型 modernization 專案拆成很多子任務分頭做（他說這是很 frontier 的 AI 用法）

但前提是：你必須能「自動驗證」某個 PR 是否算合理成功、是否不會明顯把 production 弄壞。否則你不可能放心平行化。

他也把門檻講得很硬：

如果單一任務的執行（我想完成 X、怎麼做、怎麼驗證）不能在接近 100% 的情況下成功，那你就幾乎可以忘記在公司規模化使用那些更進階的做法。

11) 想要高品質 AI code review？你需要文件（documentation）給 AI 系統

當談到 code review 這類工具時，他指出：
如果你要「很高品質的 AI 產生 code review」，你需要給 AI 系統文件/脈絡。

他承認 agents 會進步：

  • 會更會判斷要不要跑 lint/test
  • 在缺乏明確指示時，會更會找解法
  • 會更擅長搜尋

但他也強調一件事：
agents 不會進步到「憑空從無到有」隨機生成你的 validation criteria。這也是為什麼他相信：

軟體工程師會持續深度參與軟體建置流程。

因為你的角色會轉變成：

  • 管理與策展（curate）軟體建置的「環境與花園」
  • 設定約束
  • 建立自動化
  • 持續把「更有意見（continued opinionated-ness）」灌進這些自動化裡

他說：如果公司連這些都沒有，那就代表你有很多事情可以做，而且完全不需要先經歷採購流程、或先買某個工具、或換另一個工具試試。

12) 如何系統化評估與提升：八大支柱、lint、AGENTS.md

Factory：他們會幫組織做這件事。

他提到工具面可以做到：

  • assessment（評估）
  • ROI analytics（投報分析）讓你互動檢視

但他也說：對多數組織，其實有一條很清楚的路徑可以走——你可以分析自己在「自動化驗證的八個支柱」上處於什麼位置（他在逐字稿中沒有逐一列出八項名稱，但明確說是八個 pillar）。

他舉例你可以具體問：

  • 你有 linter 嗎？
  • linter 有多好？
  • 你有沒有 AGENTS.md 檔案？
    他稱這是「一個開放標準（open standard）」，而且「幾乎每一個 coding agent 都支援」。

你可以系統性地把這些 validation criteria 一步步提升。

13) 可靠性不是「新人不會用」，而是你缺少自動化去覆蓋那些「小眾但重要」的習慣

Eno 描述一個你能做的分析方式：當你有工具能告訴你「哪個開發者在用哪些工具」時，你就能問：

  • 為什麼資深工程師用 agents 很可靠
  • 但初階工程師卻幾乎沒辦法用？

而你可能會發現：原因不是初階更不行、也不是不會用工具，而是你們有一些「niche practices（小眾習慣/做法）」沒有被自動化驗證涵蓋。

14) Google/Meta vs 2000 人工程組織：差別在「新手零脈絡也能安全出貨」

他用一個對比說明「驗證文化的差距」：

  • 像 Google 或 Meta 這種等級的組織
  • 跟一個仍然很大、但大約 2000 人的工程組織

差別在於：
在前者，你可以讓一個幾乎「零上下文」的新鮮人去改一個變更——例如讓 YouTube 的邊界「更圓一點」——而且在某種信心程度下，不會害 YouTube 對十億使用者掛掉。

他說這能成立的原因是：
要讓那段 code 被 shipped，背後必須有**瘋狂大量（insane amounts）**的 validation 發生。

15) 新的轉折：coding agents 能找出缺口，甚至能協助補上缺口

Eno 接著說：現在有個很大的不同是——我們有 coding agents，可以：

  • 找出你在哪些地方「不夠 opinionated」（例如 linter 規則不足）
  • 幫你補救、修復這些缺口

他舉例你可以直接問 agent：

  • 你能不能找出我們 linter 哪裡不夠 opinionated？
  • 你能不能幫我們產 tests？

16) 「有 slop 的 test 也比沒有 test 好」：Alvin 的一句話與 Eno 的立場

他提到一位工程師 Alvin（Eno 說他很喜歡這句話）：

“A slop test is better than no test.”
（有點「爛/粗糙」的測試，也比完全沒有測試好。）

Eno 說這句話可能有點爭議，但他的論點是：

  • 先「有東西在那裡」很重要
  • 只要它在變更正確時會 pass，且能「某種程度上」對齊你想建的 spec
    之後人會去強化它、升級它
  • 而且其他 agents 會「注意到」這些 tests、會遵循模式
    因此你越 opinionated，循環就跑得越快

17) 新的 DevEx 正回饋迴圈：環境越好 → agents 越好 → 你越有時間把環境變更好

他要大家思考：你們組織正在「服務哪一種 feedback loop」？

他描述一個正循環（他把它視為新的 DevEx loop）：

  • 有更好的 agents
    → 會讓環境變更好
    → 環境變好又讓 agents 變更好
    → 你就有更多時間繼續改善環境

而這個迴圈的價值在於：
它能提升你採購/使用的所有工具，不管是 code review tool、coding agent 等等，都會受益。

18) 領導者的投資心智模型也要變：不只加人（OpEx），也要投資「環境迴圈」

Eno 說這會改變你作為領導者在投資工程工作時的心智模型。

傳統上，我們把 OpEx 當作工程投入：

  • 想解決問題就「需要多 10 個人」

他主張：現在你還能投資另一個方向——

  • 投資「環境回饋迴圈」
    讓這些新增的人（或既有人力）能更成功

而他認為這個迴圈能產生很大的價值，因為 coding agents 可以把它規模化擴張。

19) 好的 coding agent 會主動利用 validation loop；不會找 lint/test 的 agent 終究不夠好

他總結一個判準：除了工具本身，還有很多事情可以做來 enable 這些系統。

同時，他也說「最好的 coding agents」會吃到這些 validation loops 的紅利。反過來：

  • 如果你的 coding agent 不會主動去找 linters、tests 等驗證依據
    那它終究不會像會主動尋找驗證的 agent 那麼好

20) 「一個有主見的工程師」可以放大到改變整個企業速度

Eno 也把話題拉回到「人」：

如果你是一個能清楚說出：

  • 這是我的意見（opinion）
  • 我希望軟體用這種方式被建出來

你就能以前所未有的方式把能力放大。
他甚至說：一個 opinionated 工程師只要你真的把這套做法落地，而且能衡量、系統化改善，就能「有意義地」改變整個 business 的速度（velocity）。

他說這大概就是他今天主要想講的內容。

21) 結尾：全自動從工單到上線「技術上今天就可行」，真正的限制是你家的驗證標準

最後他留給大家一個對未來的畫面：我們仍然處在使用軟體開發 agents 的「很早期」。

他描述一個端到端的流程願景：

  • 客戶 issue 進來
  • 形成 bug、建立 ticket
  • ticket 被接起來
  • coding agent 執行修復
  • feedback 呈現給開發者
  • 開發者點擊 approve
  • code 被 merge 並部署到 production
  • 整個 feedback loop 可能只要 1 ～ 2 小時

他連說了兩次：這會是可能的（That will be possible）。

他也承認大家對「完全自主」會抱持懷疑，但他強調：
這個 fully autonomous flow 在技術上今天就可行。

真正的 limiter 不是 coding agent 的能力，而是：

你組織的 validation criteria（驗證標準/驗證門檻）。

因此他把投資價值講得非常明確：

  • 這不是讓你變 1.5x、2x 的那種提升
  • 真正的 5x、6x、7x 來自於你今天是否投資在這裡

但他也說這故事有點「不討喜」，因為代表：

  • 你必須投資
  • 這不是 AI 會「魔法般」直接送你的
  • 這是組織的選擇（a choice）

如果你現在就做這個投資

  • 你會進入工程速度（eng velocity）前 1%～ 5% 的組織
  • 你會在領域中超越所有競爭者