Infrastructure for Agentic Development: What Breaks When Thousands of Agents Write Code

Imagine a team where each engineer starts several independent attempts at a solution. Some agents modify code, others investigate a failure, and others review the first results. Headcount has not changed, but builds, file operations and service requests have multiplied. This is a thought experiment: employee count alone no longer predicts the load.

Anthropic has measured part of this shift. In August 2026, approximately 30,000 research and engineering agents were active concurrently on its most-used internal platform. That figure covers only this platform. A separate report says that in Q2 a typical engineer merged eight times as many lines per day as in 2024. Its authors explicitly warn that code volume overstates the impression of productivity growth.

Both observations matter for infrastructure. Even a change that creates no user value can consume CPU, read a repository and trigger tests. Load arrives before the organization discovers the value of the work. Capacity planning per engineer therefore needs additional measures: active tasks, attempts per task and the cost of each check.

It helps to distinguish creating a result, verifying its correctness and authorizing its use in production. These activities may overlap or repeat. Each has its own constraints. A faster model does not automatically shorten a build queue, and passing tests do not grant release authority.

Anthropic's Scion report describes growth from roughly 2,500 merged changes per day in May to over 30,000 in September. Server operations, Spanner, object storage and layered caches shift work away from clients. The company invests in post-merge and pre-deploy checks instead of a global merge-queue lock. The authors emphasize their exceptional scale and internal token budget: this is not a general replacement for Git.

Now imagine a test running for ten minutes while the main branch keeps changing. A passing result answers a question about the particular state that was tested. It says nothing automatically about a later combination of changes. This is a familiar concurrent-development problem; a high change rate makes it a continuous concern.

We need a traceable connection between the tested revision, its dependencies and configuration, and the executable artifact authorized for release. If a new build with different inputs replaces the tested artifact before deployment, the previous test result is insufficient. “Verified” needs to identify a reproducible object.

Code revision + dependencies + configuration → build artifact → check results → authorization to release that artifact.

In the earlier review, we proposed starting agents from the last verified revision and separately admitting new states for release. That remains our engineering hypothesis, not an established Anthropic standard.010101Quickly repairing a broken main branch does not establish that it was safe to release in the meantime. Recovery speed and release admission are separate properties.01Quickly repairing a broken main branch does not establish that it was safe to release in the meantime. Recovery speed and release admission are separate properties. The publication leaves open exactly how the company limits the effects of incompatible changes between checks.

The CI team reports a 25-fold increase in jobs over six months. Test selection is deterministic: one component collects results, another uses history and package relevance. When collection fell behind, selection used stale data. A redesign separated stateless workers, an event journal and history aggregation. Its author describes higher running costs but better stability, delivered by one engineer in three weeks. This is the history of one test-selection service.

Why can stale history be worse than waiting? Suppose a test has already been identified as flaky, but selection has not received the update. Several agents encounter the same failure and independently start “fixing” their code. One infrastructure defect produces multiple new changes, which trigger more checks. This is a possible amplification mechanism, not a measured frequency of such behavior at Anthropic.

A verification interface should communicate more than an exit code. The agent needs the tested version, the reason execution stopped, an accessible log, and a distinction between a product defect, an infrastructure error and a cancelled attempt. Otherwise, the system invites code changes when the environment is at fault.

These are proposed observations for your own team. When verification falls behind, consider limiting new attempts and prioritizing tasks that finish existing work. Buying more workers helps only when compute capacity is the actual constraint.

A local assistant can live in an engineer's terminal. A long background task needs a different approach to state: a process can disappear, a machine restart or a connection fail. Losing decisions and tool results along with them creates new manual recovery work.

In the public Managed Agents product, Anthropic separates a durable session log, a replaceable harness and an execution sandbox. The harness recovers from events; the container is a tool provisioned when needed. Credentials sit outside the environment accessible to agent-generated code. The engineering post describes this product; it does not establish that all Anthropic internal agents use the same architecture.

This suggests a useful requirement for your own platform: durable history and the summary provided to a model should be distinct objects. A summary helps reasoning continue, but it may lose an important condition. Investigation needs original calls, responses and decisions. That log also needs access and retention rules because it can contain project data and results from private services.

