Anthropic's CI firefight ran from October to March — the fix was three weeks of one engineer

The 30-second version

On 14 September an Anthropic engineer published the story of a service that kept falling over as Claude took over most of the company’s code. The headline figures travelled further than the details:

• CI jobs grew 25x in six months; the test corpus grew 10x, on nominal headcount growth.
• Engineers shipped about 8x as much code per quarter as across 2021-2025, with Claude authoring roughly 80% of merged code.

The component that buckled was test impact analysis, which decides which tests to run for a given change. The repair sequence has dates attached, and they are more informative than the multiples:

That is roughly five months of firefighting, and a three-week fix at the end of it. The gap between those two facts is the useful part of the post, and it is worth being precise about what the numbers can and cannot tell you — including one piece of arithmetic that most capacity planning gets backwards.

What a fix adds, and what you already had

A capacity fix is exhausted when load reaches the new ceiling. Write load as L(t) = L₀ · 2^(t/D) with doubling time D, sustainable capacity C₀, utilisation u = L₀/C₀, and a fix that raises capacity to k·C₀. Then:

• Runway you already had, doing nothing: D · log₂(1/u)
• Total runway after the fix: D · log₂(k/u)
• What the fix itself added: D · log₂(k)

That last line is the one that matters, and the u cancels out of it. A 2x adds one doubling of runway whether it lands at 100% utilisation or 50%. Acting early gives you more total time — at 50% you already had a doubling in hand — but it does not make the fix worth more. It is easy to slide between “how long until this breaks” and “how much did that buy”, and they behave differently.

What the logarithm does to the second quantity is the practical lesson:

Capacity tends to be priced roughly linearly and returns logarithmically. Going from a 2x to a 10x is five times the capacity for 3.3 times the added runway; from 10x to 100x is another tenfold for double again. You can buy doublings, but each one costs more than the last.

Reading the 70 days carefully

The first patch is the only one with a known nominal multiple — they doubled the cores — so it is the one people reach for to back out a doubling time. Two things have to be true for that to work, and only one of them is.

Utilisation was near its ceiling, and this is established. The post says that by October the service was showing strain and the team “got paged two days straight” before the cores were doubled. A service paging on consecutive days is not sitting on spare capacity. So u ≈ 1, and the 70 days is close to the time load took to consume log₂(k) doublings.

The throughput multiple is not known, and it is probably below 2. Doubling cores doubles a resource, not necessarily the work done. At that point the design still routed writes through a single writer — a serialisation point — and adding cores to partly serialised work returns less than linear. Which way that cuts is worth spelling out:

Every value of k below 2 makes the implied doubling time longer, not shorter. So the defensible statement is a bound: if doubling the cores bought at most 2x of real throughput, the doubling time in late 2025 was 70 days or more.

Set that against the other published figure. 25x over six months implies an average of 39.3 days per doubling. That is roughly half the late-2025 bound.

The two do not have to be reconciled by acceleration — but acceleration is the straightforward reading, and it requires one assumption the post does not supply: that the six-month window sits later than the October-to-March repair sequence. Given a September publication date, that is plausible. It is not stated, so this stays a reading rather than a measurement, and it is worth flagging because the post is circulating as though 25x were a rate you can apply to anything.

The shrinking patch durations are consistent with the same picture without independently proving it. 70, then 29, then under one — but those three fixes addressed different resources, so the sequence is not three samples of one curve.

Three fixes, three resources

That distinction deserves its own paragraph, because it changes what the story is about. The failures were: CPU strain, then listener lag that was paging the team, then a process hitting its memory limit by mid-afternoon on most weekdays. Cores, queueing, memory.

A stateful single-instance service holds several resources at once, and the post does not establish that each fix caused the next failure. What it does show is that three separate interventions all landed on the same component without addressing what made it fragile: it could not be scaled horizontally.

The third patch is where the capacity model stops applying altogether. Daily restarts do not raise a ceiling, they reset an accumulation. How long that buys depends on how fast memory refills, not on how fast load doubles — and it was under a day. That does not prove more memory would not have helped; it does show the team had run out of moves that could be expressed as a multiple.

The redesign, and what it changed

Listener workers became stateless, the journal moved to a shared in-memory store, a consumer rolls entries into per-test history every few seconds, and a selector queries it. The single writer — global at first, one per package after the February sharding — was gone from the listener path.

This does not make the system unbounded. The shared store, the consumer and the selector each have ceilings of their own, and at some load one of them becomes the constraint. What changed is narrower and still valuable: absorbing another doubling in the listener tier is now mostly a matter of adding workers rather than changing the design, assuming nothing else binds first.

And it took three weeks of one engineer. That is not evidence the patches were a mistake. Stopgaps are how a team stays up while a real fix is built; the failure modes only became legible one at a time; and the October decision was made without March’s information. But the juxtaposition is worth sitting with, because the same shape recurs: if the durable fix is three weeks, how many 70-day patches is it worth?

Anthropic’s advice, unedited

Four recommendations, paraphrased tightly rather than quoted at length:

