編碼之後的新瓶頸

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

首先，部署成為第一個明顯的瓶頸。寫完代碼後，你還需要等待合適的環境搭建完成、獲得部署權限，或者讓代碼與現有環境中的各種“膠水”協同工作——服務間連接、權限、角色、登錄、數據庫連接、存儲桶權限等等，這個清單很長。針對這個問題，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 交互及其上游/下游風險仍是新領域。讓智能體監控自己構建和部署的東西會有所幫助；而要監控所有在本地、遠程和整個組織中運行的智能體，目前還沒有完美解法，除非你願意被廠商深度綁定。作者表示可能還有其他瓶頸，未來會繼續補充。