Many years ago, a large European bank spoke to analysts after its first transition from purely physical hardware into virtual machines. While expressing overall satisfaction with the move, its enthusiasm was clearly tempered. When pressed on the hesitant endorsement, the bank’s representative stated that virtual machines had, in fact, accomplished all of the desired goals: their infrastructure and usage were far denser, utilization was up, stand up and instantiation times were down and so on.
All of which led to a natural response: “it sounds like there’s a ‘but’ coming.”
To which the executive replied, “virtual machines have been good for us. It’s just that going from managing 500 physical machines to 5,000 virtual machines has been…a challenge.”
This pattern, in which a given unit of technology is decomposed into smaller units of a technology, is one that has played out repeatedly over the last few decades in this industry. One of the more recent examples of this was the trend towards microservices, in which larger APIs were deconstructed into multiple smaller component services in search of more granular control and development velocity.
In every case, this leads to a management challenge. What makes sense on paper and may indeed make sense in practice does not come without an offsetting cost. Just as there an array of benefits to virtual machines and its successor, containers, or to microservices, it’s important to consider not just the short term advantages to decomposition but the longer term implications of it on a going forward basis. How do you manage thousands of VMs when your existing infrastructure was designed to manage hundreds or even dozens of physical machines? How does your network cope with an exponential increase in the number of active services and endpoints?
These questions seem particularly important in 2026. Last year was in effect the year of the agent. The industry had begun to digest the abilities – and shortcomings, importantly – of existing models and related technologies, and had followed the typical industry progression from a given monolith – all encompassing AI models – to its logical conclusion, decomposed, individual AI services, or agents, that were the functional equivalent of a microservice. Small, independent and with some degree of autonomy, what ultimately came to be described as the “agentic” vision of AI was one describing fleets of individual AI agents operating in concert with one another and various third parties both human and otherwise.
All of which means that the next challenge in front of the AI market is management.
This is already evident to an extent in the domain of code assistance. As code assist progressed from enhanced autocomplete to the autonomous generation that is vibe coding, developers have gradually transitioned from builder to architect. At which point, people began to ask a logical question: if agents are as easily spun up as VMs could be once upon a time, what would happen if we added more builders?
Rather than one agent building code, then, they began deploy larger and larger numbers of them, with a primary gating factor of token costs. Referred to by many names, “swarm coding” among them, the practice has become increasingly common as developers and their employers deploy teams of coding agents in an effort to improve overall velocity, code quality and to leverage the differing strengths of varying models.
The obvious problem, then, was how to manage these swarms of autonomous coding agents. Enter Gas Town. Written by Steve Yegge (that Steve Yegge) and billed as a “new take on the IDE for 2026,” Gas Town is a way to manage and orchestrate swarms of code assistant agents – up to 20 to 30 of them – much as Kubernetes does the same for fleets of containers.
It’s overkill for many, Gas Town is merely one initial stab at this problem and Yegge himself goes out of his way to dissuade anyone using less than ten agents from using it. And swarms are not the only option for those seeking greater speed and refinement – Ralph Wiggum is an iterative, looped single agent alternative that has proven very popular with developers.
But it’s clear within the specific domain of code assistance that swarm coding is going to be a primary if not default approach, and it’s equally clear that swarms of agents are going to be deployed across multiple domains in the quote unquote agentic future. If you’re looking for 2026 trends to track, then, how the industry is going to manage the flood of AI agents is a critical question. If it’s not solved, as Yeats said, the blood-dimmed tide will be loosed, and everywhere the ceremony of innocence will be drowned.
