Agents are making Git’s bottlenecks impossible to ignore
AI agents are generating Claude Code at a pace that is exposing fundamental bottlenecks in conventional source control. The tension is clear: while agents can generate changes rapidly, the human-centric workflows for coordination, testing, and review are struggling to keep up.
Consider the scale: Anthropic reported daily Claude Claude Code changes skyrocketing from approximately 2,500 to over 30,000 in just four months. OpenAI’s monorepo reliability sometimes dipped below 90% as its agents pushed changes. These are extreme cases, but they highlight a systemic challenge.
Even at a smaller scale, developers using local agents face similar coordination problems. Agents sharing one working directory can overwrite files or disrupt each other’s tests, leading to more time spent resolving conflicts than writing new Claude Code.
The infrastructure problems at Anthropic and OpenAI are massive, yet the underlying coordination problem is familiar to anyone running multiple coding agents on the same project. The core issue is that Git, designed for human developers working primarily offline, struggles with the constant, high-volume, and parallel demands of AI.
OpenAI kept Git—and rebuilt what was behind it
OpenAI took an opposite approach to Anthropic, rebuilding the backend while keeping Git’s familiar interface. Developers continue using standard git push and git fetch commands. This system, called Pando, is a custom, high-concurrency backend written in Rust, designed to scale with AI agent demands.
The bottleneck was coordinating simultaneous updates across numerous branches. Pando resolves this by handling updates to different branches immediately, replacing monolithic ref locking with independent ref coordination. This allows agents to push to distinct branches concurrently, eliminating serialized bottlenecks that previously slowed all activity.
Pando also caches Git pack files, preventing the server from regenerating identical data repeatedly for common CI job requests. This efficiency is critical as the system now serves almost a petabyte of Git data daily.
OpenAI reports impressive results: median push latency fell by nearly 80%, making workflows significantly faster. The trade-off is that reads across multiple branches may not present one perfectly synchronized view of the repository. Pando went from kickoff to production in approximately 10 weeks, with its core designed by one engineer and largely implemented by Claude Claude Code agents.
Anthropic asked whether agents need Git at all
Anthropic, on the other hand, questioned Git's fundamental assumptions. Its team asked whether an offline-first, distributed version control system remained optimal when most clients were always-online AI agents and automated jobs. This led to Scion, a complete replacement for Git.
Anthropic's main branch history was approaching 100 GB, with compressed working copies exceeding 25 GB. Its CI infrastructure performed roughly 25 million checkouts daily. These pressures highlighted the growing overhead of deep local repositories and Git’s decentralized model.
Scion moved commits, merges, and history operations to a server-side system. Clients request only the files and data they need, eliminating the need for large local repositories. This architecture yielded significant efficiency gains.
Anthropic reported Scion uses around 200 times less CPU and memory than its previous Git mirroring infrastructure. Some checkouts that once took minutes now complete in seconds, and CI recovered approximately 25% of its CPU capacity. To fully leverage Scion, Anthropic rebuilt its Claude Code review, Claude Code search, and CI tooling. For further technical details, see Redesigning source control at Anthropic. Scion is not a general Git replacement, but a specialized solution for Anthropic's unique agent-driven workload.
Enjoying this? Get one like it in your inbox each morning.
one email a day · unsubscribe in two clicks · no third-party tracking
Your agents need worktrees, not a new source-control system
Pando and Scion represent diverging bets. OpenAI prioritizes Git compatibility, rebuilding the backend to handle petabyte-scale data and 30,000 daily changes without altering developer workflows. Anthropic’s Scion, conversely, is a clean-slate system tailored to its internal agent workloads, discarding Git’s offline-first assumptions for an always-online, server-authoritative model.
Neither system is available for general use, and their impressive internal benchmarks (e.g., Scion’s 200x CPU/memory efficiency or Pando’s 80% push latency reduction) do not translate to laptop-scale gains. For most teams, Git remains robust. The immediate solution for local agent conflicts is git worktree add <path> <branch>. This command provides each agent with an isolated working directory and branch, preventing concurrent edits from colliding.
While worktrees mitigate local workspace collisions, they do not eliminate all merge conflicts. To scale agent-driven development, consider:
- Using sparse checkouts for large repositories
- Caching dependencies
- Avoiding duplicate CI jobs
- Running relevant tests safely
As Claude Claude Code and other agents accelerate Claude Code generation, the next bottleneck will inevitably shift from source control to human review and automated validation processes.
Frequently Asked Questions
Why are AI coding agents creating problems for Git?
Agents can make and push changes in parallel at high volume, increasing contention, checkout load, and the work required to review and test changes.
What is the difference between OpenAI Pando and Anthropic Scion?
Pando rebuilds Git’s backend while keeping Git workflows. Scion replaces Git with a server-centric system designed for Anthropic’s agent-heavy workload.
Can developers use Pando or Scion today?
No. Both are internal systems, not tools teams can install and adopt as replacements for Git.
How can I stop multiple coding agents from conflicting?
Give each agent its own Git worktree and branch, then review and merge the changes. Worktrees isolate working files but do not prevent later merge conflicts.