[情報] Factory 軟體工廠：從 bug 回報一路做到上線
卡住大家的是 review、重現 bug、補文件、顧測試。
一、講者跟這場在講什麼
Davis Palmie 是 Factory 的技術人員。Factory 是一家做 coding agent 的公司，讓 agent 幫團隊寫碼、審碼、處理工單。
他之前共同創辦 Lumetric，一個給投資團隊用的 agent 平台，走過 Y Combinator，後來被 Factory 收購。再之前他在顧問公司 Slalom 的創新實驗室當工程主管。大企業跟 AI 原生團隊的導入，他兩邊都看過。
這場 18 分鐘，講的是「軟體工廠」：一套 agent 組成的系統，吃進 bug 回報、使用者回饋這類訊號，最後吐出能上線的程式碼。
二、AI 寫程式走過三個階段
一開始是按 Tab 補全、猜下一個字，工程師還穩穩坐在駕駛座。
接著 AI 能整個檔案生出來，工程師變成很挑剔的複製貼上手，輸出還是自己牢牢把關。
再來是跟程式碼綁更緊的 agent，會自己找上下文、呼叫工具、替自己的輸出除錯。當年覺得神奇的自動補全，現在頂多是懷舊回憶。
他說每往上爬一層抽象，工程師都更值錢。下一步是把一群 agent 組成系統，工程師負責把護欄收緊、抓住慢慢跑偏的程式碼、決定優先順序跟方向。
三、主管最常問的四個問題
AI 產出的程式碼比人多的時候，大家一定會問這四件事：
- 預算會不會爆？他舉了幾則新聞標題，像 Uber 的 CTO 到四月就把一年的 AI 預算燒完、微軟收回 Claude Code 授權來省錢。他的答案是不要綁死一家模型，每件事用夠用就好的模型、拿最高的成本效益。他們 CEO 的比喻是：小孩要請代數家教，一定找得到比愛因斯坦便宜的人。
- 怎麼一直用到當下最強的模型？他覺得「押對那匹馬」根本是假選擇，開源模型越來越強，應該依任務挑工具，甚至讓系統自動分派。
- 工程師會怎樣？產品跟工程的界線越來越模糊。工程師會去打造、維護那套產出程式碼的系統，替軟體工廠定大方向。
- 組織會怎樣？團隊邊界也在糊掉，上下文要能跨團隊流通，資訊不能各自鎖住。對人是這樣，對 agent 更是。每個團隊都要一起扛軟體工廠的幾根柱子。
四、寫程式本來就是最簡單的一段
他請大家回頭看自己的工程數據：PR 等 review 的中位數是多久？重現一個使用者回報的 bug、除錯要多久？
文件誰在每個 PR 之後更新？每次策略會議完誰去改？測試誰在顧？測試、工程、產品團隊常常像分住在不同大陸。
DORA 是業界常拿來衡量交付速度的一組指標。拿裡面從寫完碼到上線的時間來看，他賭這段遠比真正改程式的時間長。
現在大家缺的是把這些環節接在一起。文件會過期、死碼一直留著、團隊之間溝通隔好幾層，人已經很痛，agent 會更痛。所以蓋工廠的第一件事，是讓 agent 能跨過這些服務，讀懂組織裡的眉角。
五、軟體工廠長怎樣，從哪開始
軟體工廠是一套從輸入訊號一路做到上線部署的 agent 系統。agent 的工作不只寫碼，還接客服、產品、工程、部署維運這些角色。
它要能分流事故、擬計畫、建立跟更新文件、實際執行程式、review、測試、推出去，最後盯著這次發版。
工作量很大，他建議別一次全包。一來太重，二來團隊沒時間建立對系統的信任。
先挑一件範圍小、好驗證的事，例如事故分流。Sentry 是抓線上錯誤的監控服務，可以讓 agent 讀它的告警，拉 trace 跟其他上下文，整理好貼到 Slack，最後由工程師看過再決定怎麼做。
agent 給的正確診斷越來越多，團隊自然會開始信任、也搞懂這一塊。每一步都要有人負責、有人盯，才考慮讓流程自己繞圈。等系統的輸出能接回輸入訊號，組織就能自己越變越好。
六、工廠要守的三個原則
- 不綁模型。不同模型擅長的事不一樣，成本效益也差很多。他們發現在 code review 上，GPT-5.2 能做到跟最新 Opus 模型一樣的表現，價格只要一半；改看開源模型，成本可以再便宜 10 到 30 倍。不綁單一實驗室，就能在速度、效果、成本之間挑最划算的那條線。
- 部署自己作主。不該為了塞進 AI 的部署方式去讓步資安架構或公司政策。Factory 從全代管、自帶機器到完全斷網的環境都支援。
- 接進整個開發流程。文件改了程式碼要跟著改，反過來也一樣；規劃目標要直接決定測什麼，不管策略、產品、工程、測試之間隔了幾層溝通。
他說每根柱子都撐著整座工廠，一根弱，整個系統就弱。
七、實際長什麼樣：從 O(N) 到 O(1)
在 AI 原生的組織裡，他們常看到很多小組慢慢合併、逐步自動化，收在同一座工廠底下。常見的工作有：
- 分流進來的訊號，例如 Sentry 告警，值班的人還沒接起 page，agent 已經先診斷完
- 主動做資安測試，掃外洩的金鑰跟漏洞
- 寫測試、顧測試，抓出變得脆弱或用不到的測試
- 讓文件跟程式碼、跟各種會議頻道保持同步
- 老本行：審程式、在 PR 留評論、推出新版、監看發版
agent 做這些事的時候，工程師的工作變成回應、做判斷、用 AI 學得會的方式修正它。每個小組的改進都會傳到其他小組，一組變好，整個系統跟著變好。
公司越大越分散，管團隊的痛就跟團隊數一起線性增加。他說工廠保守估計能把這件事從 O(N) 降到 O(1)：護欄、agent、文件、測試政策、治理規則定一次，全公司一起用，而且每個人都被拉到最高標，不是大家的最低公約數。
agent 能在各個介面之間移動，就能替你守住每個團隊的品質，你也不用一組一組盯。上下文集中在一處，主管也看得到整個開發流程跑得怎樣。
不綁模型能避免被鎖住，agent 也該不綁介面。Factory 的 agent 在遠端機器、CLI、Slack 都叫得到。人跟 agent 用的入口可以不同，底下共用同一套執行框架跟上下文。
八、agent readiness 的八根柱子
他說蓋工廠的過程會把「只有老鳥知道」的潛規則、手動流程跟過時資訊全挖出來，清掉之後 agent 跟工程師都受益。Factory 用八根柱子評估一個 codebase 準備好讓 agent 上工了沒：
- 驗證：有沒有 linter、formatter 這類護欄
- 建置：CI 裡的 build 指令有沒有寫清楚
- 回饋迴圈：單元跟整合測試夠不夠緊
- 文件：有沒有 README、
AGENTS.md這類說明 - 開發環境：能不能乾淨重建，讓 agent 直接用
- 程式碼結構：有沒有模組化、邊界清楚、有規則擋住亂長
- 可觀測性：出問題時多久能查到原因
- 資安：有沒有主動做安全掃描，不用擔心金鑰外洩或漏洞
他的說法是，agent 跟工程師走的是同一條路，把路鋪好，兩邊都受惠。
九、治理、慢慢上，人還是要定方向
看不到的東西管不了，agent 跟工程師都一樣。可以先從 agent readiness 評估做起，但不管怎樣，工程師都要盯 agent 的表現、控管它的行為。Factory 裡每個動作都能稽核，照公司既有的規則走，像依角色給權限、只給最小必要權限。
蓋工廠的團隊要先建立信任跟理解，所以要一步一步上：先把個別柱子自動化，再讓整套系統變成迴圈。執行再精準，也救不了爛設計，從來都救不了。
架構、策略、定方向還是很需要人。工程師不會被取代，只是判斷力跟排優先順序，現在比動手實作的功力更值錢。
agent 不會什麼都搞定，還是會有護欄要收緊、會跑偏的程式碼，人要當工廠裡的驗證關卡。他的比喻是：我們早就不用把打孔卡塞進機器，程式碼現在也不用手寫。團隊定好策略跟風險邊界，剩下交給 agent 執行。
十、看成果，別看 token
程式碼行數跟 token 用量都能灌水，跟成果沒什麼關係。大公司的 token 排行榜只會鼓勵亂花錢，他說這是古德哈特定律的現場版：一旦拿 token 用量當指標，工程師就會去衝 token 用量，這個數字也就沒用了。
比的是誰能把花下去的錢換成最大的成果。Factory 自己喜歡看的指標是：
- 從收到訊號到上線要多久
- 人要出手介入幾次
- 修復時間的中位數
- 程式碼能活多久才被改掉
- 每個 PR 的成本
他把 agent readiness 看成好工程的前置條件，不管最後在系統裡做事的是 agent 還是人。agent 要跟工程師一樣被仔細管：工具、權限分級、review 機制都要有，別直接放進 codebase 讓它亂跑，也別一味把 token 用到滿。使用者不在乎你在 AI 上花多少錢，他們在乎的是軟體工廠帶來的明顯改善。
※ 來源：YouTube／AI Engineer — Davis Palmie《The Software Factory: From Bug Report to Production Code》（AI Engineer World's Fair 2026，San Francisco）；Factory；講者 @davispalmie。逐字稿用開源 Whisper 從原始英文音軌轉寫，再拿 YouTube 原始英文自動字幕對過專有名詞，數字與用詞仍以原片為準。非正式圖文整理；封面取自 YouTube 縮圖，沒有另外擷取簡報畫面。