The CI Bottleneck From AI Coding: Why Anthropic, Cursor, and GitHub Are Rebuilding the Pipeline

AI coding agents have moved the bottleneck in software delivery. Writing code is now fast. Source control, CI, and merge queues were built for human volume, and they are now the slow part. Anthropic says it directly: "The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI" (Anthropic).

The largest teams are rebuilding these systems. Anthropic replaced Git in its monorepo, Cursor built a new Git storage layer, and GitHub more than doubled its capacity in four months. Most teams do not need to go that far. Linear shows that runners, toolchain, gate jobs, and setup per shard come first.

The key numbers

Sources: Anthropic, GitHub Octoverse, Cursor, Linear. GitHub's years run from October 1 to September 30.

Why agents overload the pipeline

A human developer opens a few pull requests a day. An engineer at Anthropic often runs 10 to 15 Claude agents in parallel (The Pragmatic Engineer). Each agent opens pull requests, and each pull request starts CI. The work grows with the number of agents, not with the number of people.

GitHub's 2026 Octoverse data shows the same change across the whole platform. Developers pushed code 17.9 billion times in 12 months, more than in 2024 and 2025 combined. Agents started about 110 million pull requests in September 2026 alone, about six times the March volume. Repositories created this year with an agent configuration file had eight times the commits of new repositories without one (GitHub).

Agents also write tests, so each CI run gets longer. Linear says agents now write most of its tests. The team adds about 2,000 tests a week (Linear). More runs, and longer runs, multiply each other.

The load also creates more of itself. Anthropic notes that "every bottleneck we remove immediately leads to a further increase" in the code it produces. A faster pipeline lets agents ship more, which then loads the pipeline again.

Four layers, four kinds of failure

The pressure lands on four layers. Each layer fails in a different way.

A fifth layer sits outside CI but has the same problem. Each cloud agent needs a working copy of the repository with dependencies installed. Cursor's answer for that layer is in the section on setup cost below.

The platform layer: GitHub at agent scale

GitHub carries most of this load for most companies. In its May 2026 availability report, GitHub wrote that its "traffic is growing rapidly, driven in large part by AI-assisted and agentic development workflows." It also said, "We've more than doubled our effective capacity in four months" (GitHub).

The same report lists nine incidents in May. Two show how agents and CI now share one failure domain:

• On May 15, a failover problem made 42% of Actions runs fail at peak. Copilot cloud services were also affected.
• On May 26, an automated system suspended the account that Actions uses. All newly queued runs failed for about 96 minutes. Copilot code review and the Copilot coding agent also stopped.

GitHub's agents run on Actions. When Actions fails, the agents and the checks on their work stop at the same time. A team that depends on hosted agents and hosted CI should plan for both to fail together.

The source control layer: Anthropic and Cursor

Git was designed for developers who work offline and sync from time to time. Agents and CI jobs are always online, and there are many more of them. Two companies have now built new storage for this case.

Anthropic: Scion

Anthropic's monorepo has almost 100 GB of history on the main branch. A compressed working copy is more than 25 GB. CI makes about 25 million checkouts a day. Anthropic estimates that naive Git fetches would move more than 600 PB a day.

Anthropic first ran several hundred internal Git mirrors. The mirrors "bought us time", but they got harder to operate as the merge rate rose. Repository snapshots drifted further from main between refreshes.

A team of seven built Scion and moved the full monorepo off Git in five months. During that time, daily merges grew about 10x. The design rules are:

1. The server answers history, blame, merge, and rebase queries. Clients keep only a bounded local cache.
2. Tools and CI jobs query the repository through an API. Many jobs need no local checkout at all.
3. Checkouts are sparse and virtual. Files appear on disk only when a job reads them.
4. All data is content-addressed, so cached data never goes out of date. Each cache tier has a hit rate above 99%.

The results: the infrastructure uses about 200x less CPU and memory than the Git mirrors did. Checkouts take seconds instead of minutes. CI alone gained 25% of its CPU capacity (Anthropic).

Anthropic credits earlier work at Google (Piper) and Meta (Sapling). It says Meta's Mononoke server "pioneered many of the techniques we use in Scion." Scion is not open source.

Cursor: Continuity and Origin

Cursor took a different path. It kept Git as the client protocol and rebuilt the storage under it. Origin is Cursor's Git hosting platform. It runs on a storage system called Continuity (Cursor).

Continuity stores each push as an entry in a write-ahead log in S3-compatible object storage. A write-ahead log is an ordered record of every change, written before the change is applied. Each server keeps a normal Git repository on local disk as a cache. Cursor says, "We never acknowledge a push until it has been fully persisted to the WAL."

Cursor names a CI problem that this design fixes. With eventual consistency, a CI runner can fail to find the commit it should test. Continuity gives fully consistent reads on any replica. In Cursor's tests, one cluster took 120 pushes a second on S3 Standard and more than 300 on S3 Express One Zone. Reads scaled in a straight line up to 100 replicas.

What the two designs share

Both designs assume that clients stay online. Both move the source of truth into managed storage and treat local copies as cache. Both treat CI, not people, as the main reader.

The merge queue layer: drop the global lock

