讓不切實際的品質工具重獲新生

資料來源#

• Uncle Bob on Software Fundamentals in the Age of AI
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering

摘要#

Robert C. Martin（Uncle Bob on Software Fundamentals in the Age of AI，2026-08-19，practitioner-opinion）在本文集裡，對代理程式究竟具體改變了程式碼品質的哪些面向，提出了最具體的說明，而這並不是多數討論首先會想到的部分。重點不是代理程式寫出的程式碼比較好或比較差，而是他在二十五年前認為正確但負擔不起的兩種品質技術，如今變得負擔得起了，儘管技術本身完全沒有改變。

他提到的兩種技術：

技術	用途	他為何擱置（約 2000 年）
CRAP score	將測試涵蓋率與各函式的圈複雜度合併成一個「這個函式有多糟」的數值	偵測成本低，報告也準確。「我得花老半天逐一檢查那些函式，試著修好它們並重寫測試。」
Mutation testing	翻轉原始碼中的運算子（<→>、==→!=、正負號翻轉）；每次翻轉都應該讓測試套件失敗，若沒有，就是必須消除的「存活突變」	若專案的測試套件要跑四分鐘，數百次突變就得花一整晚。「我不能把它放進一般的建置流程裡。」

兩者都是診斷工具，成本幾乎全落在診斷之後。這項結構特性讓它們不切實際，而代理程式恰好能消除這個障礙。

機制：他的說法#

「這些傢伙速度很快，而且不在乎工作有多枯燥；我叫它們做什麼，它們就會做。所以，為什麼不把 CRAP 跑一遍，檢查你剛做完的所有東西——它會跑 CRAP，接著清理程式碼……為什麼不也跑 mutation testing？也許要花 30 分鐘，而不是一整晚，然後它就會補上所有漏洞，確保每個地方都有測試涵蓋。」

發揮作用的是三項特質，沒有一項是智慧：

1. 速度——一夜的突變測試縮短到大約三十分鐘。
2. 不嫌繁瑣——讓他打退堂鼓的修復佇列，對代理程式而言並不令人厭煩。
3. 在關卡約束下服從指令——這項技術成為循環條件：「你必須持續修改程式碼，直到這個工具說可以為止。」

第三項把報告轉變為執行機制。關於為何他把品質要求放進檢查器，而不是提示詞，請見潛在空間與確定性空間；關於循環本身的形狀，請見迴圈工程。

一般形式#

有意思的主張不在於這兩種工具，而在於一項重新審視的準則：若某項技術因修復成本超出人類耐心而遭擱置，它就值得考慮重新啟用；當初擱置它，並不能說明這項技術是否正確。 Martin 對整場訪談的整體說法正是如此：「這些構想很久以前就很好了。我們只是一直沒有足夠的勞動力，真正把它們做到底。」

本文集裡符合這種模式、但尚未在代理程式勞動力的條件下重新審視的技術，包含窮舉式屬性測試產生、完整程式碼庫的不變條件檢查、系統化故障注入，以及他目前舉的例子——在每個模組邊界執行架構相依規則，而不只管人類有空監督的少數幾處（見代理程式的深度模組）。

並非毫無代價#

他明確指出，這些關卡是以吞吐量換來的，而且即使他還沒找到上限，也確實存在上限：

「顯然總會有做得太多的時候，對吧？最後你會把代理程式拖慢到比人類還慢。到了那一步，你就輸了。」

他自述，在完整關卡組合下，速度優勢約為人類的「兩倍、三倍或四倍」；一項代理程式裸跑五分鐘就能完成的任務，經過關卡後約需一小時。這是重新啟用工具確實付出的代價，而唯一明確提出的停止規則，是不低於人類速度的底線——那是底線，不是最佳值。

這些內容能證明什麼、不能證明什麼#

這是單一實務工作者的說法，沒有量測數據，而且他對自己撰寫的一組工具給予正面評價。它提供的是一項可證偽的結構性主張，也有成本低廉的驗證方式：如果代理程式勞動力讓這些技術重獲新生，那麼 mutation testing 與複雜度關卡的採用率，應該會隨著代理程式採用率上升；這種關聯在 CI 採用時並未出現。此外，通過關卡的循環應該呈現為一項獨立成本，而不是更好的程式碼。目前本文集還沒有任何資料量測這兩者。

這也與量測代理程式測試的結果形成一個有趣的對照。代理程式產生的測試品質發現，代理程式寫的測試涵蓋面廣，卻不太能對準重點——一半改動程式碼的 PR 沒有任何測試變更，而錯誤處理結構有高達 86% 的情況未被測試執行。Mutation testing 正是能抓出這類缺口的工具，因為存活的突變代表有分支未經測試。Martin 的強化階段實際上正是針對那些研究所量測的缺陷提出解方——這個構想獨立提出，從未拿來與那些研究比較。

一位實務工作者工具箱之外的重啟（2026 年 9 月）#

Martin 描述的是一位資深人士重新審視自己早已擁有的工具。Stolze & Strässle（ESEM 2026 SEIP，case-study）訪談五位彼此無關的實務工作者——一位 CTO、一位工程經理、一位團隊主管和兩位資深工程師，任職領域涵蓋企業軟體、公用事業、代理商與工業科技；其中四人獨立描述了相同壓力下的相同變化：AI 產生的程式碼量讓可執行式強制檢查擴大範圍，因為它成了唯一能隨規模擴展的層次。 其中兩人提到擴充既有檢查，以抓出架構違規、程式碼重複、相依性誤用，以及偏離組織實作限制的情形；另兩人描述建置系統成為裁決者，讓違規直接造成建置失敗，而不是一路流到審查者手上。

