Coding Agents Grew Anthropic's CI 25x: How the Fix Worked

When coding agents write most of a company's code, the next thing to break is not the code review. It is the machine that runs the tests. On September 14, 2026 an Anthropic engineer published what that looked like inside Anthropic: CI jobs up 25 times in six months, and a test-selection service patched three times before it was rebuilt. Each patch bought less time than the last.

This post is for the engineering lead whose CI queue or bill has grown since the team adopted coding agents. It explains the Anthropic post for a reader who has never run test impact analysis, then turns its lesson into a decision for a team of ten rather than a lab. Every figure is Anthropic's, about Anthropic's own codebase. None of them is a benchmark of anyone else.

The post opens with the cause before the effect. Anthropic's engineers ship eight times as much code per quarter as they did in the 2021 to 2025 period, and Claude writes 80 percent of it. Claude also does much of the review. Once writing and reviewing both speed up, the author says, the pressure moves to continuous integration, the system that runs tests on every proposed change.

The post gives no cost figures and none are inferred here. It also does not claim the 80 percent applies anywhere else. Treat the three numbers as a description of one large monorepo run by people with unusually heavy agent use, and read the pattern rather than the values.

Most teams run every test on every change. That is simple and, as the post says, works up to a point. Past that point the CI gate gets long, expensive and less trusted, because a failing test that has nothing to do with your change is noise you learn to ignore.

Test impact analysis, also called test selection, is a service that picks which tests to run for a given change. Anthropic's is deterministic: it chooses based on recorded past results and on which packages the change touches. The post notes that vendors sell this as a product, so it is not an exotic idea. What is specific to Anthropic is the load.

The service has two parts that must stay in step. A listener records the result of every test in every CI run. A selector reads that history and decides which tests each open pull request needs. The failure mode is lag. If the listener falls 20 minutes behind, the post says, tens of thousands of test updates have not reached the selector. Then a bad merge fails tests for everyone, a flaky dependency blocks merges, and a newly fixed or added test does not run until the listener catches up.

The original design ran as one process, because keeping a running history per test seemed to need a single writer. That decision is the whole story. A single writer cannot be split across machines, so every fix short of removing it was a delay.

By October 2025 the service was straining and the team was paged two days running. What followed is the useful part of the post, because it is a dated record of quick fixes with the time each one bought.

The post is careful about what the missed results meant. CI still ran on those pull requests and untested code did not reach production. The selector was simply choosing from stale data, which mostly meant running tests that were already flaky or failing for everyone. That is the quiet cost of lag: not danger, but wasted compute and eroded trust.

One detail is worth keeping. During the sharding period the author ran a long-lived session of an internal version of Claude Tag, Anthropic's Slack product, that watched the service and pinged him whenever the listener fell more than 50,000 jobs behind. The post says Claude often argued for a full overhaul and the humans usually chose another patch. The model was, in the record as published, right earlier than the team.

The redesign removed the single writer by giving the service a database, specifically an in-memory data store. Any listener worker can now take any result, append it to a journal in the store, and move on holding nothing. That makes the workers stateless, which means more of them can be added on more machines. A small separate consumer rolls the journal up into per-test history every few seconds, and the selector reads from that.

Anthropic says the distributed version costs more to run but is far easier to scale and to profile than one overloaded process. The chart in the post shows the backlog of unprocessed results, which used to build most days and grow week on week, flat after the cutover. The tuning of journal size and worker count was done, the post says, largely by Claude on its own. The whole project took one engineer three weeks, which the author says would have been nearer a quarter a year earlier.

The general lesson the author draws is about planning, not technique. Buying a bigger machine, parallelising and restarting are, in his words, "not the insights to take from this article". The insight is that each of them now buys a fraction of the time it used to, while a full redesign costs a fraction of what it used to. The ratio between patch and rebuild has moved, and it moved because writing code stopped being the slow part. We made a related argument about measuring agent output in our guide to evidence of completed work: usage numbers rise first, and the systems downstream of the agents feel it before the metrics do.

Almost nobody reading this runs a monorepo at Anthropic's scale. The question is what a team of five to fifty engineers, now running agents, should take from a lab's experience. Our reading, drawn from the post's own recommendations, sorts by what your CI is doing today.

The last row points at a control the post does not discuss. Agent platforms expose limits on concurrent runs, and setting them is cheaper than scaling the pipeline they feed. We collected those limits in our parallel-agent resource limit reference. For the pipeline itself, the design principles in our CI/CD pipeline design reference predate agents but still hold, with one number changed: the load you plan for. Anthropic's advice is to assume 25 times the current load within two quarters, and to accept that designing a first version for ten to twenty times the visible scale is no longer over-engineering if the budget allows.

If your team is adopting agents and the pipeline is already the constraint, our AI transformation practice starts engagements with the systems downstream of the agents, because that is where the first bill arrives.