編碼之後的新瓶頸

這些瓶頸並不新鮮，只是我們過去從未真正觸及它們，而是把它們當作自然力量接受了。如今，當寫程式碼本身變得相對容易後，真正的瓶頸開始轉移到軟體開發流程的其他環節。

首先，部署成為第一個明顯的瓶頸。寫完程式碼後，你還需要等待合適的環境搭建完成、獲得部署許可權，或者讓程式碼與現有環境中的各種“膠水”協同工作——服務間連線、許可權、角色、登入、資料庫連線、儲存桶許可權等等，這個清單很長。針對這個問題，Agent-Owned Accounts（Deploy Environments）模式是一種思路，像 LowKey 這樣的工具已經在嘗試解決它，但大部分團隊還沒有達到這個階段；Cloudflare 的 agent accounts 也可以看到一些雛形，不過仍相對有限。

其次，程式碼評審正在成為新瓶頸。作者認為，AI 智慧體會逐漸承擔越來越多的程式碼評審工作，而人類則更多轉向對整體架構的評審。程式碼提交與衝突也會成為瓶頸。當 1000 個活躍的智慧體每天並行向同一個程式碼庫推送 10000 次提交時，衝突將不可避免。OpenClaw 等專案已經在經歷這種痛苦：智慧體提交 PR，緊接著主分支又合入新提交，需要變基，變基產生衝突，智慧體修復衝突，然後再次提交……如此迴圈往復。作者嘗試用博弈論策略來協調智慧體之間關於何時推送、推送什麼的協商，但這是否是正確方向仍是開放問題。

智慧體還需要理解當前工作的上下文：程式碼庫周圍有什麼、其他倉庫、良好的架構實踐、上下游依賴、公司範圍內被接受或拒絕的工作方式、金鑰、合規要求等。這些資訊本來就在不斷變化，而在大量提交的推動下會變化得更快。Reposwarm 是作者維護的專案，試圖提供不過時的跨倉庫架構上下文；還有很多專案在打造“公司大腦”，但目前的局面仍比較混亂。

測試的重要性也隨之上升。當功能和程式碼幾乎可以免費生成時，對智慧體功能進行驗證就變得至關重要。會編寫優秀測試、並能將測試用於智慧體驗證，能夠顯著加速多個變更的落地。全新程式碼比較容易，但程式碼一旦不斷變化，測試就會越來越關鍵。生成測試本身並不難，難的是教會智慧體生成高質量測試。

規格說明也成了瓶頸。既然寫程式碼變得容易，產品經理就需要更快地產出高質量規格。相關框架包括 Claude 的 superpowers、BMAD、Spec Driven Development（作者提到 kiro 實際上在 AI-IDE 視角下最早提出這個概念）、AI-DLC 2 等。組織仍在學習如何以這種方式運作，這些方法能否真正奏效尚無定論，但早期跡象令人期待；由於這個領域有很多低垂的果實，任何改進可能都是好事。

最後，監控正在成為新瓶頸。如果每個人都能隨意編寫和部署更多程式碼，而智慧體又天生具有“創造性”，那麼監控這些流程和可能隨時生成的新應用就會成為新的壓力點。監控行業已經相當成熟，但監控 LLM 互動及其上游/下游風險仍是新領域。讓智慧體監控自己構建和部署的東西會有所幫助；而要監控所有在本地、遠端和整個組織中執行的智慧體，目前還沒有完美解法，除非你願意被廠商深度繫結。作者表示可能還有其他瓶頸，未來會繼續補充。