Your CI Was Sized for Humans: What Agent Load Is Doing to Pipelines, Main Branches and Delivery

Why Has CI Become the Constraint on AI-Assisted Delivery?

Most of the debate about AI coding has been about writing code, then about reviewing it. A quieter problem sits between the two. Every agent iteration that pushes a branch can start a pipeline, and a developer running several agents can start far more of them in an afternoon than the same developer ever did by hand. The machinery that decides whether code is safe to merge is now among the busiest systems an engineering organisation runs, and in many companies it still has no owner.

CircleCI's 2026 State of Software Delivery, based on 28,738,317 workflows run during September 2025, shows the shape of it. Average daily workflow runs rose 59% year over year, but the median team gained only 4% and the bottom quartile gained nothing measurable. For the median team, feature branch throughput rose 15% while main branch throughput fell 7%. More work was started. Less of it arrived.

The follow-up data did not close the gap. CircleCI's Q2 2026 Pulse, covering more than 20 million workflows from March 2026, found feature branch throughput up 7.7% year over year and main branch throughput flat, at roughly 1.7 workflows per day for the median team. The gap between the top 5% of teams and the median widened from 8x to 9x.

A caveat belongs here. This is one vendor's customer telemetry, not a census of the industry, and CircleCI sells the product that benefits from the conclusion. The attribution to AI is also an interpretation, since a workflow log does not record who or what wrote the code. But the direction matches what we have seen in the review and merge data: generation scales easily, and everything downstream of it does not.

What Does a 76.7% Main Branch Actually Cost?

Main branch success is the number to look at first, because a red main blocks everyone. CircleCI reports that it fell to 70.8%, the lowest in over five years, against its recommended benchmark of 90%. The Q2 reading recovered to 76.7%, still below the mid-80s results of 2023 and 2024. Recovery to green took the typical team 72 minutes in the first report, up 13% from the year before and 12 minutes over the benchmark.

The report's own worked example makes this concrete. A team pushing five changes a day at 70% success sees about 1.5 failures a day, against one every two days at 90%. CircleCI puts that difference at roughly 250 additional hours a year lost to debugging and blocked deployments. At 500 changes a day, it becomes the equivalent of 12 full-time engineers doing nothing except getting back to green.

Size does not protect you, and being mid-sized seems to hurt. Companies with 21 to 50 employees had the lowest throughput in the report, and recovery times approaching three hours, nearly four times longer than the smallest and largest cohorts. That fits what we would expect. These companies have enough people and services to generate real integration failures, but rarely a platform team to absorb them.

Rework is the second cost. The Q2 Pulse introduces a Merge Efficiency Ratio, which measures rework before code reaches main. The median team scores 3.9, which CircleCI translates into roughly five CI cycles per shipped change. The top 5% score 2.6, and a cohort of the 20 highest-throughput organisations improved from 1.62 to 1.28. CircleCI models a 50-developer team shipping about 3,000 changes a month at the median ratio as spending up to roughly $900,000 a year on delivery, with $700,000 or more recoverable by validating earlier. Those are a vendor's modelled numbers, so run your own, but the ratio itself is cheap to calculate from your CI history.

What Did GitHub's Year of Outages Reveal About Agent Load?

The strain is also visible at the platform level. In an April 2026 update, GitHub CTO Vlad Fedorov wrote that the company began a plan to increase capacity by 10X in October 2025, and that "by February 2026, it was clear that we needed to design for a future that requires 30X today's scale." The post says agentic workflows accelerated sharply from the second half of December 2025, and describes why this compounds: a single pull request can touch Git storage, mergeability checks, branch protection, Actions, search, notifications, webhooks and databases.

The reliability record shows what that meant for users. LeadDev reported IncidentHub's count of 257 incidents between May 2025 and April 2026, 48 of them major, with Actions the worst affected at 57 outages. Weekly Actions volume is reported by GeekPark to have gone from 500 million minutes in 2023 to 1 billion in 2025, reaching 2.1 billion in one week in early 2026, although that piece does not name a source for the figures.

Agents are not the whole explanation, and it is worth being fair about that. The Pragmatic Engineer pointed out that GitHub was also migrating from its own data centres to Azure during the spike, and that peers including GitLab, Bitbucket, Vercel and Linear had not suffered comparable public problems under similar growth. So this is not proof that agent load inevitably breaks platforms. It is evidence that load growth finds the weak points in whatever you already have.

For most teams the practical lesson is about dependency, not about GitHub. On 23 April a merge queue bug produced incorrect squash merge commits, affecting 2,092 pull requests according to the same report. If your only route to production runs through one hosted pipeline, then that vendor's incident is your incident. We covered the general case in our piece on dependency resilience. CI deserves a place on that list, including a tested answer to one question: how do we ship an urgent fix if the pipeline is down?

Is the Real Cost Compute, or Waiting?

