Anthropic: agentic coding drove a 25× CI surge, then a test-impact rebuild

Anthropic says its CI job volume rose 25× in six months after Claude-heavy coding lifted both pull requests and tests—then threatened to overload the service that decides which tests to run.

In a September 14, 2026 engineering post, Sachin Malhotra reports that Anthropic engineers now ship eight times as much code per quarter as they did from 2021 through 2025. Claude, the company says, authors about 80% of that code and plays a large role in reviewing and approving pull requests. Tests across the codebase grew 10×, with only a nominal increase in headcount. Not every test runs on every PR, but the mix still produced a 25× jump in CI jobs. Those numbers are Anthropic's own; they are not an independent industry measurement.

Malhotra's point is blunt: writing code is no longer the constraint. Once review speeds up, CI becomes the next bottleneck. Scaling CI, he writes, is a challenge more teams are likely to face as agents accelerate code generation and review.

A singleton that could not shard

Anthropic does not run every test on every change. It uses a deterministic test-impact analysis service that picks tests from past performance and package relevance. A listener records results from every CI run. A selector reads that history and chooses tests for each opened PR.

The original design kept per-test history in a single process so one writer could apply results in order. That blocked horizontal sharding. When multiple CI jobs ran every second, the listener lagged the PR queue. Twenty minutes of lag, Malhotra writes, can mean tens of thousands of test updates never reach the selector. Stale data can miss a failure after a bad merge, leave flaky tests blocking everyone, or skip a newly added or newly fixed test.

Seventy days, then 29, then less than a day

By October 2025 the service was already straining; the team was paged two days straight. The first patch doubled the cores. It lasted 70 days. In February they parallelized: the listener needed a single writer per package, not globally, and Claude generated the code to shard each package onto its own worker. That bought 29 days.

In March the process hit its memory limit by mid-afternoon on most weekdays. Four bugs, a memory-allocator swap, and daily restarts followed. Restarting bought less than a day—and restarts left the listener falling further behind. When lag passed an hour, results went unrecorded. Malhotra stresses that CI still ran and untested code was not pushed to production. The selector simply chose tests from stale history, often re-running tests that were already flaky or failing widely.

Stateless listeners and a flat backlog

The rebuild moved state out of the process. Listener workers became stateless: any worker can append a result to a journal in an in-memory store and move on. A small consumer rolls that journal into per-test history every few seconds. The selector looks up history quickly. The design is more expensive to run, Malhotra says, but it scales horizontally and is easier to memory-profile than a shaky singleton.

One engineer finished the work in three weeks. A year earlier, he writes, it would have been closer to a quarter. After cutover and tuning, queued unprocessed job-result events went from a backlog that built most days and grew week over week to flat. Claude did much of the journal- and worker-sizing autonomously. The service has remained stable since.

Plan for 25× in two quarters

Malhotra's lesson is not "buy a bigger machine." Those tactics now buy a fraction of the time they did a year ago, while a full overhaul also takes a fraction of the time because writing code is no longer the bottleneck. He would have planned earlier for an AI exponential: more agents per engineer, smaller granular PRs (Claude prefers them), overnight and weekend agent activity, and still-bursty human approvals.

His advice: assume a 25× load within two quarters, keep state out of the process from the start, and do not run a critical service as a single instance unless you can measure it. He anticipates that horizontally scaled test selection will become industry standard as agents raise both PR and test volume.

Read Malhotra's full post for the architecture diagrams, the lag failure modes, and the cutover chart—then check whether your own test-selection path is still a singleton.