打造軟體工廠

TL;DR

• 寫程式不是難的部分,是最簡單的部分。企業感受不到「100x 生產力」,是因為只把 AI 塞進整條迴圈中很窄的一段,其餘仍是人驅動的同步工作流。
• 軟體工廠的三個設計主張:model independent(不把工廠押注在單一模型廠商,要把 model layer 商品化才能拿到成本與品質的 Pareto frontier)、你自己是工廠的主權者(支援 on-prem / airgapped)、以及跨所有工作流共用一個 shared agent core,而不是為 code review、incident response 各養一套 agent 架構。
• 阻礙 agent 成功的最大瓶頸是環境,不是模型。最高槓桿的投資是 dev 可重現性、環境乾淨度、linting、type checking、測試品質——也就是「有沒有足夠多的 deterministic verifiable feedback loop 讓 agent 不必問人就能自我收斂」。
• 治理要先於規模化:agent 一定會拿到危險權限,「不是 if 而是 when」。要像對待人一樣建立分層管控,而且要把護欄拉到「比現在大 10 倍的組織」該有的水準(5 人團隊要用 50 人公司的控管)。
• 量測 outcome,不要量測 token:看 cycle time、code shelf life、incident time、bug 數;成本用「每次程式變更的成本」這種類比薪資的方式看。

重點整理

什麼是軟體工廠:讓隱性迴圈顯式化(約 00:53–00:57)

三年半來這個領域的演進:autocomplete → chatbot → agent → software factory。所謂軟體工廠,是把公司裡本來就存在的一條迴圈畫出來:各種訊號流入(客戶回饋、內部 telemetry、主管說「我們要轉向」),被 triage,然後進入 planning,再到寫程式、驗證、shipping、部署,而部署後被監控的軟體又產生新的訊號。

問題在於:這些訊號今天幾乎都是人在腦袋裡分流,從來沒有被顯式表示在任何系統裡;planning 也多半散在 Jira / Notion / Confluence 裡且高度非結構化。所以「這個隱性回饋迴圈在每家做軟體的公司都存在,但幾乎沒有任何地方有它的顯式模型」。

由此他點出為什麼很多公司感受不到 AI 帶來的爆炸性生產力:你只把 AI 用在這條迴圈裡很窄的一段,其餘仍是「我叫機器做一件事,它回傳給我」的同步 autocomplete 式互動。真正該問的是:怎麼設計一個讓訊號一路流到 deployed software 而不需要人介入的系統?(注意:是不需要人「介入」,不是不需要人。)

系統該怎麼設計:三個主張(約 00:57–01:01)

1. Model independent:模型廠商會論證「你必須垂直整合、agent harness 必須跟模型綁在一起」——他說經驗上這明顯不成立。你要把 model layer 聚合並商品化,才拿得到成本與品質的真實 Pareto frontier。
2. 你是工廠的主權者:即使買的是 SaaS,也要能控制它;Factory 提供 on-prem、airgapped 等形式。理由是「你的軟體工廠就是你的公司」,它必須能在任何廠商來來去去之後繼續運作。
3. Shared agent core:軟體工廠要覆蓋產品與工程組織裡的每一個動作——code review、security analysis、testing、documentation、incident response。但如果為每個場景養一套高度特化的 agent 架構,就會掉進一種奇怪的 microservice 化;實際上這些工作流在高層次上都是同一件事:蒐集資訊 → 在電腦系統上行動 → 回報使用者。變的是 context 與 workflow,不是 agent 本身。

大型組織還要處理 governance:一致性、防止 agent 去 drop 一堆資料表、IT ops。他主張這是 agent 平台的責任,並給了一個評估廠商的具體方法:去看它有沒有一頁「enterprise controls / organizational controls」,上面有幾條;如果沒有數以百計的情境,就該再看看別家。他點名 Docker 近期推出的一套 vendor-neutral agent 控制項清單(約 35 條)是不錯的呈現方式。

最大的瓶頸是環境,不是模型(約 01:02–01:04)

他用人類演化打比方:20 萬年前的人跟現在的我們差不多,但今天先進太多——因為我們徹底改造了周遭的環境。同理,你可以等模型變強(它大概會),但改造 codebase 與工程系統才是槓桿最高的事:dev reproducibility、環境乾淨度、linting、type checking、測試品質。

真正的判準是:你的組織裡有沒有足夠多的 deterministic verifiable feedback loop,讓 agent 不必諮詢人類就能成功? 等 code review 來告訴你「這段程式組織得不好」是一回事;有一個確定性訊號直接說出這件事,agent 就能自己 loop、自己驗證直到過關。

至於權限:agent 終究會拿到危險的存取權,「不是 if,而是 when」。所以要像對待人一樣建立分層控管。他的類比是:公司超過 50–75 人之後你會明白,就算 75 個人都極為能幹,總有一天會有人 drop 掉資料庫;引入 agent 等於把組織規模放大 10 倍,護欄也要跟著升級——5 人新創要用 50 人公司的控管,50 人公司要用 500 人的。這些都是既有的軟體開發最佳實務,不必重新發明輪子,只要確保它們被強制套用在 agent 上。

人的新角色與量測(約 01:04–01:08)

人的新工作就是觀察 → 介入 → 迭代改良這座工廠:哪裡缺護欄就補護欄、agent 在哪裡失敗就補 context、更新 agent 遵循的 workflow。他建議去聽晶圓廠或 industry 4.0 真實工廠的分享——那裡有專職的 process control / loop management 角色,專門看「這裡損失了 10% 資源,去修好工廠的那一段」,然後迭代。軟體系統即將照做一遍。

Code review 是最好的第一個案例:建一套系統,讓你有信心把 5% → 10% → 50% → 100% 的 PR 在沒有人工 code review 的情況下合併。這需要什麼樣的系統?他借用自動駕駛的類比(儘管有點黑暗):大家知道當道路死亡率降到跟人類同級、或低一個數量級時,我們就願意讓機器上路。驗證也一樣——你要先定義哪些指標(bug 數、incident、MTTR⋯)達標時,可以讓 review 這一步不需要人在迴圈裡。

量測什麼:cycle time、code shelf life、incident time、bug 數。不要量 token,它給不了什麼資訊或價值;要看成本就看「每次程式變更的成本」「每個 loop / 每週的成本」,用近似看待人類薪資的方式來看。

三個帶走的重點:(1) 投資 agent readiness;(2) govern before you scale——先把治理做好再全公司推廣;(3) 事先想清楚要量測什麼 outcome。

金句

"Coding is just not the hard part. It's basically in fact the easiest part of this problem."(約 00:56)

難的是寫程式周圍的一切;把 AI 只塞進「寫程式」那一格,自然感受不到倍數效應。

"Your software factory is your company. If you build software, you're basically describing the new version of your business."(約 00:59)

因此工廠的主權必須在自己手上,不能綁死在某個廠商身上。

"It's not really a matter of if, but just when."(約 01:03)

指 agent 終將拿到危險權限——所以護欄要現在就建,而且要照大 10 倍的組織規格建。