AI coding agents change the shape of source control load. People commit a few times a day, check out a repository once, and wait for review. Agents can open many branches, trigger many CI runs and each want a fresh checkout. For most teams, git handles this fine. For some, it does not. This guide gives you a way to tell the difference, a ladder of fixes to climb before replacing anything, and the questions to ask if you do consider something new.
The framing comes from two public examples: Anthropic's account of building Scion to replace git in its monorepo, and Cursor's Origin hosting platform. Neither means you should switch. Both are useful because they name the pressure points.
TL;DR
| Question | Short answer |
|---|---|
| Is git wrong for agents? | No. It is right for the vast majority of repositories |
| What breaks first? | Clone and checkout cost, CI fan-out, merge contention, review capacity |
| What do you try first? | Shallow and partial clones, sparse checkout, merge queue, caching |
| When consider more? | When measured bottlenecks remain after those fixes |
| What is the borrowable idea? | Let a service answer repository questions so jobs do not clone everything |
Two models of version control
Distributed. Git is the standard example. Every clone is a full, independent copy. You can commit, branch, diff and read history with no network. This is why git survives host outages and why open-source collaboration works through forks.
Server-centric. The server is authoritative and does heavy work. Anthropic's Scion is described this way: clients are assumed always online, the server answers history and blame queries and creates commits, merges and rebases, and the client keeps a bounded cache and a sparse working copy. Anthropic credits earlier systems such as Google's Piper and Meta's Sapling for the approach.
Neither is better in the abstract. A distributed model buys independence and offline work and pays in clone size. A server-centric model buys scalability for always-online clients and pays in independence and ecosystem.
Why agents change the load
| Behavior | Human pattern | Agent pattern | Source control effect |
|---|---|---|---|
| Checkouts | Once, then pull | Fresh for each task or sandbox | Clone cost multiplies |
| CI | A few runs per change | Many runs, parallel | Fan-out on the host |
| Merges | A few per day per person | Large volume, bursty | Queue and conflict pressure |
| Branches and repos | Few, long-lived | Many, short-lived | Hosting overhead per repo |
| Review | Reads the diff | Needs structured signals | Review becomes the limit |
Anthropic reported merges growing from about 2,500 a day to over 30,000 a day in four months, and about 25 million checkouts a day for CI. That is an extreme case. Your numbers will be smaller, and the same categories apply.
Step 1: measure before you change anything
Collect these for a representative week:
- Median and slowest clone or checkout time in CI and in agent sandboxes.
- Bytes fetched per job, and total bandwidth from your host.
- Merge queue wait time and the share of merges that fail on conflict or stale tests.
- How often jobs fail because a branch drifted from main.
- The share of delivery time spent in version control versus build, test and review.
If version control is a small share of delivery time, stop here. Changing it will not move the result.
Step 2: climb git's own ladder
Each rung is cheap and reversible. Anthropic says it used these tools before building anything new, which is a good sign they work and a fair warning of their limits.
| Rung | What it does | When it helps |
|---|---|---|
| Shallow clone | Fetches only recent history | CI that does not need history |
| Partial clone | Defers fetching file contents | Large repositories with big blobs |
| Sparse checkout | Materializes only needed directories | Monorepos |
| Merge queue | Serializes and tests merges | Frequent conflicts and broken main |
| Caching and mirrors | Serves clones near the job | High CI fan-out |
| Repository service | Answers blame, history and merge-base through an API | Jobs that clone only to ask questions |
The last rung is the most transferable idea from Scion. Many jobs clone a repository only to compute a diff or find a merge base. Giving them an API removes the clone entirely. You can build it on top of git.
Step 3: look at the hosting layer
If agents create very large numbers of small, short-lived repositories, hosting economics can matter. Cursor argues that traditional hosting needs a minimum number of replicas per repository regardless of use, which is wasteful for throwaway repositories, and that consensus-based replication limits how many replicas a huge repository can use. Its Origin platform keeps git for clients and changes storage underneath. Whether that matters to you depends on your repository counts, not on hype.
A hosting-layer change is attractive because clients and workflows stay on git. It is also another vendor and another place your code lives.
Step 4: consider a different model only with strong evidence
A server-centric system is a large commitment. Anthropic's team of seven needed five months to migrate, with a company at the scale of tens of thousands of merges a day. Before considering anything like it, you would need to show that:
- Measured bottlenecks remain after steps 2 and 3.
- Your clients are overwhelmingly online automation, not people working offline.
- You can staff and maintain the system, since you cannot buy Scion.
- You accept losing offline work and some ecosystem tools.
For nearly every team, that bar is not met.
Questions to ask before adopting any new system
- Exit. Can you export full history and move back to git?
- Data. Where is code stored, how long is it retained, and is it used for training?
- Compatibility. Do your CI, code review, editors and security scanners work with it?
- Failure modes. What happens during an outage, and can people still work?
- Identity and access. Does it support per-repository and per-directory permissions you need?
- Operating cost. Who runs it, and what happens when that person leaves?
- Proof. Is there an independent measurement on a workload like yours?
A worked example: sizing your own bottleneck
Suppose your CI runs 2,000 jobs a day and each one clones your repository. If a shallow clone fetches 300 MB, that is about 600 GB of traffic per day before counting developer machines and agent sandboxes. Change the clone to a shallow, sparse checkout that fetches 30 MB and the same jobs move about 60 GB. The numbers are illustrative, not measurements of any real system, but the shape is the point: bytes per job times jobs per day is the quantity that grows when agents arrive, and it is the first thing to shrink.
Anthropic made the same calculation at far larger scale. With roughly 25 million checkouts a day and a working copy over 25 GB compressed, naive git traffic would have been over 600 PB a day. No amount of mirror tuning closes a gap that large, which is why it changed the model. Your gap is probably several orders of magnitude smaller, and git's own tools will close it.
Common mistakes
- Replacing the system before measuring. Teams blame version control for slow delivery when builds or tests dominate.
- Treating every agent task as a long-lived branch. Short tasks need automatic cleanup, or stale branches pile up and confuse queues.
- Cloning to ask a question. If a job only needs the merge base or a blame result, give it an API instead of a repository.
- Ignoring merge contention. More concurrent changes mean more conflicts. Decide whether a pre-merge gate or post-merge testing with fast repair fits your risk level.
- Forgetting people. A system that assumes always-online clients can strand developers who work offline or in restricted networks.
- Skipping the exit plan. Any hosting or version control change should let you export full history back to git.
- Copying a lab's architecture. A company with a team of seven and a five-month migration is not your baseline.
Review is the next bottleneck
Even perfect source control does not decide whether changes are good. Anthropic says its engineers still steer, that agents sometimes violate core constraints, and that reviewers now examine intent rather than every line. It also moved toward post-merge and pre-deploy testing and accepts that concurrent changes can conflict, because fixing conflicts with an agent is often faster than finding them by hand. Plan the human and agent split in review early. Our comparison of Claude Code, Cursor and GitHub Copilot covers the tooling side.
A practical checklist
- Record your baseline numbers for one week.
- Apply shallow clones and a merge queue if you have not.
- Add sparse checkout if you have a monorepo. Our monorepo primer explains why.
- Build or adopt a repository query service for jobs that only need metadata.
- Re-measure. Stop if the numbers are fine.
- Pilot a hosting change only on a contained set of repositories.
- Revisit when your volume grows by an order of magnitude.
Related reading
- Scion vs Git
- Scion vs Git vs Cursor Origin
- Anthropic Replaced Git With Scion
- Cursor Origin: how its git hosting works
- What is git? A beginner's guide
- What are monorepos?
Examples cite Anthropic's October 13, 2026 engineering post and Cursor's Origin write-up. The decision framework itself does not depend on either product.