CI Jobs Rose 25x in Six Months. Nobody Had Agreed to Own the Service That Broke.

Anthropic saw “a 25x increase in CI jobs over a six month period.” Sachin Malhotra published that number in September 2026, alongside two others that explain it: Anthropic engineers now ship on average 8x as much code per quarter as they did from 2021 to 2025, and Claude authors 80% of that code. The test suite grew with it. “The amount of tests across our codebase grew 10x and we added a nominal amount of engineers.”

So the headcount did not move much. The load did, by a factor most capacity plans never contemplate.

What broke was the test impact analysis service, the thing that decides which tests a pull request actually needs to run. It was patched three times. Those patches “lasted 70 days, then 29 days, and then less than a day respectively.” Roughly three months of runway in total, if you add them up, and the third patch lasted less than a day.

The Interesting Failure Sits Above the Service

Malhotra wrote one sentence that sits outside test selection entirely: “Even when the trend line was clear, ownership was murky. No one wanted to own another piece of infrastructure.”

That is the part worth sitting with. The trend line was visible. The engineering team could read a graph. My reading of why the service degraded until it needed a rebuild: no team had signed up to be responsible for it, and a system nobody owns gets patched. Rearchitecting is what owners do; patching is what you do to someone else’s problem when it lands in your week.

Any organization running agentic coding is likely to have services sitting in this position. Build orchestration, test selection, artifact caching, flake quarantine. These were minor concerns when a small team opened a handful of pull requests a week. At 25x job volume they carry weight, and the org chart still describes them as minor.

The Degradation Was a Control Failing Quietly

Here is what the service was actually doing while it was broken. It was “using stale data to decide what to run and what not to on PRs.” Malhotra is careful to bound the claim, and the bound matters: it “doesn’t mean CI never ran on those PRs.”

Both halves belong together. The selector stayed up. It kept making decisions with inputs that no longer reflected the codebase, which is a stranger and more uncomfortable failure than an outage. An outage announces itself. A test-selection service running on stale data returns green, on time, with the right shape of report, while the relationship between “these tests passed” and “this change is safe” quietly weakens.

Think about what test impact analysis is in governance terms. It is the control that decides how much assurance a change receives before it merges. Treat it as the gate it is, with the scrutiny a gate deserves. When it degrades, your evidence of safety degrades with it, and the pipeline stays silent about the evidence getting thinner.

This rhymes with comprehension as the bottleneck: a control that reports all-green while the assurance behind the green thins out.

Two Rules That Transfer

The rebuilt architecture is Anthropic’s, sized for Anthropic’s problem. Malhotra also says the new design is “more expensive to run” and does not quantify by how much. Copying the architecture is beyond most teams. Two operating rules are within reach.

The first is a capacity assumption, stated verbatim: “assume your architecture will be at a 25x load within two quarters.” That is a planning posture. It converts a capacity question from “what do we expect” into “what survives if we are wrong by an order of magnitude?” Applied honestly, it kills a lot of designs at the whiteboard, which is where you want them killed.

The second is a conservation check: “ensure that the same number of CI jobs coming in equals the same going out.” A one-line invariant. Jobs in equals jobs out. If they do not match, something is being silently dropped.

That second rule is the one I would implement first, because it is cheap and it makes the expensive failure loud. Check whether your pipeline has one. A duration dashboard and a green checkmark, which is what the pipelines I have seen expose, cannot detect a job that was never scheduled.

What PostHog Adds, and What It Does Not

PostHog published its own numbers in September 2026. Ian Vanagas reported that the company “went from 1,441 PRs merged in January to 4,869 in August while only growing engineering headcount 10%,” and that agent-opened pull requests moved “from around 20% of our monorepo PRs being opened by agents to 70%” over four months. That is roughly a 3.4x rise in merged PRs against a 10% headcount increase.

It would be convenient to file that as a second data point for CI strain. The fit is looser than that. PostHog’s named constraint is review and judgement capacity, the human ability to evaluate what the agents produced, rather than the infrastructure that builds and tests it. That qualifies the infrastructure thesis rather than confirming it. Two companies with steeply rising volume named two different things as the binding constraint, which is a useful warning against assuming you already know where your own throughput will jam.

Sean Goedecke argues, in a forecast rather than a measurement, that “fast tool calls are going to be the difference between a near-instant response and having to wait several minutes.” He offers no organizational measurement for it. Treat it as a hypothesis about where latency cost lands next, and hold it apart from evidence of realized cost.

One thing none of these sources says: that headcount falls. PostHog grew engineering by 10%. Anthropic “added a nominal amount of engineers.” The cost did not leave the organization. It moved into infrastructure that nobody had agreed to own, which is a pattern we traced from the individual engineer’s side in the cost reality of 2026 and from the per-interaction side in the economics of computer use.

Do This Now

Pick your build and test pipeline and answer three questions in writing.

Who owns the test-selection logic? Go past “who wrote it.” Who is accountable when it degrades, who gets paged, and whose roadmap absorbs the rebuild. If the honest answer is that it belongs to whoever touched it last, you have reproduced the Anthropic precondition ahead of the volume.

Does jobs-in equal jobs-out? Instrument it this sprint. Count the jobs the pipeline should have run, count the jobs it actually ran, alert on the difference. If you cannot produce those two numbers today, the class of failure that three patches did not fix is currently invisible to you.

What does your architecture do at 25x? Skip 2x. Take the 25x number as a stress assumption and walk one pipeline through it. Where it falls over first is your next owned service. Naming an owner now costs a conversation. Naming one later costs a rebuild.

The volume is the easy part to see. Ownership is the part that stays murky until the graph forces it, and by then you are patching.

---

This analysis synthesizes Agentic coding is straining CI. Here’s how we scaled test impact analysis at Anthropic (Anthropic, September 2026), What happens to engineers when AI writes all the code? (PostHog, September 2026), and Slow developer experience will bottleneck fast models (Sean Goedecke, September 2026).

Victorino Group helps engineering organizations assign ownership and instrumentation to the build and test infrastructure that agentic coding puts under load. Let’s talk.