• Assume your architecture will be at 25x load within two quarters, whether you build or buy.
• Account for 10-20x the perceived scale in v0 designs, as budget allows.
• Instrument services so Claude can read their metrics — including checking that jobs arriving match jobs completing.
• Keep state out of the process from the start, and avoid running a critical service as a single instance unless you can measure it and any canary changes.

The first two are deliberately different numbers, and reading them as a contradiction misses the point: plan against 25x, design for the smaller figure your budget actually permits, and know the difference is time you will have to spend later.

Working it out for your own pipeline

1. Your doubling time. Same metric, measured the same way, at two points: daily arriving CI jobs, or test-result events. Divide, take log₂, divide elapsed days by that. From 400 to 3,000 daily jobs over 180 days is log₂(7.5) = 2.9 doublings, so about 62 days. That is a historical average, not a forecast.
2. The honest multiple of the proposed fix. A bigger instance is a multiple of cores, which is a multiple of throughput only if nothing serialises — the exact trap in the 70-day patch. Sharding across N is N× only if no shard is hot and nothing else is shared. Halving the work per job through caching or de-duplication is a genuine 2x, if you measure it.
3. Then compare D × log₂(k) against how long the durable fix needs, including validation and rollout — and separately check D × log₂(1/u), the time you have before anything is done at all. If the patch cannot cover the durable fix’s timeline on its own, that is worth knowing going in rather than discovering in month four.

If you’re not Anthropic

The 25x is not a forecast for anyone else. Anthropic is an extreme case: about 80% of merged code agent-authored, a test corpus up 10x, headcount roughly flat.

But the mechanism does not require 80%. Agents raise the rate at which changes and tests are produced, while everything downstream of code generation was sized for human-paced input. Test selection, the runner pool, artifact storage and the review queue each have their own relationship to that rate — not one shared multiplier — and whichever is tightest goes first.

The part worth keeping is not the multiple. It is that the cost of an agent lands in a budget nobody attributed to it. The token bill is itemised and arrives monthly. The CI bill arrives later, on a different team’s line item, and by the time it is legible you are five months into someone else’s firefight.

Companion reading

• What enterprises actually spend on AI coding agents — the visible half of the bill, and where the rest of it hides.
• Claude Code’s 33,000-token startup overhead — the per-session cost that scales the same way.
• Spotify’s 90% token cut, reproduced — what an optimisation actually returns when you measure it.
• How AI coding workflows converged in 2026 — why more changes arrive per engineer in the first place.
• Managing long-running agents — the operational end of the same problem.

Sources

1. Anthropic — Agentic coding is straining CI. Here’s how we scaled test impact analysis at Anthropic, by Sachin Malhotra, 14 September 2026. Source for every figure here: the 25x, 10x, 8x and 80%; the October 2025, February 2026 and March 2026 dates; the three patch durations and the symptom behind each; the two straight days of paging before the first fix; the single-writer constraint and the sharded and redesigned architectures; the three-weeks-one-engineer figure; and the four recommendations.
2. Anthropic — When AI builds itself. Context for what the share-of-code figures are measured against.

The arithmetic is ours, from one identity: a fix raising sustainable throughput by k adds log₂(k) doublings, while utilisation u separately determines the log₂(1/u) doublings already in hand. The 39.3-day figure is 182.6 days divided by log₂(25), an average over a window the post does not date. The late-2025 bound assumes utilisation was near the ceiling, which the two days of paging support, and that cores bought no more than 2x of throughput. The suggestion that the rate rose between the two periods additionally assumes the six-month window is the more recent one — the post does not say, and we flag it rather than rely on it.

FAQ

What actually happened? A test impact analysis service failed repeatedly under load. Paged in October 2025, cores doubled (held 70 days); sharded in February 2026 (29 days); daily restarts in March 2026 (under a day); then redesigned around stateless workers in three weeks by one engineer.

How much did load grow? CI jobs 25x over six months, tests 10x, on nominal headcount growth; separately, 8x code per quarter versus 2021-2025 with about 80% of merged code authored by Claude. Different baselines and windows — do not multiply them, and note the post does not date the six-month window.

How long does a capacity fix buy? It adds D × log₂(k) days, independent of how full you were. Utilisation sets a different quantity — the D × log₂(1/u) you already had. Acting early gives more total runway but does not make the fix itself worth more.

Can you derive their doubling time from the 70 days? Roughly, with assumptions. The paging establishes they were near the ceiling. But cores are not throughput on serialised work, and every multiple below 2 makes the implied doubling time longer — so the defensible claim is that late-2025 doubling time was 70 days or more, against the ~39 days implied by 25x over six months.

Was the growth accelerating? Probably, not provably. It requires assuming the six-month window is later than the October-to-March sequence, which the post does not state. The shrinking patch durations are consistent with it but are not three samples of one curve, since each addressed a different resource.

What should I take from it if I’m smaller? Not the 25x. That agents raise the production rate of changes and tests while everything downstream of code generation was sized for human pace — so the cost surfaces in a budget nobody assigned to the agent.