Anthropic's engineering team ships eight times as much code per quarter as it did between 2021 and 2025. Claude writes 80 percent of that code and also plays a significant role in reviewing and approving pull requests. The test suite across the codebase grew ten times while the engineering headcount increased only nominally. The combination drove CI job volume up twenty-five times in six months, and it nearly broke the company's test impact analysis service in the process.
The Problem: A Singleton Service Facing Exponential Load
Anthropic runs a deterministic test impact analysis service that decides which tests execute on each pull request, based on past performance and package relevance. The approach avoids running every test against every change, which is common at many organizations but does not scale once CI volume crosses a threshold. The service depends on two components staying in sync: a listener that receives test results and a selector that uses those results to make decisions about future runs.
The original architecture ran everything as a single process. A singleton listener consumed results and wrote them to an in-memory store, which meant a single writer had to order test results correctly. That design prevented horizontal sharding. By October 2025, the service was already showing strain, and the on-call team was paged for two consecutive days.
The root cause was straightforward. With multiple CI jobs running every second, the listener increasingly fell behind the pull request queue. In an AI-native software development lifecycle, even small lag creates downstream problems. Twenty minutes of listener lag translates into tens of thousands of test updates not being applied to the selector, which means the selector makes decisions based on stale data. The practical effect was not untested code reaching production, but the selector running tests that were already flaky or widely failing, wasting CI time and creating noise.
Three Patches and Their Expiration Dates
The first fix was simple: double the CPU cores running the service. It worked, but the team knew it was temporary. The second fix, applied in February 2026, parallelized the listener by package. Claude generated the code to split each package's state into its own shard with a dedicated worker, so multiple packages could process results concurrently. That bought twenty-nine days before the process hit its memory limit on most weekday afternoons.
The third fix was the most telling. Daily restarts were keeping the service alive, but they also caused the listener to fall gradually further behind. When lag exceeded an hour, which happened several times, the selector operated on outdated information for extended periods. The team was spending increasing time on maintenance that did not address the underlying architectural problem.
Throughout this period, an engineer ran a long-running session in an internal version of Claude dedicated to monitoring the service. Anytime the listener lag exceeded fifty thousand jobs, Claude would ping the engineer and resume the conversation on next steps. Claude consistently argued for a full overhaul, but the team kept settling on patches. That pattern lasted months.
The Redesign: Stateless Workers and an In-Memory Journal
In March, the team finally committed to rebuilding the service. The new architecture added an in-memory data store as a shared journal. Any listener worker can now process any test result, append it to the journal, and move on without holding state in memory. The workers are stateless, which means they can be horizontally scaled without coordination overhead. A small separate consumer process rolls the journal up into per-test history every few seconds, and the selector queries that history to make its decisions.
The redesign took three weeks for a single engineer. The same project would have taken roughly a quarter a year earlier, before AI-assisted development tools matured. Claude handled much of the fine-tuning, including sizing the journal and tuning the number of workers, largely autonomously. The service has remained stable since deployment.
What Anthropic Learned About Planning for Exponential Growth
The engineering team identified several lessons from the experience. CI job volume increases exponentially as the number of agents per engineer rises and as automated pull request approval becomes more sophisticated. Claude's preference for smaller, more granular pull requests increases the total number of CI jobs in a given day. The activity floor is also raised because agents push code overnight and on weekends, though bursts still occur when human engineers drive and approve pull requests.
The team's advice to other engineering teams: assume your architecture will face a twenty-five times load increase within two quarters, whether you build or buy your CI tooling. Over-engineering as a concept is fading, or at least the bar is moving significantly higher. Starting with designs that account for ten to twenty times the perceived scale is reasonable as long as the budget supports it.
Instrument services to give AI agents visibility into system behavior. The monitoring setup allowed Claude to incrementally identify and fix problems faster than the team could manually. The team also recommends keeping state out of critical processes from the start and avoiding single-instance deployments for any service where the load trajectory is uncertain.
What This Means for Engineering Teams
Anthropic's experience is an early signal of a problem that will reach more organizations as AI coding agents become standard tools. The volume of code, tests, and CI jobs is not growing linearly. It is growing exponentially, driven by agents that generate code faster than humans, approve pull requests with less friction, and operate around the clock. Infrastructure that was adequate for human-paced development cycles will not survive the transition.
The specific scaling techniques Anthropic used, bigger machines, parallelization, process restarts, are common and not the main takeaway. The lesson is that each of those techniques bought a fraction of the time it would have bought a year earlier. The exponential compressed the window for half-measures. Teams that anticipate this trajectory and plan their architecture accordingly will waste less time on patches that do not compound.