Anthropic recommends a git worktree per agent. Your runtime infra makes that a problem.
The New Stack Arjun Iyer
Anthropic now says every AI coding agent should get its own git worktree, running in parallel. Problem: your CI, staging, and databases weren't built for four agents hitting them at once.
Git made branching free two decades ago, but everything downstream of code stayed singular — one CI queue, one staging cluster, one shared database. That gap didn't matter much when a human developer worked one branch at a time. It matters enormously now that Anthropic's own documentation treats a worktree per agent session as the default setup, and teams are running four, six, ten coding agents in parallel, each producing a candidate change in an afternoon.
The numbers back up how fast this has gotten out of hand. Faros AI's telemetry across more than 10,000 developers shows that teams with heavy AI adoption merge 98% more pull requests, while review time has ballooned 91%. Code generation isn't the bottleneck anymore. The bottleneck is the first shared resource a branch touches once it needs to actually run — the seeded database, the staging cluster, the message queue — because a branch nobody can test against real infrastructure is a branch nobody can trust.
What's interesting is that other layers of the stack already solved this exact problem, just under different names. CI figured it out a decade ago with per-branch pipeline runs on shared runners plus build caching. Vercel and Netlify did it for the front end with instant preview deployments. Even the data layer, supposedly the hardest case because databases carry state, cracked it: Neon, PlanetScale, and Xata now spin up copy-on-write database branches in seconds, letting schema changes get tested against production-shaped data instead of a stale fixture.
The runtime is the layer that's still stuck in 2015. Spinning up a full copy of a microservices environment for every agent-generated change is prohibitively expensive, so most teams just don't. But the fix mirrors what already worked everywhere else: keep one shared, continuously-deployed baseline running, deploy only the services a given change touches as a thin ephemeral environment, and route test traffic through those changed services while everything else falls through to the stable baseline. Uber already built this internally with SLATE because staging contention couldn't keep pace with headcount, let alone agent count.
Stitch the layers together — worktree, pipeline, preview, data branch, and now a routed environment branch — and validation stops serializing everything upstream of it. Bitso, a crypto exchange running this pattern with a data branch attached to each environment branch, is proof it's not theoretical. The real audit for any team adopting coding agents is simple: trace one change from worktree to validated and find the first shared resource it queues behind. For most shops today, that's still the runtime.
My take
Anthropic telling everyone to run agents in worktrees without a word about what happens three layers down is peak model-lab thinking — ship the exciting part, let infra teams absorb the pain. The uncomfortable truth is that most orgs' "AI transformation" plans stop at the IDE and never touch staging, so the agents will generate work faster than anyone can validate it, which just relabels the bottleneck rather than removing it. Cheap branching down the whole stack is the boring, unglamorous fix nobody wants to fund, and it'll matter more to whether AI coding actually ships software than any new model release this year.
Read more about this at: The New Stack
