Anthropic建议每个代理使用一个git工作树。但你的运行时基础设施让这成为问题。
内容提要
本文探讨AI编码代理并行开发中的瓶颈：代码分支虽廉价，但CI、数据库、运行环境等下游共享资源无法支撑多分支并行。解决方案是“分支式开发”，让每层都支持廉价分支，如数据库分支、预览部署、环境沙箱，实现端到端验证，提升开发效率。
延伸解读
瓶颈不在代码生成，而在共享资源
文章指出，AI编码代理让并行开发成为常态，但代码层以下的基础设施（如CI、数据库、运行环境）仍是共享的，导致多个分支在等待这些资源时形成队列。代理在等待时可能闲置或基于过时视图工作，造成返工。因此，真正的瓶颈是第一个被触碰的共享资源，而非代码生成或审查能力。
分支式开发：各层都需廉价分支
解决思路是将git的分支理念推广到每一层：CI已有按分支的流水线，前端有预览部署，数据库有分支（如Neon），运行时则通过环境分支和请求路由实现。这些机制共享底层资源，只隔离变更部分，使得每个变更都能端到端验证，而无需复制整个环境。
运行时是多数团队的短板
文章建议通过审计找出第一个让变更等待的共享层，对多数团队而言是运行时。Uber的SLATE和Bitso的实践表明，运行时分支可行且有效。若运行时无法分支，代理的并行优势会被下游队列抵消，因此应优先解决该层的分支能力。
Q&A
为什么说代码分支在AI代理并行开发中不再够用？
因为代码分支虽然廉价，但下游的CI、数据库、运行环境等共享资源无法支撑多分支并行，导致分支在代码层以下无法继续延伸，成为瓶颈。
什么是分支式开发（branch-based development）？
分支式开发是指每一层技术栈都提供廉价、即时、可丢弃的分支原语，让变更可以端到端存在，而不必复制未修改的部分。它借鉴git的机制：共享不变的部分，只隔离变更的部分。
数据库分支是如何实现的？为什么说它打破了传统观念？
数据库分支通过写时复制（copy-on-write）技术，在共享存储页上创建视图，几秒内即可完成，无论数据库多大。它打破了数据库有状态无法分支的传统观念，使得模式迁移和风险数据变更可以在生产形状的数据上验证。
微服务运行时环境如何实现分支？
微服务运行时环境通过共享一个持续部署的稳定版本作为主环境，为每个变更只部署受影响的服务作为轻量级临时环境，并通过请求标签路由测试流量，使请求经过变更服务，其余流量回落到共享稳定版本。这样环境分支的成本与变更服务成本相当。
Uber的SLATE系统解决了什么问题？
Uber的SLATE系统为每个开发者提供临时环境，路由到共享的生产级依赖，解决了因开发者数量增长而导致的staging环境争用问题。
Bitso公司是如何组合使用环境分支和数据库分支的？
Bitso是一家拥有250多名工程师的加密货币交易所，它为每个变更配对使用环境分支和数据库分支，使运行时变更和数据变更一起流动，共享staging环境不再成为关键路径。
如何审计自己的开发流程，找出瓶颈所在？
审计方法很简单：跟踪一个变更从工作树到验证通过的全过程，记录它在哪一层第一次等待共享资源。那个位置就是你的技术栈停止分支的地方。对于大多数团队，答案通常是运行时环境。
为什么说“如果状态最多的层都能秒级分支，那么无状态从来不是真正的需求”？
这句话的意思是，数据库作为状态最多的层，都能通过写时复制实现秒级分支，那么其他层如果还没有分支能力，就不是因为技术限制，而是因为选择不去实现。因此，无状态并不是分支的前提条件。
