In the ever-evolving world of software development, a paradigm shift is taking place. The traditional concept of 'per-developer environments' is being challenged, and the goalposts are being moved by an unexpected player: coding agents.
This article delves into the implications of this shift, exploring how the introduction of coding agents has transformed the very definition of a 'tenant' in the context of multi-tenancy.
The Evolution of Tenancy
Over the past six decades, multi-tenancy has undergone a fascinating transformation. Initially, a single mainframe was shared among an organization's departments, with the 'tenant' being the entire organization. Virtualization brought about a more granular approach, allowing each team to have its own virtual machine fleet, and the tenant became the team. Containers and Kubernetes further refined this, enabling platform teams to provide isolated environments on shared clusters, with the tenant now being the individual developer.
However, the emergence of coding agents has disrupted this trajectory. A developer running multiple agent sessions effectively has multiple changes in progress simultaneously, each requiring its own working version of the system. This has led to a realization: the tenant is no longer the developer, but the change itself.
Scaling with Changes, Not Headcount
The traditional capacity planning approach, based on headcount, is no longer sufficient. Changes are now arriving at a much faster pace, and the pressure on the system is immense. A Microsoft study revealed that developers using coding agents merged 24% more pull requests over four months, and this is just the tip of the iceberg. Each change, including iterations and abandoned attempts, needs its own space to run.
The Mispricing of Resources
The assumption that a person produces one stream of work at a time has led to mispricing of resources. A per-developer namespace, for instance, allocates one tenant slot to what is now multiple concurrent workstreams. Shared staging serializes these workstreams, creating a bottleneck. Seat-based capacity plans underestimate the actual demand, as they fail to account for the number of changes in progress.
The Wrong Tenant: Agents
It's tempting to think that the new tenant is the agent, but this is a misconception. Agents are interchangeable, and their collaboration or rotation across changes doesn't change the fact that it's the change itself that must be isolated. Giving each agent its own environment repeats the mistake of isolating workers, when it's the work that needs to be kept separate.
The Durable Unit: The Change
The change is the durable unit. It comes into existence when work begins, accumulates state that must be kept private, and needs to observe a version of the system that includes its own edits. It's torn down when merged or abandoned, ensuring that its state doesn't leak into other changes.
Applying Multi-Tenancy Playbook to Platforms
The requirements of change-level tenancy are not new. Any multi-tenant production service already operates under these rules: tenants share the substrate, each owns only what makes it distinct, creation is self-service and cheap, and resources are reclaimed immediately. However, these principles have not been applied to pre-production environments, where provisioning is often manual and isolation is achieved through duplication.
Redefining Tenancy for Change
A change tenant owns the services it modified, an isolated database branch, and nothing else. Everything else resolves against a shared, stable environment, continuously deployed from the main branch. This approach ensures that tenant creation is nearly free, and offboarding is automatic, tied to the change's lifecycle.
Measuring and Planning for Change
Platform teams need to shift their focus from measuring seats to counting changes. The practical shift involves counting open pull requests with recent activity, which often far exceed headcount. Pricing the marginal tenant in terms of cost and setup time reveals whether the platform is still operating at a person-level tenancy.
The Future of SDLC
With coding agents, the traditional definition of a tenant as a person or group of people breaks down. One person can now operate multiple workstreams, and these workstreams are created and abandoned at a rapid pace. The software development lifecycle (SDLC) must therefore redefine its tenant around the change, as the change is the stable unit of isolation in this new landscape.
Organizations that fail to adapt will see agent-generated changes queue up, waiting for infrastructure that can handle the load. Those that re-platform around change-level tenancy will unlock the full potential of coding agents, converting their throughput into merged work.
This shift is not just a technical challenge, but a cultural and organizational one as well. It requires a deep understanding of the changing dynamics of work and a willingness to adapt to new ways of thinking and operating.
