Why AI Coding Agents Change Source Control: Worktrees, Pando, and Scion
Running several coding agents can expose a problem before any code reaches a server: they may edit the same working files. At a larger scale, independent agents also produce more branches, pushes, checkouts, and build jobs. Making code generation faster increases the work that source control and delivery systems must absorb.
OpenAI and Anthropic have responded to that pressure differently. OpenAI built Pando, a backend that preserves Git workflows. Anthropic built Scion, a new source-control system centered on connected clients and server-side operations. Their decisions illustrate a useful architectural question: which existing assumptions are worth keeping, and which have become expensive?
For most development teams, the immediate implications are closer to home. Git worktrees can separate agent sessions, sparse checkouts can reduce working-directory scope, and continuous integration needs to avoid multiplying unnecessary work. Local isolation, repository throughput, and code validation solve different problems, even when all three become visible during the same agent-driven project.
Why parallel agents create several kinds of contention
A repository is more than a directory containing source files. A development workflow also includes a checked-out branch, an index of staged changes, a history database, remote references, and services that respond to updates. Parallel work can collide at any of those layers.
Consider two agents assigned to an authentication service. One changes token handling while another fixes a failing test. If both run in the same working directory, the second agent may read the first agent's unfinished implementation. A test result can then describe a mixture of two tasks, making it difficult to determine which change caused the failure.
Putting those agents in separate directories addresses that immediate interference. It does not prevent both from later changing the same function on their respective branches. That conflict belongs to integration, when the changes are reviewed and combined.
Server contention is different again. Thousands of agents may work on unrelated branches but still share a repository service. A backend that serializes unrelated updates can make all those clients wait on a common coordination point. A busy build fleet can simultaneously request the same source revision, adding read pressure even when no developer is waiting to push.
These distinctions explain why one remedy is rarely sufficient. Adding worktrees does not increase remote-server capacity. Replacing a server does not protect a shared local checkout. Faster checkouts do not establish that the code being checked out is correct.
How worktrees separate working files without duplicating the project
Git worktrees let one repository have multiple checked-out working directories. Each linked worktree can use a different branch and has its own working files and index, while sharing much of the repository's underlying object storage.
A feature agent can therefore operate in agent-a, while another agent operates in agent-b. The paths become meaningful boundaries for ordinary file edits: saving a file in one worktree does not replace the corresponding working file in the other.
The important information is the directory and branch associated with each session. Two terminals are not sufficient isolation if they both point at the same checkout. Conversely, two worktrees can remain useful even when both agents use the same model or command-line application.
An illustrative worktree definition creates a branch and its working directory together:
Here, -b agent/feature-a names the new branch, ../agent-a identifies its working directory, and main supplies the starting revision. A second independent branch can have its own directory:
These commands explain the arrangement; they are not a requirement to restructure an existing repository. Branch names, starting revisions, and directory locations depend on the project. Git can report the current associations through its worktree listing interface:
Worktrees still share repository-level resources. They also do not isolate a database, a cache, a service account, or a listening port. Two application instances may have perfectly separate source trees and still overwrite the same test database. Effective parallel development requires understanding both filesystem isolation and external state.
Integration also remains explicit. An agent's changes need review and appropriate tests before being merged. Removing its worktree afterward is cleanup, not acceptance of the branch. A workspace interface can make those operations easier to see, but it cannot establish correctness on the developer's behalf.
Pando preserves Git while changing how a server handles demand
OpenAI's Pando engineering report describes a service designed for many clients pushing to different branches and a large fleet fetching source. The company reports nearly fivefold lower median push latency and nearly a petabyte of Git data delivered daily. These are production observations from OpenAI's infrastructure, not measurements of an ordinary local repository.
The shorter latency bar represents the reported push operation, rather than the duration of a complete development task.
Pando keeps the Git client and protocol as the developer-facing interface. That choice matters because version control connects to editors, automation, deployment scripts, and existing developer knowledge. Preserving the interface can reduce migration work even when the service behind it changes substantially.
Two architectural ideas are central to the account: independent branches should avoid unnecessary shared coordination, and repeated readers should be able to reuse prepared repository data. Together, those ideas target both the write side and the read side of an agent-heavy workload.
Independent branches and consistency
A branch is a reference to a commit. Updating one branch does not inherently require changing every other reference in the repository. However, providing a single synchronized view of all references can introduce coordination across otherwise unrelated work.
Pando relaxes that repository-wide requirement while retaining ordered updates to individual references. A client reading multiple branches should not assume that the combined result represents one globally synchronized instant. That is a consistency trade-off, not a claim that commits randomly lose their contents.
The consequence matters most for automation that reads several moving branch tips and treats them as one coordinated state. Pinning the intended commit identities gives a job a more precise input than repeatedly asking for whatever a branch name happens to indicate. A build artifact should identify the exact source revision it represents regardless of which repository service is in use.
Reusing data requested by many readers
Git transfers repository objects in compressed bundles called packfiles. Generating a tailored response for every client can consume server resources, particularly when a large number of build jobs want closely related code.
Pando emphasizes reusing stored packs instead of repeatedly constructing equivalent responses. This illustrates a broader caching principle: immutable data is easier to share safely than a changing piece of state. If many jobs request identical bytes, preparing those bytes once can avoid redundant work.
The resulting system still has operational limits. Clients, network links, storage, and cache behavior all contribute to observed performance. Retaining Git compatibility also means the architecture must accommodate the protocol's expectations rather than freely redesign every interaction.
Scion changes the relationship between client and server
Anthropic's Scion report starts from a different assumption: most clients are online agents and automated jobs, so they do not need a fully capable offline repository on every machine. The company reports growth from roughly 2,500 merged changes per day in May 2026 to more than 30,000 in September.
Scion moves source-control operations toward the service. Rather than requiring each client to maintain the same kind of local history machinery, it lets clients obtain the files and information they need. This makes connectivity part of the system's design rather than an optional convenience.
The connected-client assumption explains why server-side operations fit this workload. The clients already depend on a live service to perform their jobs.
A useful way to understand the difference is to consider a job that only needs a diff. Producing that diff should not necessarily require constructing a full working directory and maintaining repository history locally. A service interface can answer the question directly, allowing the job to avoid work unrelated to its actual purpose.
The same principle applies when files are needed. Materializing a small portion of a large repository can reduce the amount of data handled by a short-lived job. However, this changes what the client can do independently. Network availability and service reliability become important dependencies for operations that a self-contained repository might otherwise perform locally.
What the efficiency numbers measure
Anthropic reports that Scion's source-control infrastructure required about 200 times less CPU and memory than its previous Git mirroring infrastructure. CPU refers to central processing unit resources. It also reports faster checkouts and a 25% CPU-capacity improvement for its continuous integration (CI) fleet.
The denominator is essential. The 200-fold figure describes an infrastructure footprint against Anthropic's previous mirrors. It does not mean a developer's local git status becomes 200 times faster or that Scion would deliver the same saving for a small repository.
The operational benefit also has a migration cost. Changing the source-control model affects code review, search, automation, permissions, and the interfaces other tools rely on. An organization considering such a change must account for the surrounding system, not only the source-storage component.
What the two approaches reveal about architectural trade-offs
Pando and Scion illustrate different answers to a shared scaling pressure. One preserves the existing client contract while changing the backend. The other changes more of the contract to fit a predominantly connected workload.
The comparison is about design choices rather than a benchmark ranking. A latency reduction and a resource-footprint reduction are different measurements. They cannot be divided into each other to decide which system is faster.
| Question | What it helps evaluate |
|---|---|
| Where does work happen? | The balance between local capability and service dependency |
| Which operations contend? | Whether unrelated work waits on shared state |
| Which bytes can be reused? | Opportunities to reduce repeated computation and transfer |
| What must clients understand? | The cost of preserving or changing established interfaces |
| What is the measured baseline? | Whether a reported gain applies to a particular deployment |
Neither system is presented here as an off-the-shelf replacement to install. Their value as case studies is in revealing the assumptions behind the results. A specialized internal system can be the right decision for its operator without becoming the default choice for the wider developer ecosystem.
Why CI and review remain separate scaling problems
Source-control throughput is only one part of delivering software. A faster push can start a build earlier, but it does not reduce the number of tests that build needs. Increasing the number of branches can also increase the amount of duplicated automation.
Suppose a team moves from one active change per developer to several agent-generated changes. Each push may trigger dependency installation, compilation, tests, analysis, and artifact generation. Even with fast source retrieval, those jobs can compete for the same runners or external services.
Caching dependencies and build outputs can reduce repeated work when the cache key correctly represents the inputs. Canceling obsolete jobs can prevent an earlier revision from consuming resources after a newer one supersedes it. Selective testing can help too, but only when the dependency model reliably identifies what a change can affect.
The repeated lanes make duplicated build work visible. Faster source retrieval helps each lane, while caching and cancellation address work repeated across lanes.
Review has its own capacity limits. More generated code means more behavior to understand, not merely more lines to scan. Small changes with a clear purpose are easier to evaluate than a large collection of unrelated edits, even when both were cheap to generate. An agent can help investigate a change without becoming the authority that accepts its own output.
These are general workflow implications rather than performance claims about either internal system. The useful question is where elapsed time and failures accumulate in the actual delivery process. Without that evidence, a source-control migration can move the bottleneck while leaving the overall outcome unchanged.
Where ordinary Git still fits
Most teams do not need the infrastructure scale described by either company. Git's local operations, ecosystem, and established workflows remain useful. A small repository with occasional pushes has little in common with a fleet performing millions of checkouts per day.
Sparse checkout provides a narrower working tree when only part of a large project is relevant. It addresses which tracked files are materialized, rather than promising to eliminate all history or network costs. That distinction prevents confusing it with every other form of partial repository access.
An illustrative declaration selects the paths relevant to an application and its shared dependency:
The paths represent a hypothetical repository layout. Their usefulness depends on the build system and dependency structure. Omitting directories blindly can make a checkout smaller while breaking the tools that need those files.
Worktrees and sparse checkouts therefore complement measurement rather than replace it. One separates concurrent working files; the other narrows what appears in a working tree. Backend capacity, build efficiency, and review quality still need their own explanations.
Final thoughts
AI coding agents increase pressure across the development pipeline, from local working directories to shared source-control services. Pando shows how a backend can change while preserving Git workflows. Scion shows what becomes possible when connected clients and server-side operations guide a broader redesign.
The reported gains are specific to the systems and workloads that produced them. They are evidence of useful architectural choices, not proof that every repository needs a replacement or that one system wins a universal performance contest.
For ordinary agent workflows, separating working files and understanding the delivery bottleneck are immediately useful priorities. Worktrees can reduce local interference, while deliberate CI and review design help ensure that faster code generation produces dependable changes rather than a larger queue of unfinished work.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.