When CI gets busy, the first instinct is to look at the runner bill. That is usually the wrong place to start. GitHub cut hosted runner prices by up to 39% from January 2026, and postponed a proposed $0.002 per minute charge on self-hosted runners after developers objected. Per-minute prices can move in either direction, and that postponed fee is a reason to check your exposure, but raw minutes are rarely the largest line.

Flaky test research supports this. In the ICST 2024 industrial case study by researchers from TU Munich and CQSE, covering a roughly 30-developer commercial project over five years, automatically rerunning failed tests cost a negligible $3 a month. Flaky tests as a whole consumed at least 2.5% of productive developer time. The compute was trivial. The people were not.

At larger scale the numbers get uncomfortable. Atlassian reported that flakiness caused as much as 21% of master build failures in its Jira Frontend repository and about 15% in the backend, wasting over 150,000 developer hours a year. Those are the figures of a very large organisation, and yours will differ, but the structure of the cost carries over.

Agents add a new line to this account, and here we are reasoning rather than citing a study, because we found no rigorous data on it yet. A human who sees a familiar flaky failure shrugs and reruns it. An agent may treat the same red check as a real defect and spend tokens investigating it, or change code to get a pass. That links the CI problem to your AI coding budget, and to the test tampering behaviour we have written about. An unreliable signal costs more when the reader of the signal is both literal and billed by usage.

What Should You Fix First?

Start by moving validation closer to the author. CircleCI's Q2 conclusion is that fast checks in the inner loop reduce CI runs, developer friction and token spend. In practice, give the repository one fast command, covering lint, type checks and the tests most relevant to the change, and require humans and agents alike to pass it before pushing. It must behave the same locally and in CI, or people and agents will learn to ignore it.

Second, stop running everything on every push. Use path filters and test impact selection on feature branches, and keep the full suite for the merge gate. In GitHub Actions, set a timeout on every workflow and a concurrency group that cancels superseded runs, so an agent pushing six commits in ten minutes does not leave six full pipelines competing for runners.

Third, deal with flakiness as a managed backlog. Detect flaky tests automatically, quarantine them so they stop blocking merges, and give each one an owner and a deadline. Quarantine without a deadline simply deletes coverage slowly. Auto-rerunning is a legitimate tactic, and the ICST authors moved their team towards it, but keep a record of what was rerun, or you will lose sight of real intermittent defects.

Fourth, protect main. Test each change against the current state of main rather than a stale base, using a merge queue if your volume justifies one, and treat a red main as an incident with a named responder rather than a shared annoyance. Pair this with progressive delivery, so that merging and exposing a change to users stay separate decisions.

Finally, set limits for agents. Cap how many times an agent may retry a failing pipeline before it must stop and hand over to a person, and limit how many of its branches can run full pipelines concurrently. A repository in agent-ready condition makes all of this easier, because fast deterministic checks are what agents need most.

Who Should Own the Pipeline?

Almost every recommendation above is cheap in licences and expensive in attention. That is why it does not happen. Feature teams are measured on features, CI work never wins a prioritisation meeting, and the pipeline degrades one skipped test at a time. The mid-sized cohort in CircleCI's data, with its three-hour recoveries, looks to us like what that drift produces.

Large companies solve this with a platform team, and platform engineering remains the right long-term model. A 40-person company rarely needs a whole team, however. It needs one or two engineers with explicit responsibility for pipeline health, a small set of published numbers, and the authority to block merges when main is red.

The numbers can stay simple: main branch success rate, time to recover, Merge Efficiency Ratio, the 90th percentile of pipeline duration, and the size of the flaky test backlog. Review them monthly next to delivery data. If a metric cannot change a decision, drop it.

This is well suited to a dedicated development team or a focused cloud and DevOps engineer working as part of your organisation. The work is continuous, it benefits from knowing your codebase, and it needs to overlap with the people it unblocks. A red main at 10:00 in Berlin or London is best handled by someone awake and working at 10:00. That is one practical reason nearshore development from Serbia suits this work for European clients, and offers useful morning overlap for US East Coast teams.

What Should You Ask a Development Partner About CI?

If an outside team ships code for you, its pipeline habits become your delivery risk, and they are easy to check. Claims about AI productivity mean little if the same team's main branch is red a quarter of the time. Pipeline data is much harder to spin than a slide about velocity.

Ask to see the numbers: main branch success rate over the last 90 days, and how long recovery took. Ask what a developer or agent must pass before pushing. Ask how flaky tests are found and who owns them. Ask how many CI cycles a typical change takes before it merges, and what limits apply to agent retries. Ask what happens to an urgent fix when the CI provider is down. A strong team answers with data and specifics, and a weak one talks about tools.

Also settle ownership in writing. The pipeline definitions, secrets management approach and CI accounts should belong to you, and pipeline changes should be reviewed like any other code. If you have to change vendor later, a pipeline that only runs inside someone else's account becomes a transition problem you would rather not inherit.

At Stepto, we think a client should be able to see these signals directly rather than hear about them in a status report. Dedicated teams work in the client's repositories and pipelines, so build health is visible to both sides, and AI-assisted work goes through the same gates as everything else.