Why Making CI Pipelines Faster Won't Solve the Real Problem with AI Agents

Recent disclosures from major engineering teams paint a clear picture of a crisis brewing in continuous integration. Anthropic's CI job volume surged 25x in six months as their agents ship roughly 8x more code per quarter than they did historically. Linear's test suite has nearly quadrupled since January. These are not isolated incidents — Blacksmith, a CI runner vendor, reports 5–10% week-over-week growth in CI jobs driven by AI-generated code.

The industry's response has been instinctive: make pipelines faster. Smarter test selection, bigger caches, ephemeral runners, and inline validation all help. Yet these optimizations treat the symptom, not the disease.

Why CI Became the Bottleneck#

Agents broke two foundational assumptions about how continuous integration works. Volume is the first. When a single engineer deploys multiple agents in parallel, the number of pull requests multiplies rather than increments. A developer who once submitted a handful of PRs per week now submits dozens.

The second is loop latency. Traditional CI runs after a PR is already open. An agent that drafts code, commits, and then waits 20 minutes for feedback has lost its working context by the time results return. Each failure means starting over. The agent itself is fast; everything surrounding it is not.

The response has been predictable: faster runners, smarter test selection, cached artifacts, and systems that let agents pre-validate before even creating a PR. All of it is necessary. All of it is also incomplete, because it leaves one critical question unanswered: what are you actually verifying?

The Repo Versus the System#

For a monolithic application, a repository is the system. Unit tests exercise the application in isolation. Green tests mean the code works.

For cloud-native architectures with dozens of interdependent services, a repository is a single piece of a much larger puzzle. A change can sail through every unit test, pass CI in record time, run perfectly in a sandbox built from the branch — and still shatter the first real request that crosses a service boundary.

The failures that inflict the most damage in distributed systems live in the seams. A renamed field that a downstream service still tries to read. A timeout tightened in one service that triggers cascading retries elsewhere. A schema change that works against test data but locks production tables. An endpoint that behaves correctly in isolation and incorrectly when called by its actual dependencies.

No conventional CI pipeline, regardless of speed, can detect these breaks, because it cannot see beyond the repository it is testing. This is why recent reports from Anthropic, Linear, and others are symptoms of a deeper problem. DevOps Research and Assessment has found that — faster code shipped with the same incomplete verification creates more broken deployments.