Writing code is no longer the slow part of shipping software. For teams running AI coding agents, the bottleneck has moved upstream: to source control, CI pipelines, and code review. Harness published its own internal numbers this month, and they are worth a look if you manage any developer infrastructure.
The raw numbers
Over the past year inside Harness’s own engineering org, pull requests grew about 7x, pushes grew 6.6x, and data pulled from repositories grew almost 6x. CI executions grew nearly 7x between November 2025 and September 2026. Active contributors grew roughly 30%. Lines of code added per month grew almost 5x between March and May 2026 and held above the March baseline through July.
One stat explains the shape of the problem: reads grew faster than writes, almost 6x versus 3 to 5x. CI jobs and agents clone repositories far more often than they commit to them. Every agent-driven task can trigger multiple pushes, multiple CI runs, and multiple fresh clones of the same repo.

What broke and how they fixed it
At peak load, CI pipelines started queuing even though compute capacity was available. The bottleneck was concurrency limits, not hardware. Harness cleared it by raising concurrency limits and temporarily disabling high-volume, non-critical triggers. Error rates stayed flat throughout, confirming the spike was demand, not instability.
On the source control side, Harness shipped three targeted fixes:
- Clone caching: A single commit can spawn up to 100 CI pipelines, each starting with a fresh repo clone. Harness added a short-lived clone cache keyed on the commit and the client’s flags. The first request builds the packfile; identical subsequent requests serve the cached version. This cut cloning latency by 40%.
- Merge optimizations: Read-only merge-verify calls (dry-run merge checks) previously took a distributed write lock and ran across every replica through quorum. The fix removed that requirement, cutting merge-verification work by about two-thirds across n replicas. Merge Queues were added for the busiest repositories handling concurrent merge requests.
- Predictive CI scaling: Load is now distributed across regions and availability zones with warm pools and fallback strategies. A predictive load algorithm scales capacity ahead of peak based on historical patterns, which let them serve 7x the previous load volume without slowing the build system.
Anthropic ran into the same wall
Harness notes that Anthropic published a similar finding. Between May and September 2026, merged changes in Anthropic’s monorepo jumped from roughly 2,500 to more than 30,000 per day, a 12x increase in four months. Anthropic built a custom REST API-based approach to replace traditional Git clients for its workloads, though Anthropic itself noted in its blog that the approach required significant engineering investment and may not make sense for every team.
The MCP angle
Harness also ships a Harness MCP server that gives agents direct access to repository and pull request data without cloning. Current capabilities include listing repositories, fetching files, and fetching pull requests with their checks and comments. The Harness CLI adds commands like harness list repository, harness get pr <repository_id>/<pr_number>, and harness get commit <repository_id>/<commit_sha> for agent-friendly SCM interaction without a local clone.
What comes next
Harness says it is working toward separating compute and storage in its repository architecture, similar to how Snowflake, Amazon Aurora, and Redshift operate. In this model, durable cloud object storage holds the repository data, Git servers keep a local copy as a fast disposable cache, and hosted pipeline runners may eventually fetch repository data directly from the durable store, reducing clone traffic on Git servers entirely.
For teams running agents at any scale, the pattern is clear: tools designed for human commit rates will queue and slow down long before you run out of raw compute. The fix is infrastructure that treats reads as a first-class workload.
