Anthropic's CI Jobs Grew 25x in Six Months. The Warning Was in How Fast Each Fix Stopped Working

The half-life of a fixHover to explore

Anthropic published its continuous integration numbers on 14 September 2026, in an engineering post by Sachin Malhotra about rebuilding the service that decides which tests to run. The headline figures travelled fast, and they deserve to. But the most useful thing in the post is a detail almost nobody repeated.

1. What was actually reported

Read those together rather than separately. The interesting relationship is not any single multiple — it is that 8x more code produced 10x more tests and 25x more CI jobs. The load did not scale with the code. It scaled with the code times the tests times the number of times anyone asks "is this still green".

2. The bottleneck did not disappear. It moved.

Malhotra's framing is the part worth quoting exactly, because it is more precise than the way it is usually paraphrased:

That is a sequence, not a slogan. Three stations, in order: writing, reviewing, verifying. Agentic coding removed the first constraint. Accelerating review removed the second. Neither of those created capacity — they relocated the queue to whatever came next in line and had none to spare.

This is the thing I would want a founder to take from the post ahead of any number in it. Removing a bottleneck does not produce throughput. It produces a new bottleneck, one station downstream, arriving faster than the old one did and usually in a system nobody has looked at for two years.

For most small teams the stations after "write the code" are review, CI, staging environments, preview deploys, and then — quietly, last, and most expensively — the humans who have to understand what shipped.

3. The number that is actually a warning

Anthropic patched the test impact analysis service three times before rebuilding it. The patches were all sensible. Here is how long each one lasted:

Seventy, twenty-nine, one.

No individual decision there was wrong. Doubling cores when a service is slow is correct. Sharding when a single worker saturates is correct. Restarting a service that accumulates lag is a normal thing to do on a Tuesday. Each fix was proportionate to the symptom in front of it.

The failure was that nobody was measuring the interval between fixes as its own signal — and that interval was collapsing by roughly half each time.

4. What the architecture got wrong

The service had two halves: a listener that records the result of every test from every CI run, and a selector that decides which tests a given pull request actually needs to run.

The constraint was that the listener was a singleton. A single writer had to maintain running history per test, which meant it could not be scaled horizontally — the only available moves were a bigger machine, then a partitioned set of machines, then restarting the machine. The three patches were not a failure of imagination. They were the complete set of options that architecture allowed.

The redesign — a three-week project — separated the concerns by moving the state out of the process:

After the cutover, the count of queued unprocessed job-result events stayed flat, where it had previously grown week over week. That flat line is the actual deliverable. Not faster — non-accumulating, which is a different property and the only one that survives another 25x.

5. The advice, and the caveat attached to it

Malhotra's recommendation is to design initial systems for 10–20x their perceived scale, where budgets allow, and to assume AI-driven load can reach 25x within two quarters.

Take the clause at the end seriously — where budgets allow is doing real work in that sentence. Anthropic is describing its own internal infrastructure at a frontier lab whose code is written by the model it sells. A seed-stage team copying "build for 20x" literally will over-engineer a product that has not yet found anyone who wants it, and that failure mode has killed more startups than CI lag ever will.

The portable version is narrower and cheaper:

The other stated lessons generalise cleanly and cost nothing: avoid making a critical path a singleton, instrument services so an agent can investigate them autonomously, and assert that the volume going into a queue matches the volume coming out. That last one is how you detect a system falling behind before a human notices it is stale.

6. The bill nobody published

Anthropic reported job counts. It did not report what those jobs cost, and for a founder that omission is the whole story, because CI is metered.

A 25x increase in CI jobs is a 25x increase in compute-minutes against a runner bill, modulated only by how well test selection works — which is precisely the service that was falling over. If your team adopts agentic coding and does nothing else, the observable sequence is: velocity rises, everyone is pleased, and roughly two months later someone asks why the CI line on the infrastructure invoice has quietly become one of the largest items on it.

This is the same arithmetic as the context tax, moved one system to the left. The cost of agentic development is not only the inference you buy. It is the verification load that the generated code creates downstream — tests to run, environments to spin, artefacts to build, reviews to hold — and that load grows faster than the code does.

7. Where the agents go next

The companion piece to the CI post describes Anthropic pointing Claude at CI/CD failures as an automated first responder — monitoring alerts, investigating across Grafana, log stores, PagerDuty, GitHub and Kubernetes, and proposing fixes. The reported figures: a median 14 minutes to first analysis, fastest cases inside 4 minutes, and one example resolved 3 minutes from recommendation to verification. In one case it identified 44 tests that a feature-flag toggle had silently stopped running.

The honest reading of that is symmetrical. It is a genuine answer to the operational half of the problem — and it is also agents being deployed to absorb load that agents created. That loop is not necessarily bad; most automation is a response to volume that earlier automation produced. But it is worth naming, because it sets the direction of travel: the cost of agentic coding is increasingly paid in systems that watch the systems, and those have an operating cost of their own.

8. What I would do with ten engineers or fewer

9. What I would not over-read

"Claude writes 80% of our code" is not a portable statistic. It describes a frontier lab with unusual tooling, an unusual codebase and an unusual incentive to demonstrate the claim. Treat it as evidence that the ceiling is high, not as a target your team is behind on.

8x code shipped is not 8x value shipped. The metric is code volume per quarter. Nothing in the post claims eight times the product outcomes, and code volume is a measure that agentic tooling inflates almost by construction.

Anthropic's timeline is the aggressive end of the distribution. Two quarters to 25x is what happens when a company is both the heaviest user and the vendor. Your curve will likely be flatter. The shape is the transferable part, not the slope.

This is a solved problem, and the solution is old. Stateless workers over a shared journal is not new architecture; it is standard distributed-systems practice that a fast-growing internal tool skipped, as fast-growing internal tools do. There is no novel technique here to acquire — only an ordinary one to apply earlier than feels necessary.

The honest summary

Anthropic's CI post is a good artefact precisely because it is unglamorous: an internal service outgrew its design, three competent patches bought progressively less time, and a three-week rebuild fixed it properly. Every part of that has happened at every company that has ever grown quickly.

What agentic coding changed is the clock. A system that would historically have taken three years to outgrow its architecture now does it in two quarters, and the warning signs arrive in the same order as before — just compressed to the point where the usual instinct, "patch it now and fix it properly next quarter", runs out of next quarters.

If you are shipping more code than you were six months ago, the constraint has already moved downstream of you. The only question is whether you find out from a dashboard or from an invoice.

Sources: Anthropic, "Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic" by Sachin Malhotra, published 14 September 2026 · Anthropic, "How Claude Tag serves as Anthropic's first responder for CI/CD failures" · Analytics India Magazine, "Anthropic's CI Jobs Grew 25x in 6 Months as Claude Wrote 80% of Code" · VentureBeat, "Anthropic says 80% of its new production code is now authored by Claude". The 8x, 80%, 10x and 25x figures, the three patch durations, the redesign description and the 10–20x design recommendation are Anthropic's own, as reported in the engineering post; the first-responder timings are from the companion post. Anthropic did not publish CI costs — the section on the bill is inference from job counts, and is labelled as such. The patch half-life framing, the reading of the bottleneck as relocating rather than clearing, and every recommendation are mine. For the previous station on the same line, see hiring the reviewer before the coder.

Related Posts

Hire the Reviewer Before the Coder: Building a Startup Engineering Team When Agents Write the Code (2026)July 31, 2026

Leading an AI-Native Engineering Team: What the Job Became When Output Stopped Being ScarceAugust 2, 2026

One Refactor Cost $14.29. Every File the Agent Read Stayed on the BillSeptember 2, 2026