Three significant posts appeared in September that deserve to be read as a set. Anthropic disclosed that continuous integration job volume surged 25x over six months, with engineers now shipping roughly 8x more code per quarter than they did between 2021 and 2025. Their response was to implement test impact analysis, which executes only the tests relevant to a given change. Linear published a piece titled "AI coding has made CI a bottleneck," noting their test suite has nearly quadrupled since January as agents author most tests, prompting an end-to-end pipeline redesign. Depot's CEO argued that CI is undergoing transformation, with the future lying in "giving agents a way to validate code and maintain trust as they work."
What makes these reports worth attention is that Anthropic and Linear do not sell CI tools—they are describing what occurred inside their own systems. The diagnosis of the problem is sound across all three accounts, yet two of them are addressing the wrong layer of the issue.
How CI became the bottleneck
For two decades, CI infrastructure was calibrated around human development patterns. A developer would submit a handful of pull requests each week, and the pipeline would execute after each submission. A 20-minute runtime was acceptable because the developer had already moved on to the next task. Agents shattered this model in two distinct ways.
The first is sheer volume. When a single engineer orchestrates multiple agents simultaneously, pull request counts multiply rather than increment. Anthropic's 25x figure is not exceptional; Blacksmith, which operates CI runners, reports that job counts have expanded between 5% and 10% every week.
The second is timing. CI executes only after a pull request is created. An agent that generates code, opens a PR, and then waits 20 minutes for the result has lost the context it held while writing. Each failure requires a complete round trip. As one observer put it, "The agent is fast, and the loop around it is slow."
The industry responded predictably: make CI faster. Faster execution environments, intelligent test selection, expanded caching, pipelines callable before commit—all of it helps, all of it is necessary, and all of it preserves one unexamined assumption: that the thing being verified is a repository.
What a green pipeline does not tell you
For a monolithic application, the repository is the system. Tests run, and you understand the state of the software.
For cloud-native architectures, a repository is one service among dozens or more. Tests in that repository exercise that single service while mocking all others. A change might pass every unit test, sail through CI in record time, pass a sandbox built from the branch, and still fail the moment a real request traverses a service boundary.
In distributed systems, the failures that matter occur at the seams. A field renamed in a response that downstream consumers still expect. A timeout reduced in one service that triggers cascading retries elsewhere. A schema modification that works against test fixtures but locks a table in staging. A fresh endpoint that functions correctly when the test harness invokes it but behaves incorrectly when the dependent service calls it.
No CI pipeline, regardless of speed, detects any of this. It cannot, because it examines only a repository.
The September posts are symptoms rather than root causes. CI slowed because verification transitioned from a human decision point to an automated one without examining what the automated gate actually validates. Accelerating the gate does not alter what it checks.
DevOps Research and Assessment (DORA) uncovered a troubling correlation: organizations with higher AI adoption see increases in both software delivery speed and software delivery instability. "Faster code, same verification, more breakage. That is the gap."
The verification loop has to move
Cursor made an observation in February that grows more pertinent with time. Their agents operate within cloud sandboxes, each with its own virtual machine, and more than 30% of the PRs Cursor merges now originate from agents working in this manner. Their explanation: "Without the ability to use the software they are creating, agents hit a ceiling."
This instinct is correct. The agent must execute the code, not merely compose it. Every major coding agent now implements some form of this capability. GitHub's Copilot cloud agent runs tests in ephemeral environments backed by GitHub Actions. Codex executes a setup script and resumes cached containers. Devin initializes from environment blueprints. Greptile's TREX executes the branch and attaches logs and screenshots to the PR.
Yet examine what each sandbox contains: the repository, the branch, and whatever the setup script could provision. None include the other 39 services, the actual message queue, or a database populated with production-like data.
"So the loop closes, but it closes around the wrong thing." The agent validates its change against a replica of its own code. Then the change enters CI, which validates it against the same replica, faster. Then it moves to staging, and only then does anything verify whether it functions with the rest of the system.
For distributed systems, pre-PR verification must target the system itself, not the repository. This is the essential shift. It is not quicker feedback on the same question. It is a different question, posed earlier.
Why this looks expensive and is not
The immediate objection centers on expense. If every agent requires the entire system for verification, and one engineer runs five agents, five staging environments per engineer become necessary. The cost appears prohibitive.
The solution mirrors what the industry did with compute two decades ago: do not assign every workload its own machine. Multiplex instead.
A single Kubernetes cluster can maintain one stable shared version of every service and host thousands of lightweight test environments on top. Each test environment deploys only the modified service. Requests routed to that environment pass through the changed service; all other hops resolve to the shared stable versions. The modified service communicates with genuine dependencies, and those dependencies remain unaware that anything shifted.
A test environment costs approximately the price of one pod and initializes in seconds. Fifty agents working concurrently share one stable environment instead of each cloning it. This is what makes system-level verification inside the agent loop economically viable.
Agents need governed verification, not only environments
Inexpensive, rapid environments are insufficient on their own. An agent also requires a structured methodology for using them: transmit this request, record that log, confirm this contract, report findings. Without guidance, each agent develops its own checks, and no two executions remain comparable.
The effective model has the platform team define these steps once, as an approved sequence that exercises a change against the live system and documents the outcome. Agents invoke them via the skills and hooks that Claude Code, Cursor, and comparable tools already provide, so verification becomes part of the loop rather than following it. Governance matters as much as the steps themselves, because platform teams must ensure agents cannot perform unsafe operations in a shared cluster.
Output is equally important. A record showing which requests were sent, which services were contacted, and which contracts held is an artifact downstream processes can consume. Review tools and merge gates can observe that a change was tested against live services before human review, transforming CI from the first place cross-service failures appear into a confirmation stage.
Verification belongs inside the agent's loop
CI vendors will continue accelerating, and coding agents will keep improving at running code in sandboxes. Both developments benefit everyone, and neither bridges the gap between a repository and a system. Organizations that gain an edge will stop asking how quickly the pipeline can confirm a repository passes its own tests and start asking how soon an agent can demonstrate a change works alongside everything else. That question finds its answer in one location: inside the agent's loop, against the real system, before the PR.