只需正確瞄準大炮

James Shore最近發表了一篇關於AI編碼代理的文章，其核心論點是：你的AI編碼代理必須顯著降低維護成本，而不是僅僅加速代碼生產。他認為，長期生產力受限於維護成本的複合增長，任何只加速生產而不控制維護的代理本質上是債務洗錢操作——讓你今天跳過賬單，卻要永遠償還。

Justin Duke在本文中回應了Shore的觀點。他同意Shore的診斷，即代碼是債務、維護成本會複合增長、快速添加功能而團隊無法消化的代理長期來看是反生產力的。但Duke在Shore即將得出的結論——當前LLM工具總體上是壞的——處停下了腳步。

Duke提出一個實用的框架：“難度評分”。這個想法很簡單：組織中的每個重複性操作都有一定的摩擦，你可以用粗略的成本函數來近似度量。例如，對於發起一個拉取請求，他的版本是：等待測試或CI每十秒加1分；每次工具上下文切換（文檔、儀表板、終端）加5分；每次點擊加1分；每次手動檢查加10分。對於支持工作，版本可能不同：每次分類工單的點擊加5分；每次答案不是簡單的文檔鏈接加10分；每次需要登錄用户賬户加25分；每次用户後續回覆乘以1.25。

具體的權重不重要，關鍵是有了函數後，你可以求導，識別出“壞”的操作，然後逐步減少它們，目標是使分數儘可能低。Duke的經驗表明，LLMs在降低這些分數方面非常出色。在Buttondown 2026年，他將大部分LLM輔助時間花在擠壓內部循環、精簡依賴、將診斷和範圍界定工作交給後台代理上，獲得了超額的回報。

相反，他看到LLMs最有害的部署方式——也是Shore論點最適用的地方——是當工具與代碼庫的關係純粹是疊加時。LLMs非常擅長添加功能，而且更隱蔽的是，它們非常擅長告訴你添加功能是個好主意。Duke多次試圖説服編碼代理不要構建某些東西，但發現這比相反方向更難。他警告，如果搭建一個功能從一週縮短到一下午，答案會傾向於“是”，直到你某天早上醒來發現十六個新端點，卻不知道它們為何存在。

但你可以選擇不這樣使用工具。Duke提供了一個簡單的工作手冊：首先定義關鍵操作的難度分數，並讓團隊討論完善；然後優先處理明顯的低垂果實（通常比預想的多），因為這是內部循環；最後交付改進並重復。

這一切並非LLM特有。Duke指出，維護債務累積的失敗模式早於LLM，也將持續下去。LLM的作用是提供了一個快進按鈕：讓已經在維護債務中失敗的組織失敗得更快，讓有良好評分體系的組織拉大差距。

總之，Duke同意Shore的診斷，但認為治癒方法不是放棄工具，而是將它們指向正確的操作，並牢記：添加代碼是編碼工具能為你做的最昂貴的事情。