對經濟效益的看法與 Martin 相同，且出自一位不認識他的人。談到即使放寬自己 monorepo 裡的自動化慣例很容易，他仍決定不放寬時，他說：「只要我能自動做到，對我來說就不花任何成本。……我真的希望嚴格維持這項慣例。」 [P5]。這是本文所述機制以決策規則重新表述——一旦勞動由代理程式負擔，關卡的成本便不再是移除它的理由——也是本文集裡第一個非 Martin 的聲音如此表達。

原始資料並未提供本文提到的特定工具。沒有人提及 mutation testing、CRAP score 或任何複雜度關卡；受訪者描述的是架構符合性與政策檢查，屬於相鄰的重啟，而非同一種重啟。研究也沒有對成本定價：沒有關卡數量、執行時間或修復量。它對一般形式的限制由 P4 說明，而且屬於質性描述——脈絡解讀、架構取捨推理與長期可維護性評估「經常無法自動檢查」，因此可執行的防護措施「分擔了一部分監督工作，但無法取代人類監督」。完整討論見分層監督。

延伸閱讀#

• 分層監督——在本文這位個別實務工作者之外觀察到的重啟：四位彼此無關的實務工作者因 AI 產生大量程式碼的壓力而擴大可執行式強制檢查，並各自得出相同的「不放寬免費關卡」立場，另有一項決定哪些檢查能納入堆疊的晉升規則。兩者相近但不相同——受訪者所說的是架構符合性與政策規則，而非本文提到的突變與複雜度工具

• 強制落實價值，而非紀律——相輔相成的原則：關卡落實的是已捨棄的儀式原本要帶來的價值

• 規格驅動開發成為新瀑布模式——關卡讓廉價且未事先規劃的變更得以安全進行，而不只是成本低廉

• 代理程式程式碼審查的確定性工程——經過量測的相近做法：在審查流程中加入確定性，以及這位實務工作者的說法所非正式補足的「關卡對指令」測試組

• 審查是控制點——控制點從具備技能的審查者，移到能實際執行的判準

• Parallel Agent Orchestration——在他的流程中，這些工具會放在清理與強化階段執行

• Context Window Smart Zone——衰減論證說明了為何應將持久規則放進檢查器，而不是提示詞

• Robert C. Martin（Uncle Bob）——這套實務的提出者；閱讀時也值得考量他的偏見

• 程式碼品質的效益以 Token 計價——勞動面的對應觀點：DHH以 Token 衡量品質，Martin 則以代理程式自身繼續工作的能力衡量

• 代理程式產生的測試品質——量測到的涵蓋率與目標對準落差，而 mutation testing 正是為了填補這個缺口而設計

• 潛在空間與確定性空間——說明這些重新啟用的工具為何應放進檢查器，而非上下文檔案

• 驗證成為新的瓶頸——這是其中一個具體解答：自動化驗證，而不是閱讀差異內容

• Agentic Technical Debt——重新啟用的工具旨在避免的失敗模式

• 代理程式的深度模組——他只部分自動化的架構層級版本

• 迴圈工程——「持續修改程式碼，直到工具說可以」就是循環條件

尚待解答的問題#

• Mutation testing 或複雜度關卡的採用率，是否真的會隨著代理程式採用率變化？還是 Martin 的重啟只是早已擁有這些工具的實務工作者之個人作法？When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering（case-study，五位彼此無關的實務工作者，ESEM 2026 Software Engineering in Practice）於 2026-09-22 提供部分解答，但只回答了「是否為個人作法」這一半。五人之中有四人描述可執行式強制檢查因 AI 產生的程式碼量超出審查能力而擴大範圍，包括擴充檢查來找出架構違規、程式碼重複與相依性誤用，以及由建置系統擔任裁決者；其中一人也獨立於 Martin 表達了這項經濟立場：「只要我能自動做到，對我來說就不花任何成本。……我真的希望嚴格維持這項慣例。」因此，重新啟用工具並非單一實務工作者的習慣。採用率這一半仍未解答，而且研究幾乎沒有觸及：五位受訪者都沒有提及 mutation testing、CRAP score 或複雜度關卡；他們描述的是符合性與政策規則，而非本文所談的高修復成本工具；無論如何，五次訪談都無法證明趨勢。這個問題仍需要母體層級的量測——依代理程式撰寫占比分層，統計儲存庫中 mutation testing 或複雜度關卡的存在情況。
• 關卡疊加的實際上限在哪裡——必須通過的關卡累積到多少個，代理程式相對於人類的吞吐量優勢才會消失？Martin 表示他還沒找到上限。

資料來源#

• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering — Stolze & Strässle（OST Eastern Switzerland UAS / smartive AG，arXiv 2608.26316，2026-08-26，ESEM 2026 SEIP），case-study：§4.3（可執行防護措施擴大範圍、由建置系統擔任裁決者、P5 的 monorepo 立場與 P4 的限制）以及 §5.6 Pattern 1（將反覆出現的審查發現升級為 linting 規則）。五次訪談，沒有量測——證據說明見分層監督
• Uncle Bob on Software Fundamentals in the Age of AI — Robert C. Martin 與 Matt Pocock，2026-08-19，practitioner-opinion