A merge queue tests each change against the latest main branch before it merges. Most queues hold one global lock on the repository. Only one change can merge at a time, so the queue limits how many changes merge per hour.

Anthropic found that it could not keep a global lock at 30,000 merges a day. It now relies on automated tests after merge and before deploy. Two concurrent changes can conflict. Anthropic says Claude "can typically fix these conflicts faster than humans can even identify them" (Anthropic).

This is a trade. Main can be broken for a short time between a bad merge and its fix. Pre-deploy tests stop the broken code before it reaches users. A team can make this trade only if three things are true:

• Its pre-deploy tests are strong enough to block a bad release.
• An agent or a person fixes a broken main within minutes.
• Its release process can wait for a green build.

If any of these is false, keep the merge queue and make each run in the queue shorter. The CI fixes below do that.

The CI layer: what Linear changed first

Linear's test suites grew almost 4x in 2026. PR wait time still fell from more than 6 minutes to just over 5. Runner time per test fell by about half. Linear estimates that today's suite would take about 11 minutes on the old pipeline (Linear). The rework kept CI flat while its work grew almost 4x.

Linear made the cheap changes first:

The faster runners had a cost. They sit outside GitHub's network, so checkout got slower and sometimes hung. Linear wrote its own checkout step with retries, a stall timeout of about 30 seconds, and a persistent Git mirror on disk. This is the same checkout problem that Anthropic and Cursor solved at a larger scale.

Why gate jobs cost more than their size

The critical path is the longest chain of jobs that must run one after another. PR wait time can never be shorter than this chain. A gate job is a short job that other jobs wait for, such as change detection. At Linear, "None of the eight API test shards can start until they finish."

A worked example with Linear's change-detection numbers, if that job sits in front of all eight shards:

1. The median run fell from 26 to 8 seconds, a cut of 18 seconds.
2. The job runs once per PR, so it saves only 18 seconds of runner time.
3. All eight shards start 18 seconds earlier.
4. Each developer waits 18 seconds less, about 6% of a 5-minute wait.

A second saved in a serial step is worth more than a second saved in one parallel shard.

Setup cost per shard, and per agent

Each shard repeats checkout, install, and database setup. Linear states the rule: "doubling the shard count also doubles the workflow time spent on setup." Linear cut setup per shard from 110-140 seconds to 67-73 seconds before it went from 4 to 8 shards. With 4 shards, total setup was 8.3 minutes. With 8 shards after the work, it was 7.5 minutes.

One result is not obvious. A cached node_modules took about 28 seconds to restore. A filtered install took about 7.5 seconds. The cache was slower than the work it replaced.

Cloud agents have the same setup problem. Before Cursor added prepared builds, each agent session booted a machine, cloned the repository, and ran the install script. On large repositories, this took several minutes. Cursor now prepares environments in the background every hour, and new agents start from a warm copy. Cursor says agents start up to 3x faster (Cursor). Linear's shards, Cursor's agents, and Anthropic's checkouts all apply one rule: do setup once, ahead of time, and do not repeat it per job.

What to change, by team size

You are probably not Anthropic. The right fix depends on how much load your agents create.

To find the gate jobs on your own critical path, use this procedure. It takes about an afternoon.

1. List every job in your workflow files and the jobs each one waits for.
2. Collect job durations for the last 2-4 weeks from your CI provider.
3. Use the median duration per job. For a sharded job, use the slowest shard.
4. Find the longest chain of waiting jobs. This chain is your critical path.
5. On that chain, mark each short job that many jobs wait for. These are your gate jobs.
6. For each gate job, ask if it needs checkout and install. Remove what it does not need.
7. Time each cache restore against the step it replaces. Delete caches that are slower.

This advice is the wrong choice in some cases:

• If one test file takes most of a shard's time, fix that file first. No runner or gate fix will help.
• If your security policy does not allow runners outside your CI provider, skip the runner change.
• If tests share state, do not turn off isolation. Fix the shared state first, or keep those files isolated as Linear did.
• If agents write your tests, put your CI rules in their instructions. Linear did this for its isolation rule. See Agent Skills Over Prompts.

For the cost side of agents in CI, see Coding Agents in Continuous Integration. For the review side of a high-volume merge path, see Reviewing AI Generated Code at Scale. To check whether more agent PRs mean more useful output, see Measuring AI Coding Assistant Productivity.

Keep your pipeline ahead of your coding agents

If your agents write more code each month, your pipeline decides how much of that code ships each day. OpenNash puts forward-deployed engineers on your team, and we work with Fortune 2000 companies. A typical engagement for this problem follows these steps:

1. Measure the current pipeline: critical path, gate jobs, setup cost per job, checkout time, and merge-queue throughput.
2. Apply the cheap fixes first: runners, toolchain, and gate jobs, with before-and-after numbers for each.
3. Decide, with data, if your merge queue or your Git hosting is the next limit.
4. Put CI rules into your agents' instructions and skills, so new tests follow them.
5. Add wait-time and cost dashboards, with alerts when a job moves onto the critical path.

At the end, you own the workflow changes, the dashboards, and the agent instructions.

Book a call with an OpenNash forward-deployed engineer or email us at hello@opennash.com. In the first session, we review your pipeline data and show which fixes give the most developer time back for the least engineering work.