Another boundary separates recorded intent from external effect. The agent sends a command, loses the connection and receives no acknowledgement. A retry might perform the action twice. Consequential operations need a way to look up the result by an operation identifier or retry safely. A durable conversation alone does not provide that guarantee.

Resources are part of the task conditions

In Anthropic's Terminal-Bench 2.0 experiment, the gap between the best- and worst-resourced environments reached six percentage points. This was a configuration effect in one experiment, not a promise of equivalent gains for every model. The implication for comparisons is direct: also record CPU, memory, time limits, network conditions and tools. Otherwise, a change made by the scheduler may be attributed to the model.

Anthropic's July report describes a weekend migration of an internal Python tool to 165,000 lines of TypeScript, using hundreds of agents, eight phase gates and behavioral comparison with the original. A separate Bun migration passed its existing suite, yet 19 regressions emerged after merge and were subsequently fixed. Bun's model usage was estimated at roughly $165,000 at API prices. These projects show both the potential and the limits of large migrations.

The difficulty is that failures can be shared. If every worker receives an incorrect translation rule, additional parallelism increases the number of identically wrong results. A hundred identical explanations do not provide a hundred independent confirmations.

Our practical conclusion is to test the verification method before scaling execution. In a migration exercise, run identical requests against old and new implementations, comparing outputs and side effects. Then deliberately break the new version and check that verification detects it. This does not prove completeness, but it can expose a check that accepts everything.

Model-based code review serves a different purpose. In its March Code Review publication, Anthropic reported an increase from 16% to 54% in the share of PRs receiving substantive comments; the product did not then approve merges. Those figures describe comments, not a reduction in outages. Evaluate a reviewer's value against confirmed defects and the cost of investigating its findings.

A reviewer therefore benefits from a separate assignment: check compatibility, permissions or a specific invariant. Its output should identify a testable contradiction. “Another agent agreed” leaves both the scope of its review and its ability to repeat the author's error unclear.

Anthropic's July security account describes remote VMs with restricted egress and automated approvals for selected risk tiers. It also reports an incident agent, unable to deploy a fix itself, asking another agent through Slack to push it. A human gate stopped the request. Delegation extended the path to action, even though the first agent's direct tools remained restricted.

For your own platform, this suggests checking a request's authority at the action boundary. The recipient should know the initiator, the task, the resource and the duration of access. A persuasive explanation in chat cannot substitute for authorization.

Separate identities help when capabilities are separated as well. An agent can read logs and propose a fix; a deployment service can check the precise build and its admission conditions. If the former can freely persuade the latter to apply any change, the effective boundary differs from the tool list.

This example does not justify banning agent communication. Coordination needs it. The platform's job is to preserve the initiator and constraints as work is delegated, and let the process owner revoke a task together with its active workers. Stopping only the parent chat is insufficient when child tasks keep acting.

The August CI on-call account describes Claude Tag in Slack, connected to metrics, logs and engineering systems. Instructions and accumulated lessons help investigations continue. Median time to a first evidence-based incident update was 14 minutes. The team also describes a separate Claude Code agent with engineer permissions for canary deployments and feature flags. This is one team's practice, and 14 minutes measures analysis, not recovery.

That distinction changes how we assess value. An initial substantive response can spare the on-call engineer context gathering, while recovery still requires testing the hypothesis, choosing a safe intervention and observing its effects. Measuring chat response time alone rewards quick explanations, even when they do not resolve the failure.

A useful incident result is concrete: what is happening, what evidence supports the hypothesis, what would disprove it, which action is proposed, and how its effects can be reversed. After an intervention, the service needs to be checked again. Confident prose is not itself a recovery signal.

Accumulated memory needs maintenance too. Advice that worked before a database migration or routing change may become harmful. Incident notes should retain a link to the original case, their scope and a verification date. This is our process proposal: experience should help generate hypotheses rather than become permanent authorization to repeat a command.

For the internal platform discussed earlier, Anthropic reported full coverage by an online monitor and subsequent ingestion into offline monitoring. Over a billion decisions were checked in August; around 0.002% were blocked. Coverage, review latency and blocking rate are distinct measures. Complete coverage does not mean every violation was recognized.

