Per-developer environments hit their ceiling the day one engineer ran five agents

An argument published on The New Stack holds that the target state most platform teams have been building toward since roughly 2020, one isolated environment per developer, is already the wrong unit ^[2]. The reason is arithmetic rather than fashion: the per-seat design assumes a person produces one stream of work at a time, and a developer supervising five agent sessions has five changes in flight, each needing its own working version of the system ^[3][4].

The trajectory is not new. Tenancy has been shrinking for sixty years, from the organization on a time-shared mainframe, to the team with its own virtual machines, to the developer with a namespace on a shared cluster ^[1]. What changed is the denominator. Anthropic's engineers, building a C compiler with a fleet of parallel agents, ran nearly 2,000 Claude Code sessions over two weeks, according to the piece ^[5]. Cursor's documentation tells developers to run as many agents as they want in parallel ^[6]. A Microsoft study of command-line coding agent adoption found developers merged roughly 24% more pull requests over four months ^[7], and merges are the visible tail: every one is preceded by iterations and abandoned attempts that also had to run somewhere ^[8].

The seat math against the change math is where this gets expensive. The article's worked example is a 50-developer organization where each engineer supervises a few agent sessions, producing hundreds of changes in some stage of validation on a busy day, which is the tenancy demand of a 300-person engineering org sitting on a 50-tenant platform ^[9]. That is a factor of six between the number you planned for and the number you are serving ^[10]. Each of those changes wants data it can migrate and write to without asking permission, its own view of shared message topics, and a running version of the services it touched ^[11].

Every layer built on the person-tenant assumption misprices that. A per-developer namespace hands one tenant slot to five concurrent workstreams, a five-to-one oversubscription baked into the design ^[12][15]. Shared staging serializes the same five into a single queue ^[13]. Seat-based capacity plans budget for the number of employees while the bill tracks the number of changes in flight ^[14].

The obvious replacement tenant, the agent, is the wrong one. Agents are interchangeable workers: two can collaborate on one change, one can rotate through five, and a crashed agent gets replaced mid-task without anything downstream noticing ^[16]. Isolating them repeats the original error at higher volume, isolating workers when the thing that must not leak is work ^[17]. The durable unit is the change, which exists from the moment work starts, accumulates state no other tenant should see, needs to observe a system that includes its own edits and nobody else's, and is torn down on merge or abandonment ^[18].

Naming the change as the tenant sets three testable requirements: creation must be near free, isolation must cover only what changed, and lifecycle must be bound to the change rather than to a ticket or a timer ^[19]. Measure your own platform against them. If provisioning an environment takes a ticket, if teardown waits on a timer, or if isolation is a whole cluster copy rather than the delta, the seat-shaped design is still in place. The discipline is not exotic, and anyone operating a multi-tenant production service already applies it: shared substrate, private ownership of only what makes a tenant distinct, self-service and cheap creation ^[20].