编码之后的新瓶颈

这些瓶颈并不新鲜，只是我们过去从未真正触及它们，而是把它们当作自然力量接受了。如今，当写代码本身变得相对容易后，真正的瓶颈开始转移到软件开发流程的其他环节。

首先，部署成为第一个明显的瓶颈。写完代码后，你还需要等待合适的环境搭建完成、获得部署权限，或者让代码与现有环境中的各种“胶水”协同工作——服务间连接、权限、角色、登录、数据库连接、存储桶权限等等，这个清单很长。针对这个问题，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 交互及其上游/下游风险仍是新领域。让智能体监控自己构建和部署的东西会有所帮助；而要监控所有在本地、远程和整个组织中运行的智能体，目前还没有完美解法，除非你愿意被厂商深度绑定。作者表示可能还有其他瓶颈，未来会继续补充。