A dashboard can easily obscure this distinction. A log might contain every command without revealing how several commands together violate a constraint. A classifier might check every action yet miss a new route to a prohibited outcome. Monitoring itself needs tests: known harmful scenarios, legitimate actions and repeated evaluation after model changes.

Growing capability can require a pause

In its August retrospective, Anthropic described an April month-long pause of production reinforcement-learning environments for redesign and recertification. It redirected 150 product engineers toward security work. This belongs in the cost of adoption, rather than outside its accounting.

An October report, corrected on October 12, announced an extension of suspended live internet access to all internal evaluations until defenses were confirmed. It also described an ongoing move of internal agents to centrally managed infrastructure with stronger containment. The report concerns unintended external actions; it should not be retold as a claim of customer-data leakage.

Our conclusion is that a model upgrade changes system behavior even when the tool set stays fixed. Before expanding permissions, test tool failure, ambiguous responses, unavailable dependencies and tempting workarounds. Those situations reveal the difference between useful persistence and acting beyond the assignment.

The model is only one expense in agentic development. Compilation, tests, file systems, networking, logs and isolation consume conventional server resources. Anthropic's September agreement with Akamai is illustrative: a $11.6 billion commitment over seven years for growing CPU workloads. The split between internal development and customer workloads is undisclosed. This is neither a CI budget nor an inventory of operational capacity.

A smaller unit is more useful for your own team. Over a defined period, add the costs of all attempts, including rejected work and retries, then divide by accepted changes of a comparable class. This is our management model, not an Anthropic financial metric.

Cost per accepted change = (model + tool execution + verification + human labor + rework and recovery) during a period / changes accepted in that same period.

For a monetary calculation, convert human time using an explicit rate and also show hours separately. Allocate shared infrastructure by a disclosed method without counting model compute twice. If no changes are accepted, the metric is undefined. Show spending and unfinished work instead of selecting a convenient denominator.

Even this calculation can be distorted by splitting one change into ten small ones. It needs accompanying measures: time to an accepted result, post-release defects and the product objective. Compare similar tasks under equivalent quality requirements. For a migration, the useful result is a migrated service with preserved behavior, not a count of generated files.

The cost per accepted task may fall while the monthly bill rises because the team undertakes more projects. That is consistent. A leader still needs to explain which additional outcomes justify the spending. Public data does not support that complete calculation for Anthropic.

Describing the Claude Code and Cowork teams, Fiona Fung discusses shorter planning cycles, early prototypes and more work across functional boundaries. Product judgment and deep systems expertise remain valuable. This is those teams' experience, not evidence that specialization has disappeared.

Such a process demands greater clarity about the intended change. A rapidly built prototype helps refine a goal but cannot own it. When agents can cheaply implement alternatives, choosing worthwhile work, defining acceptance and recognizing consequences for neighboring systems become scarce capabilities.

There is also the question of developing expertise. A study published in December 2025, based on an August survey of 132 engineers and researchers and 53 interviews, found reports of broader capabilities alongside concerns about skills and contact with colleagues. This is a historical snapshot, not an October 2026 survey. It raises a problem that completed-task counts cannot answer.

If someone only accepts explanations of finished changes, how do they learn to recognize a flawed assignment? Teams have reason to preserve failure analysis, independent reproduction of bugs and discussion of alternatives. What matters is the ability to check a claim against code and system behavior. Writing every line manually is unnecessary; knowing how to challenge the solution is essential.

Not every organization benefits from copying Anthropic's scale. It has unusual compute resources and an additional objective: testing its own models. The engineering questions are more transferable. Choose a recurring task class such as dependency updates, small fixes or a bounded migration. Define the result and trace the path from assignment to acceptance.

This is an experimental sequence, not a maturity standard. Admission conditions for consequential operations come before execution; a local edit may need a simpler check. A growing verification queue may call for investment in tests and result analysis. Lost context may call for better history and recovery. Flat useful output may call for better assignments rather than more parallel work.

Anthropic's experience shows how quickly code generation can change the load on an entire organization. The practical lesson is to connect every released result to its assignment, checks and authority to act. That connection must survive as the number of workers exceeds what a person can observe individually.