為什麼軟體工廠會失敗：工具鏈工程不夠

核心論點是，僅依賴 AI 編碼代理和工具鏈工程無法維持程式碼品質，因為模型對不良設計缺乏懲罰，導致可維護性隨時間惡化。

軟體工廠概念的演變

軟體工廠的概念源於 1968 年的北約會議，該會議同時創造了「軟體工程」這個術語。在 AI 出現之前，典型的工廠涉及人員決定要建什麼，使用類似 Jira 的系統追蹤工作，人類建構和測試，開啟 pull request 進行審查，針對失敗進行迴圈，部署到生產環境，加入監控，並納入使用者回饋。團隊學會前置對齊——花時間在規劃和架構上——以減少重新工作，並將審查時間從小時縮短到分鐘。

為什麼關閉燈光的工廠會崩潰

移除人類審查會創造一個關閉燈光的工廠，起初會加速交付，但最終會產出難以維護的程式碼，導致中斷並需要昂貴的重寫。作者的團隊在 2025 年 7 月嘗試了完全關閉燈光的方法，讓代理處理所有來自工單的小型和中型工作。幾個月後，他們遇到了代理無法解決的棘手問題，網站宕機，使用者憤怒，團隊在花費數週研究代理生成的義大利麵式程式碼後，不得不從頭重寫。

模型無法從當前基準學習可維護性

今天的編碼代理基準僅獎勵測試是否通過，沒有提供架構品質的信號，因此強化學習無法提升可維護性。例如，SWE‑bench Multilingual 會將修補程式評為 1，前提是它修復了回報的問題且不破壞現有測試，但對於到處引入 try‑catch 區塊、惰性類型轉換或其他侵蝕程式碼基礎健康的模式，沒有懲罰。正如作者所指出的，「對於侵蝕程式碼基礎可維護性沒有懲罰」。

評估程式碼品質的新興努力

像 SWE‑Marathon (Abundant AI)、DeepSWE (Datacurve) 和 Frontier Code (Cognition) 這樣的專案嘗試透過多小時任務、突變測試或檢查程式碼品質規則的裁判模型來判斷可維護性。然而，這些評估仍然缺乏一個快速且可靠的甲板（oracle），強化學習無法利用它來大規模改進設計決策。作者觀察到，「如果模型能可靠地分辨好程式碼與壞程式碼，它可能早在一開始就寫出好版本」，但可維護性缺乏快速甲板，因此我們無法在強化學習期間對其給予獎勵。

重新引入人類參與的規劃

為了在不犧牲品質的情況下恢復速度，團隊應該在讓代理編寫程式碼之前，重新投入人力於產品審查、系統架構、程式設計和垂直切片。作者提出四個階段：產品需求（定義使用者痛點與成功）、系統架構（就服務、端點、 schema 達成共識）、程式設計（詳細說明類型、方法簽名、呼叫棧樹、檔案樹差異）、以及垂直切片（構建端到端的追蹤子彈，而不是水平層）。這鏡像了 AI 之前的最佳實踐，但利用 AI 加速每一步，同時讓人類參與設計判斷。

實際槓桿：規劃節省審查時間

花費約三十分鐘在前置設計上，可以將審查時間從小時減少到分鐘，帶來 2‑3× 的淨速度提升，同時保持程式碼健康。作者引用內部數據顯示，一小時的規劃會議可以將審查時間從六小時減少到二十分鐘，因為規格明確的變更對代理來說更容易正確產出，對審查者來說也更容易驗證。

真正的問題是太多壞的 pull request，而不是太多

人們認為的 pull request 過載源自低品質的 AI 生成變更需要重新工作，而非合法工作的數量。正如一位評論者所說，「你沒有太多 PR。你有太多壞的 PR。」優秀的 PR 是審查的樂趣；AI 一次性 PR 常常需要 50 % 的重新工作，對提交者和審查者都造成智力和情感負擔。

將約束論應用於 AI 輔助開發

模型在孤立的編碼任務上表現出色，但在橫切設計決策上掙扎；在這些約束內進行優化意味著尋求規劃、測試和監控的槓桿，同時讓人類參與架構判斷。作者的結尾建議是學好約束，透過與模型合作培養直覺，在約束的範圍內優化系統，尋求槓桿，並閱讀那些该死的程式碼。

社群觀點與反駁

評論者提出了額外因素和替代觀點：

• 一位指出，大型產品仍然需要對每個變更進行人類輸入，而小規模的 AI 自動化實驗在重構、測試和 UI 變更上可以成功。「我們的核心產品根本不適合它們在這個規模……我們有 AI 自動化用於輕量程式碼重構、編寫測試、UI 變更等等，而且它們有效。」 (@pdp)
• another questioned the timeline, arguing that models underwent a step‑change in usefulness around fall 2025/spring 2026, making pre‑that‑period experience less relevant. "Isn't it pretty well‑accepted at this point that the models underwent a step‑change in usefulness around fall 2025/spring 2026?" (@fishtoaster)
• A comment suggested swapping the terms “vertical” and “horizontal” in the author’s description of slicing strategies. "I'd humbly suggest the author look up the definition of ‘vertical’ and ‘horizontal’ and swap their terminology + fix their videos :) " (@bavell)
• Regarding pull‑request UX, one remarked that the GitHub PR page is awful and praised Linear’s basic PR review feature that groups changes by theme and adds commentary. "These days I think there's really no excuse for the awful UX. Linear … put out a basic PR review feature … Immediately, so much mental load has been reduced…" (@rglynn)
• Several users called for better verification and benchmarking, proposing a “MaintainabilityBench” that rewards models for detecting duplication, suggesting new architectural layers, or hoisting type constraints. "Imagine a ‘MaintainabilityBench’ that rewards models which detect code duplication while working on a task and perform some refactor instead of glibly duplicating…" (@cadamsdotcom)
• One commentator emphasized that building software is not just about assigning tickets to AI; human judgment about design choices remains essential. "There are ‘points of view’ that emerge during coding I think. And at some point you as a human have to be like ‘wait… what if we use Redis here’…" (@firasd)
• Another shared a personal success story of running an agentic factory for eight months using guardrails, plan reviews, browser‑based QA, adversarial reviews, unit tests, linters, typecheckers, post‑commit hooks, formal method traces, and explicit engineering principles (functional core, imperative shell, make impossible states impossible, pure functional style). "I haven't hit the wall that the OP talked about… I used a lot of guardrails…" (@iamwil)
• A different view held that the bottleneck lies not in the model but in the harness—observability, rollback, and intent validation. "As coding agents move from demos to production, the bottleneck usually isn't the model but the harness around it: observability, rollback, and intent validation." (@jkwang)
• Finally, some warned against treating AI factories as a "solve‑anything" button, noting that factories still need intent, guardrails, and management, just like any conventional factory. "A software factory isn't a solve anything button (aka god). In a conventional factory, things break and fail. Process machines get polluted. Extruders get jammed. You still need to establish intent, define what you care about, define guardrails, and of course manage the factory." (@rapatel0)

這些社群見解強化了作者的結論：僅靠工具鏈工程不足以維持程式碼品質；即使 AI 加速軟體開發的機械部分，維持可維護性仍需要刻意的人類參與規劃與審查。