If agents write a growing share of your code or pipeline output, your infrastructure will not scale linearly with that growth. Anthropic's CI job volume grew 25x in six months once Claude wrote 80% of code changes. What nearly broke the pipeline was not compute but one single-writer service, and each capacity patch bought less time than the last.
"},{"heading":"Short answer","html":"Agent-driven load compounds: engineers ship more changes, and each change generates more downstream work. A service built for human-paced load, especially one with a single writer, degrades from slow to silently wrong before anyone sees it is out of headroom. Capacity patches buy shrinking runway against that curve. The fix that held was structural: stateless, append-only ingestion, with aggregation moved to a separate layer that scales horizontally.
"},{"heading":"Builder model","html":"Test-impact analysis needs a history of which tests exercised which code and a fast way to select the minimal test set for a change. The failure was in writing that history, not in selection. A single writer applying every result is simple and correct at low volume, but its ceiling is one process's write rate, regardless of hardware elsewhere. As input grows, the gap between "result happened" and "result recorded" widens, and every reader of the record works from data that is increasingly wrong, not merely slow.
\nThe redesign is a general pattern. Recording an event becomes append-only and shardable: any worker accepts and journals any result, holding no state. Aggregating events into queryable history becomes a separate consumer that rolls the journal forward every few seconds. Ingestion loses its single-process ceiling, and aggregation lag becomes a tunable staleness bound instead of an unbounded backlog.
"},{"heading":"How to apply","html":"See agent cost and agent reliability for operating agent-driven pipelines at scale, and agent tracing for observability that surfaces growing lag before it causes undetected failures.
"}],"evidence":[{"id":"anthropic-2026-ci-test-impact-analysis","kind":"primary-doc","tier":"primary-doc-backed","title":"Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic","note":"Anthropic's account of its own CI: job volume up 25x in six months, Claude writing 80% of changes, 8x more code per quarter. A single-writer test-selection listener fell behind; 20 minutes of lag left tens of thousands of results unapplied, letting failures merge. Patches lasted about 70 days, 29 days, then under a day. A stateless, journal-based redesign, built by one engineer in three weeks, flattened the backlog. First-party, single-company report.","added":"2026-09-16","url":"https://claude.com/blog/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic","sid":"86abcc6f17fc520e"},{"id":"agentic-code-ci-scaling-editorial-synthesis","kind":"editorial-inference","tier":"editorial inference","title":"LLM Digest synthesis","note":"The numbers are Anthropic's own pipeline. The lesson extends to any stateful aggregation service in an agent-driven critical path, such as a vector-index writer, feedback-label store, or eval-result aggregator: a single-writer or unshardable component whose input rate scales with agent output, not headcount.","added":"2026-09-16"}],"related_topics":[{"slug":"agent-cost","title":"Agent token costs are unpredictable and easily run away"},{"slug":"agent-reliability","title":"Agents give fluent, confident-looking output even when it's wrong"},{"slug":"agent-tracing","title":"Tracing and trace analysis for agent runs"}],"related_playbook_cards":[],"related_storylines":[]}