Anthropic disclosed that its own CI nearly buckled under agentic coding: 25x more jobs, 10x more tests, and three failed patches before it was rebuilt.
Anthropic disclosed in September 2026 that the code volume flowing out of Claude strained its own internal CI hard enough to force a full redesign of a core service. Claude now authors 80% of the code Anthropic engineers ship, and those engineers average eight times as much code per quarter as they did across 2021 through 2025. That growth, combined with a tenfold increase in the number of tests across Anthropic's codebase, drove a 25x increase in CI jobs over a six-month period. Anthropic wrote this about its own infrastructure, not about a hypothetical customer or a competitor's pipeline.
Sources: Anthropic Engineering Blog
The Numbers Anthropic Published
- Claude authors 80% of the code Anthropic engineers ship today.
- Anthropic engineers ship 8x as much code per quarter as the 2021 to 2025 average.
- The number of tests across Anthropic's codebase grew 10x.
- CI jobs grew 25x over a six-month period as a result.
Anthropic added one caveat to the CI job figure worth keeping: not every test runs on every pull request. The whole point of a test-impact-analysis service is to run only the tests a given change could plausibly affect, so a 25x rise in CI jobs reflects both more code moving through the pipeline and more of that code needing tests run against it, not a blunt full-suite rerun on every commit. That distinction matters because it means the strain on the service was not an inefficiency Anthropic could have avoided by testing less. It was the exact system responsible for testing efficiently that ran out of room first.
Sources: Anthropic Engineering Blog
Inside the Service That Broke
The system that buckled was not the tests themselves. It was the service deciding which tests to run. Anthropic's test-impact-analysis service paired a listener, which recorded the results of every CI run, with a selector, which read that result history to decide which tests were relevant to each opened pull request. The whole pipeline ran as a single process, because keeping a running per-test history meant one writer had to apply every incoming result. That singleton design worked fine at Anthropic's old shipping rate. It was never built for a codebase generating ten times as many tests and twenty-five times as many CI jobs inside two quarters.
Sources: Anthropic Engineering Blog
Three Patches, Each Buying Less Time
Anthropic patched the singleton three times, and every fix held for less time than the one before. The strain first showed up as an operational problem, not an architecture one: by October 2025, the test-impact-analysis service was already falling behind, and Anthropic's engineers were paged two days straight before the fix work began in earnest.
Sources: Anthropic Engineering Blog
Engineers first doubled the cores running the service, which held for 70 days. Next, Claude generated the code to shard each package's state onto its own worker process, a fix the team expected to be temporary but did not expect to buy only 29 days. When memory pressure came back, engineers fell back to restarting the service daily, which bought less than a day before lag was building up again and the on-call rotation was getting paged repeatedly.
Sources: Anthropic Engineering Blog
Each of those three fixes added capacity without touching the underlying constraint: a single process still had to be the one writer applying every test result, no matter how many cores it ran on or how the state was split. Adding cores raised the ceiling without changing its shape. Sharding by package raised it again but recreated the same single-writer problem inside every shard. Restarting nightly only reset the clock on memory pressure that was going to build back up on the same schedule. Against a workload compounding at 8x code per quarter, a fix that adds fixed capacity buys less time with every repetition, which is exactly the pattern the 70, 29, and under-one-day lifespans show.
| Fix Applied | What It Did | How Long It Held |
|---|---|---|
| Doubled the cores | Gave the singleton process more compute headroom | 70 days |
| Sharded by package | Claude-generated code split per-package state onto its own worker | 29 days |
| Daily restarts | Manually cleared accumulated memory pressure each day | Less than a day |
| Stateless redesign | Replaced the singleton with workers writing to a shared journal | Holding as of publication |
How Anthropic Rebuilt It
The fix that held was removing the single point of contention instead of giving it more resources. Anthropic replaced the singleton with a stateless architecture: any listener worker can now process any test result, append it to a journal in an in-memory data store, and move on without holding state in memory. A separate consumer process rolls that journal into per-test history every few seconds. Because no single worker owns the state anymore, the service scales horizontally instead of needing a bigger machine or a nightly reset.
Sources: Anthropic Engineering Blog
Anthropic says the redesign took three weeks for one engineer, and estimates the same project would have taken closer to a quarter a year earlier. That gap says something about what agentic coding changes and what it does not: the constraint was never writing the replacement code. It was recognizing, after three shrinking patches, that the singleton itself had to go.
Sources: Anthropic Engineering Blog
The Real Bottleneck Was Never Writing Code
Anthropic's own framing of the problem matters more than any single figure in the post. Claude does not only write Anthropic's code. It also plays a large role in reviewing and approving the pull requests that carry that code forward. Anthropic states the mechanism directly: writing code is no longer the constraint, and once pull-request review gets accelerated, CI starts feeling the pressure. The bottleneck did not disappear when agents took over authoring. It moved downstream to whichever system had the least spare capacity to absorb the new volume. At Anthropic, that system was test selection. At a company running a thinner CI setup, it could just as easily be code review, a staging environment, or a merge gate sized for a tenth of the traffic it now carries. This sits alongside other signs that agentic coding adoption keeps compounding rather than leveling off as the tools mature.
Sources: Anthropic Engineering Blog
That is the pattern worth generalizing past this one service. When authoring speeds up, whatever sits immediately downstream of authoring absorbs the new volume first, whether that is review, test execution, or a deploy step. Anthropic happened to have review moving fast enough that the next constraint to surface was test selection. A team where review is still the slow, manual step will feel the pressure there instead, before it ever reaches CI capacity at all.
What Anthropic Told Everyone Else to Do
Anthropic closed its post with advice aimed past its own walls: CI is evolving too quickly to keep proceeding the old way, so keep state out of the process from the start and avoid running critical services as a single instance. That reads as a lesson pulled from three failed patches, not a theory offered in the abstract. A bigger machine, a smarter shard, and a nightly reset each treated a structural problem as a capacity problem, and each one ran out of headroom faster than the last.
Sources: Anthropic Engineering Blog
The advice is easy to agree with and easy to ignore, because most teams design a service like this once, under a much lighter load, and revisit it only when it starts paging someone. Anthropic's own timeline shows how short that runway can get once agents are generating a meaningful share of the commits: a service that was fine in 2025 was patched three times and rebuilt within roughly a year of Claude taking over most of the authoring.
What This Means If You Are Not Anthropic
- A service built to run as a single process is a growth ceiling, not just a performance limit. Sharding and bigger machines bought Anthropic weeks, not permanence.
- Job counts and test counts do not scale with headcount once agents write and review most of a codebase. Anthropic added a nominal number of engineers while its test count grew 10x.
- Patches with a shrinking lifespan, 70 days, then 29, then under a day, are a signal to redesign, not a signal to patch again.
- The volume problem surfaces wherever verification is weakest in a given pipeline, whether that is test selection, code review, or the merge gate itself.
- Agentic coding cuts both ways on this problem. It is what created Anthropic's CI load, and it is also what let one engineer finish a redesign in three weeks that the company estimates would have taken a quarter a year earlier.
- Measuring CI job growth and test-count growth as their own metrics, separate from headcount or story points, is the only way to see a problem like this coming before the paging starts.
Anthropic's post describes Anthropic's own infrastructure. It does not name, use, or endorse any third-party code-review or governance product, TLM Forge included. What it documents is a pattern, not a recommendation: once agent-driven code volume is real and sustained, whatever enforces verification has to scale with it or become the next bottleneck.
Anthropic's fix lived inside its CI infrastructure: replace a stateful singleton with a stateless system that scales horizontally instead of needing a bigger box. A comparable problem shows up earlier in the pipeline too, at the point where a pull request gets reviewed and merged. TLM Forge is built for that layer: it blocks a merge until every critical finding from its adversarial reviewers is resolved through a scored gate rather than a reviewer's opinion, requires a spec and goal-contract sign-off before any code is written, and enforces test-driven development with full-suite regression evidence attached to the merge instead of a claim that testing happened. None of that would have caught a test-selection service running low on memory. That is a different layer of the same pipeline. But it answers the same question Anthropic just raised about its own infrastructure: once agent output is heavy and constant, whichever part of the pipeline was never designed to carry that load is the part that gives way first.
Frequently asked questions
01What percentage of Anthropic's code does Claude write?
Anthropic says Claude authors 80% of the code its engineers ship, disclosed in a September 2026 engineering blog post about the resulting strain on its CI systems.
02Why did Anthropic's CI system need to be redesigned?
A 25x increase in CI jobs and a 10x increase in test count over six months overwhelmed Anthropic's test-impact-analysis service, which ran as a single process that could not be scaled by adding hardware alone.
03What does a test-impact-analysis service do?
It decides which tests actually need to run for a given code change, pairing a listener that records results with a selector that picks relevant tests, so CI does not rerun an entire suite on every pull request.
04How did Anthropic fix its CI bottleneck?
After three temporary patches (doubling cores, sharding by package, and daily restarts, each holding for a shorter time) Anthropic rebuilt the service as stateless workers writing to a shared journal, completed in three weeks by one engineer.
05Does this mean Anthropic uses or endorses AI code review tools like TLM Forge?
No. Anthropic's post describes its own internal infrastructure only and does not mention or endorse any third-party tool. It stands as independent evidence that verification systems must scale with agent-driven code volume.