The software development world is undergoing a seismic shift, and it’s not about the tools we use—it’s about the very foundation of how we think about infrastructure. For decades, the mantra was 'one developer, one environment.' But what if that model is now obsolete? What if the real bottleneck isn’t the number of people writing code, but the sheer volume of changes they’re trying to test at once? This isn’t just a technical problem; it’s a philosophical one. We’ve spent the last 60 years shrinking the 'tenant' in multi-tenancy—from organizations to teams to individual developers. Now, coding agents are forcing us to shrink it again, down to the level of a single change. And that’s where the chaos begins.
Let’s start with a simple truth: humans are terrible at multitasking. A developer working on five different features at once? That’s not efficiency—it’s a recipe for confusion. But coding agents? They thrive on parallelism. Anthropic’s engineers ran nearly 2,000 agent sessions in two weeks while building a C compiler. That’s not just impressive; it’s terrifying. If you’ve ever tried to debug a system where a dozen versions of your code are running simultaneously, you know the nightmare. The problem isn’t the agents themselves—it’s the assumption that our infrastructure can keep up with their pace. And let’s be honest: most platforms are still built for humans, not machines.
Here’s where things get interesting. Traditional capacity planning is based on headcount. You allocate resources per developer, assuming one task per person at a time. But when agents are involved, that math falls apart. A 50-person team with three agents each suddenly has 150 active workstreams. Each of those needs a runtime environment, a database branch, and a way to isolate its changes. The result? A platform that’s designed for 50 tenants is now being asked to handle 300. And that’s not even accounting for the abandoned experiments or the ones that get merged before they’re fully tested. The old model is like trying to fit a modern city into a medieval castle—eventually, the walls will collapse.
So what’s the solution? The answer lies in redefining the 'tenant' itself. Instead of focusing on people or agents, we need to treat each change as a tenant. This isn’t just a technical tweak—it’s a complete rethinking of how we design systems. A change tenant would own only the parts of the system it modified, with isolated data branches and shared dependencies. Think of it like a SaaS tenant: they don’t own the entire application, just their data. Similarly, a change tenant doesn’t need a full copy of the system—it just needs a view that includes its modifications. This approach makes tenant creation nearly free, which is critical when you’re dealing with hundreds of concurrent changes.
But here’s the kicker: this isn’t just about efficiency. It’s about accountability. When a developer is responsible for their own environment, they’re more likely to clean up after themselves. But when you hand off that responsibility to an agent, you’re creating a ticking time bomb. Orphaned environments, unmerged changes, and data leaks become the norm. The only way to avoid this is to automate the lifecycle of each change tenant. They should be created when work starts and destroyed when it’s done—no tickets, no cleanup scripts, just a system that knows when to let go. This isn’t just clever engineering; it’s a necessary evolution in how we manage complexity.
The implications of this shift are massive. Platform teams that cling to the old model will find their infrastructure overwhelmed by the sheer volume of agent-driven changes. They’ll watch as pull requests queue up behind outdated capacity planning, while competitors who’ve embraced change-level tenancy convert that chaos into productivity. This isn’t just a technical race—it’s a cultural one. Are we ready to move away from the human-centric assumptions that have defined our platforms for decades? Or will we cling to the past until the system collapses under its own weight?
If you’re a platform engineer, this is your moment. The tools are there—copy-on-write databases, automated environment provisioning, and lifecycle management systems. The only thing missing is the will to reimagine what a 'tenant' can be. Because the future of development isn’t about giving every developer their own slice of the world. It’s about giving every change its own space to exist, grow, and disappear—without leaving a mess behind. And if you’re not thinking about this now, you’re already falling behind.
