Read the Code!
光靠 Harness 不夠：程式碼可維護性是訓練問題
Harness Engineering is not Enough: Why Software Factories Fail — Dex Horthy, HumanLayer
19:17長度
5金句
8名詞
14段落
軟體工廠失敗不是 prompt 技巧不夠，是 RL 訓練無法懲罰壞設計；解法是把事前計畫與程式碼審查找回來。
重點摘要
5 件事
Lights-Off 軟體工廠的裂縫AI 程式碼工具大量導入之後，PR 審查品質下滑、程式碼評論數量暴增、事故率上升，而「持有方式不對」的說法掩蓋了一個更深層的問題。
訓練問題，非技巧問題HumanLayer 在 2025 年 7 月嘗試全關燈工廠，幾個月後遭遇 agent 無法解決的錯誤，才意識到問題根源在於模型訓練——現有 RL 基準只驗測試是否通過，完全無法懲罰可維護性差的程式設計。
模型只關心讓測試過關SWE-bench 等基準使用二元獎勵（測試通過或不通過），導致模型學到用 try-catch 包裹不需要的地方、強制型別轉換等手段讓測試通過，而不是寫出好設計。可維護性的代價要等幾個月後才顯現，根本無法傳回 RL 訓練訊號。
關燈之前先點燈解決方案不是等待更強的模型，而是把程式碼審查加回來，並在事前做好產品評審、系統架構與程式設計，30 分鐘的事前對齊能省下幾小時的審查時間。
垂直切片降低審查負擔用垂直切片規劃實作順序與跨 repo 協調，搭配 call graph 確保各部件契約清晰，讓每次 PR 都成為容易通過的小增量，而非令人痛苦的大量 slop。
時間軸 · 金句在右
14 段 · 時碼連回 YouTube
開場：全面 Lights-Off 的裂縫提出現狀：PR 審查品質下滑、事故率上升，「你只是拿錯了」的說法並不成立。
主流敘事與反證Faros AI 報告顯示，AI 程式碼工具普及後 bug 數量與事故率雙雙攀升，並非只是技巧問題。
核心論點：這是訓練問題任何 harness 工程或迴圈最佳化都無法解決根本的模型訓練缺陷，必須正視可維護性無法被訓練的事實。
02:46
「no amount of harness engineering or loops maxing can solve what is fundamentally a model training issue. That's why we say the harness is not enough.」沒有任何 harness 工程或迴圈最佳化能解決根本上的模型訓練問題，這就是為什麼我們說 harness 不夠
軟體工廠的歷史演進從 1968 年 NATO 的定義，到 2022 年典型流程（規劃、建構、PR、人工審查、上線），再到 agentic 工廠取代建構步驟。
Agentic 工廠加速但瓶頸移位建構變快了，但人工審查仍是瓶頸；關燈工廠把程式碼審查拿掉，是把問題轉移而非解決。
為何關燈工廠行不通HumanLayer 2025 年親身試驗後得出結論：模型無法自主維護程式庫品質，需要一定程度的人工引導。
模型真的變好了嗎有些方面變好了，可維護性沒有；而講者說自己無法證明這點，正是因為沒有衡量程式庫品質的基準。
Claude Code 為何勝出在它之前 Aider、Code Buff 這些 CLI agent 工具集幾乎一樣，差別是第一次由 model lab 拿自家要出貨的 harness 去訓練模型；OpenAI 十一月那場也講同一件事，不握權重的 harness builder 永遠居於劣勢。
60 秒講完 coding agent RL產生一批 trace、依結果打分、把壞行為的機率壓下去；SWE-bench 的任務約 15 分鐘，取自 Redis、JQ、Django 這些開源 repo，獎勵只看測試過不過。
無法懲罰壞設計為了讓測試通過而亂包 try-catch、強制轉型，這套系統沒有辦法懲罰；壞架構的代價要以月與年計算。
12:50
「there's no way in this system that we can penalize it for poor program design or for eroding the maintainability of our systems.」在這套系統中，我們無法懲罰糟糕的程式設計，也無法懲罰對系統可維護性的侵蝕
「the cost function of bad architecture is measured in months and years.」糟糕架構的代價是以月和年來計算的
新一代基準在試什麼Abundant AI 的 Sweep Marathon（400 小時任務，例如把 Excel 的每個功能複製一遍）、Data Curve 的 Deep Sweep、Cognition 的 Frontier Code 跑多 PR 任務並加上判官模型檢查品質規則，但能教會的仍受限於 RL。
解法：把程式碼審查找回來加回程式碼審查，並在事前做產品評審、系統架構、程式設計與垂直切片規劃，用 30 分鐘對齊省去數小時審查時間。
14:55
「30 minutes over here in pre-planning and alignment can save you hours in review.」事前規劃與對齊的 30 分鐘，能替你省下數小時的審查時間
不是 PR 太多，是爛 PR 太多好的 PR 讀起來是享受，一眼就看得出「這就是我們討論過的東西」；就算需要兩成返工，也比一堆沒對齊過的 PR 划算。
17:01
「a good PR is a joy to to review.」一個好的 PR 審查起來是一種享受
結語：工程師面對約束的態度模型有它擅長與不擅長的事，工程師的工作就是在約束下解決問題，而不是否認約束的存在。
名詞與人物
8 個
Dex Horthy講者，HumanLayer 的打造者，講的是如何在複雜程式庫中安全使用 AI coding agent。
HumanLayer講者正在打造的平台，做軟體工廠的基礎建設；講者說軟體品質的驗證工具是接下來要做的東西。
Lights-Off Software Factory完全不讀程式碼、不做人工審查的全自動軟體工廠模式，由 Dentsu Bureau 率先推廣。
SWE-bench主流 coding agent 基準，使用二元獎勵（測試通過/失敗），無法評估程式設計品質。
Shotgun SurgeryMartin Fowler 定義的程式碼壞味道：修改一個功能需要同時更動許多不相關的地方，說明程式庫的模組邊界已崩解。
Sweep MarathonAbundant AI 推出的長任務基準（約 400 小時），嘗試用較複雜的獎勵機制評估程式品質。
Frontier CodeCognition 推出的多 PR 任務基準，加入測試誠信檢查與法官模型評審程式品質。
Vertical Slices垂直切片規劃法，將實作拆成有序的跨系統小增量，確保每次 PR 範圍清晰、易於審查。
延伸
演講裡沒展開的
- 講者說有幾張投影片是跟 Calvin French Owen 借的，對方在 Codex 初版上線時是 MTS；harness 與模型權重共同訓練的論點則出自 OpenAI 團隊十一月那場演講，兩者都沒有給連結。
- Cloudflare 的 Dylan Mulroy 將 call graph 納入規劃流程的做法被講者認為方向正確，演講中僅引用而未展示具體實作細節。
- 講者提到在 AI Engineer Miami 有更詳細討論水平計畫（horizontal plans）問題的演講，本場僅點到為止。
標籤