Anthropic's CI buckled after Claude wrote 80% of the code

Three fixes to one internal service bought Anthropic 70 days, then 29 days, then less than a day. That decay curve is the real subject of a post on Claude's engineering blog about what happens to CI once Claude writes 80% of the code your engineers ship.

At a glance

• CI jobs at Anthropic grew 25x in six months, driven by an engineering org that ships 8x more code per quarter than it did between 2021 and 2025, with tests up 10x.
• The service runs on two halves: a listener that records every CI result, and a selector that reads that history to decide which tests a given pull request actually needs.
• The rebuilt version is stateless and shards horizontally, but it costs more to run, and during the bad weeks stale data meant the selector kept scheduling tests that were already flaky or broadly failing.

If you have not been following: Anthropic engineers now ship 8x as much code per quarter as they did across 2021–2025, Claude authors 80% of it and also takes a large role in reviewing and approving PRs. Tests across the codebase grew 10x, headcount grew only nominally, and CI jobs rose 25x in six months. Plenty of teams still run every test on every change, which gets long, expensive and untrustworthy at this volume.

The three patches lasted 70 days, 29 days and less than a day

By October last year the service was already straining and the team got paged two days running. The first fix was the obvious one: double the cores. It bought 70 days, and nobody expected more, but ownership stayed murky, since no one wanted another piece of infrastructure and the CI team had bigger problems.

In February the growth came back around. The listener did not need one writer to order results correctly, it needed one writer per package, so each package's state got its own shard and its own worker. Claude generated that code. It lasted 29 days.

By March the process was hitting its memory ceiling by mid-afternoon on most weekdays. The team found four bugs, swapped the memory allocator to no effect, and did not want to risk memory-profiling a singleton already under heavy load. Restarting the service bought less than a day.

Twenty minutes of listener lag means tens of thousands of missed test updates

Deterministic test selection like Anthropic's is not exotic, and the post notes a vendor category around it. According to Cloudbees, the rules-based version leans on dependency maps and coverage data, while machine-learning alternatives guess probabilistically and need a stretch of history before they work at all.

When CI jobs land several times a second, the listener drifts behind the PR queue, and twenty minutes of drift means tens of thousands of result updates the selector never sees. Three things follow. A bad merge keeps failing for everyone, and separate teams investigate it separately. A flaking dependency turns into reds that block merges.

A test that was just added or just fixed does not run until the listener catches up, which risks a regression. The post is explicit that none of this pushed untested code to production: CI still ran, the selector simply chose from stale history. Mostly it meant running tests that were already flaky or failing across the board.

Daily restarts made the drift worse rather than better. Several times the service fell behind by more than an hour, and a large batch of job results was never recorded.

The rebuild gives every worker a journal instead of one writer

The v0 design kept a running history for each test inside the process, so a single writer had to apply every result in order. A single writer cannot be sharded, and everything else followed from that one constraint.

The fix, which Claude had been arguing for, was an in-memory data store. Any listener worker can now take any result, append it to a journal and move on holding nothing. A small separate consumer rolls the journal up into per-test history every few seconds, and the selector reads from there.

Think of the old version as one clerk who memorized every order in the shop and could never hand off a shift. The new one writes each order on a shared pad that somebody else totals.

One engineer did the rebuild in three weeks; a year ago, the author writes, it would have been closer to a quarter. Claude handled most of the tuning afterwards, including journal size and worker count. The chart of queued, unprocessed job-result events, which used to build a backlog most days, is flat since the cutover.

Assume 25x load within two quarters, the author says

To keep a long-term fix moving, the author ran a standing session in an internal version of Claude Tag dedicated to watching the service. Whenever listener lag passed 50,000 jobs, Claude pinged him and resumed the thread with months of context intact. It often argued for the overhaul; they usually shipped another patch.

Two shifts sit behind the job count. Claude prefers smaller, more granular PRs, which is another argument against running every test on every change, and agents push overnight and on weekends, raising the floor of activity while human engineers keep the load bursty.

The closing advice: assume your architecture is at 25x load within two quarters, whether you build or buy, and design v0 for 10 to 20 times the scale you think you need if the budget allows. Keep state out of the process, instrument services so Claude can see them, check that CI jobs in equals jobs out, and avoid running anything critical as a single instance you cannot measure.

The post puts no figure on cost: the distributed version is described only as more expensive to run, and the 25x is a multiple with no absolute job count behind it. Oddly, for a piece whose parting advice is to over-build v0 when the budget allows, the budget is the one variable left unquantified.

When this design hits its own wall

The post names no ceiling for the new architecture and no date by which it expects to reach one. What it offers instead is a prediction: as teams run more agents, producing both more PRs and more tests, horizontally scaled test selection becomes the industry default. If the rule of thumb about 25x every two quarters holds at Anthropic, the next data point worth watching is whether a stateless design survives a second round of it.