Anthropic engineer Sachin Malhotra published a blog post on September 14, 2026 with a blunt thesis: agentic coding didn't just make Anthropic ship more code — it broke the infrastructure that decides which tests should run on that code, three times in a row, before the team rebuilt it from scratch. The post, "Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic," is a rare inside look at what happens to engineering infrastructure once a company's own Claude Code agents are writing most of its production code.
The headline numbers are the point: Claude now authors 80% of code merged at Anthropic, engineers ship 8x as much code per quarter as they did between 2021 and 2025, tests grew 10x, and CI job volume grew 25x in six months. That is not a linear productivity bump — it is the kind of exponential curve that quietly turns a working system into a daily incident, and Malhotra's post is a case study in exactly how that happened to Anthropic's own test-selection service.
TL;DR
| Question | Answer |
|---|---|
| Core claim | Agentic coding moves the SDLC bottleneck downstream — from writing code, to reviewing it, to now running CI on it |
| Headline stats | Claude authors 80% of merged code; engineers ship 8x more code/quarter vs. 2021-2025; tests grew 10x; CI job volume grew 25x in 6 months |
| The broken service | Test impact analysis — decides which tests run on which PR, via a "listener" (records results) and a "selector" (chooses tests) |
| Why it broke | The two components had to stay in sync through effectively one writer, which doesn't scale past a certain throughput |
| Patch 1 | Bigger machine — lasted ~70 days |
| Patch 2 | Shard the listener by package, one worker per shard — lasted ~29 days |
| Patch 3 | Daily restarts to dodge memory limits — lasted less than a day, made the backlog worse |
| The real fix | A database-backed journal — any listener worker can process any result, stateless and horizontally scalable |
| Time to rebuild | ~3 weeks for one engineer, versus closer to a quarter a year earlier |
| Takeaway for other teams | Design test-selection and CI infrastructure for 10-20x scale from day one, not incremental headroom |
The bottleneck keeps moving downstream
Malhotra frames the story around a pattern explainx.ai has been tracking across the software delivery lifecycle all year: as AI absorbs one stage of building software, the constraint doesn't disappear — it relocates to whatever stage comes next.
Before AI wrote meaningful amounts of production code, the bottleneck was straightforward: humans writing code, the "build" stage. That's the stage Anthropic's own harness engineering post already described Claude eating into, with engineers running iterative loops instead of single prompts to ship 8x more code. Once Claude was authoring 80% of merged code, the constraint moved to PR review — a human (or an AI reviewer) had to read and approve code faster than agents could produce it. explainx.ai covered that shift directly in the debate over whether developers should stop reviewing AI-generated code line by line.
Now that agents assist with review too, Malhotra's post argues the bottleneck has moved again, to CI — the automated pipeline of builds, tests, and checks that gates every merge. It's the same displacement pattern OpenAI's own internal usage numbers hinted at in its September 2026 research acceleration post: once agents remove friction from one stage of a workflow, the next stage inherits the load, often faster than teams expect.
Why test impact analysis broke first
CI at Anthropic's new scale doesn't mean "run every test on every PR" — that would be prohibitively slow even before the 25x job-volume growth. Instead, Anthropic runs a test impact analysis (also called test selection) service that decides, per pull request, which subset of the test suite actually needs to run based on what changed.
That service has two components that have to agree with each other constantly:
- The listener — records the result of every test from every CI run as it completes, building up a history of which tests pass and fail against which code changes.
- The selector — reads that history and, given a new PR's diff, decides which tests are actually relevant to run.
The catch, as Malhotra describes it, is that keeping the listener and selector in sync effectively required one writer processing results in order. That's a reasonable design at normal throughput. It is not a design that survives 25x CI job growth in six months, and it broke in a specific, escalating sequence.
Three patches, each shorter-lived than the last
Anthropic's team didn't jump straight to a redesign — they tried three progressively more aggressive patches first, and the shrinking lifespan of each one is the most useful signal in the whole post.
| Patch | What it did | How long it lasted |
|---|---|---|
| Patch 1 | Moved the listener to a bigger machine | ~70 days |
| Patch 2 | Sharded the listener by package, giving each package its own worker | ~29 days |
| Patch 3 | Added daily restarts to work around memory limits | Less than a day — and made the backlog worse |
A bigger machine is the classic first move against any capacity problem, and it worked — for about ten weeks. Sharding by package bought real headroom by parallelizing the single-writer constraint across package boundaries, and it also worked — for less than a month. By the time the team reached for restarts as a stopgap for memory pressure, the fix actively made things worse: restarting a stateful, single-instance service under sustained load just re-triggers the same backlog it was meant to relieve, faster than it drains.
That decay curve — 70 days, then 29, then under 1 — is the signature of exponential growth outrunning linear patches. Each fix assumed the next plateau would look roughly like the last one. None of them did, because CI job volume wasn't growing at a steady rate; it was compounding alongside Claude's own rising share of merged code.
The redesign: stateless workers and a journal
The fix that actually held wasn't a bigger version of the same architecture — it was a different one. Anthropic gave the test-selection service a database, effectively an in-memory journal that any listener worker can write to independently. Instead of one writer maintaining order, any worker can process any test result, append it to the journal, and move on — the listener becomes stateless and horizontally scalable, the same property that makes web request handlers easy to scale by just adding more of them.
A small, separate consumer process rolls the journal into per-test history every few seconds, and the selector reads from that rolled-up history rather than the raw journal directly. That separation — a fast, dumb, append-only write path, and a slower, structured read path built from it — is a pattern familiar from event-sourced systems and log-structured databases, applied here to a CI-internal service that most engineering orgs would never think to design that carefully for.
The redesign reportedly took about three weeks for a single engineer. Malhotra's own framing of that number is the more interesting part: the same project would likely have taken closer to a quarter a year earlier — not because the problem was smaller, but because agentic coding tooling (including, implicitly, the same kind of Claude Code loops covered in Anthropic's harness engineering approach and in agent harness engineering more broadly) compresses the time needed to design, implement, and validate infrastructure changes of this kind.
What Anthropic's own engineer recommends for other teams
Malhotra's post closes with lessons aimed squarely at engineering teams adopting agentic coding themselves, not just Anthropic-specific trivia:
- Plan for the AI exponential, not linear scale. Assume growth in code volume, test count, and CI job volume will compound rather than trend steadily — the 70-day/29-day/under-1-day patch decay is the cautionary example.
- Design v0 for 10-20x scale, not comfortable headroom over current usage. A service built to handle "double our current load" will still get blindsided by a 25x jump in six months.
- Instrument services to act as Claude's "eyes and ears." If an agent is going to help diagnose or fix a production issue, it needs logs, metrics, and traces detailed enough to self-diagnose and hill-climb toward a fix — vague or missing observability defeats the point of having an agent look at the problem at all.
- Keep state out of the process from the start. A single-writer, stateful service is the exact shape that breaks first under compounding load; stateless workers backed by a shared store (the journal pattern here) scale by just adding more workers.
- Avoid single-instance critical services. Anything with no redundancy is a de facto single point of failure the moment load exceeds what one instance can handle — which, per this post, arrives faster than most teams plan for.
What this means for teams outside Anthropic
Most engineering teams are not running Anthropic's CI volume, but the underlying warning generalizes well before you get anywhere near 25x growth. If your team is adopting Claude Code in CI/CD pipelines — using the -p flag and structured JSON output for automated review gates — the same bottleneck-relocation pattern applies at smaller scale: agentic coding speeds up commits and review, and the next constraint your pipeline hits is very likely to be test execution time and test selection accuracy, not code quality.
Concretely, that means auditing three things now, before volume forces the issue: whether your test-selection or flaky-test infrastructure has a single-writer or single-instance dependency; whether your CI logs and metrics are detailed enough for an AI agent (or a human under time pressure) to self-diagnose a slowdown without spelunking through raw job history; and whether your capacity plans assume steady growth or compounding growth. Anthropic's own patch history is a useful gut check — if your fixes are lasting a shorter time with each iteration, that's the same signature Malhotra describes, and it's worth treating as an early warning rather than bad luck.
Honest limitations
- This is one company's account of its own infrastructure, published on Anthropic's own blog. There's no independent verification of the exact timelines (70 days, 29 days) or the "closer to a quarter" estimate for how long the redesign would have taken pre-agentic-coding.
- The 80% "code authored by Claude" figure describes Anthropic's own internal usage, which is unusually aggressive Claude Code adoption even by industry-leading standards; most engineering orgs are not yet at that ratio, so the CI strain described here is a preview of where heavy adopters are headed, not a description of typical current CI load.
- The post doesn't quantify cost — engineer-time saved, infrastructure spend, or the cost of the outages/backlogs caused by the three failed patches before the redesign landed.
- "Test impact analysis" as a category predates this post — Anthropic didn't invent the technique, and the post is specifically about scaling an existing internal implementation of it under new load, not introducing a new method.
Related on explainx.ai
- Claude Code in CI/CD pipelines: the -p flag, JSON output, and automated review
- Anthropic engineer: stop prompting Claude, build loops that prompt themselves
- Should developers stop reviewing AI-generated code?
- OpenAI's research acceleration post: 3.1 agent-workdays per human
- Agent harness engineering: when the model stays fixed and the scaffolding wins
- AI resolves your incidents — are you still able to?
- Claude Code pricing guide 2026
Primary source: Sachin Malhotra, "Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic," Claude blog, September 14, 2026.
This post reflects Anthropic's blog post as published September 14, 2026. Figures on code authorship share, CI job growth, and patch timelines are as stated in that post; explainx.ai has not independently verified Anthropic's internal metrics.