AI coding agents force a rethinking of development platform infrastructure from per-person to per-change

Sixty years of infrastructure evolution compressed multi-tenancy into ever smaller units: from entire organizations sharing a mainframe, to teams running virtual machines, to individual developers commanding container namespaces on shared clusters. Platform engineering in the 2020s settled on what seemed like an endpoint—one isolated environment per developer.

But the arrival of AI coding agents has shattered that assumption. A developer supervising multiple agent sessions now runs dozens of concurrent code changes simultaneously. Anthropic's engineers recently ran nearly 2,000 Claude Code sessions across two weeks while building a C compiler, and tools like Cursor encourage developers to spawn as many parallel agents as they need. Each workstream demands its own isolated workspace. Suddenly, a 50-person team can generate the infrastructure load of a 300-person organization.

The old seat-based math no longer works#

When developers worked sequentially, capacity planning by headcount made sense. A single engineer produced roughly one change at a time, so isolating people meant isolating work. That relationship has inverted. Research from Microsoft on command-line coding agents found developers merged around 24% more pull requests over four months. Yet merged code understates the true load—each pull request arrives after multiple iterations and abandoned attempts, each consuming resources.

A team of 50 engineers, each supervising a handful of concurrent agent sessions, can easily have hundreds of changes in various validation stages on a peak day. Traditional per-developer namespaces, shared staging environments, and seat-based capacity budgets all collapse under this load.

The tenant must now be the change, not the agent#

The instinctive fix—giving each agent its own isolated environment—repeats an old mistake at a new scale. Agents are interchangeable workers: two can collaborate on a single change, one can move between several changes, and a crashed agent gets replaced mid-task without downstream impact. What must remain isolated is not the worker but the work itself.

The change becomes the durable unit requiring isolation. It emerges when development starts, accumulates state no other workstream should access (schema migrations, test data, modified service versions, validation messages), and disappears when merged or abandoned. Every change needs to observe and modify a version of the system that includes only its own edits, not those of concurrent changes.