Using Multiple Coding Agents, Part 2: Welcome to Gas Town! by Ed Lyons
“Welcome to Gas Town” by Ed Lyons via Midjourney
Last year saw an explosion of advances in the world of coding agents. Many of those techniques enable developers to supervise multiple agents at the same time. Part 1 of this essay was about how to do that effectively.
Yet the techniques and tools that made it practical to supervise multiple agents have convinced many engineers that it should be possible for teams of agents to be overseen by other agents, with little to no direct human supervision at all. Those engineers have created many bold new frameworks to realize their visions. Almost none are ready for production use, most of them are impractical, and a few are ridiculous.
But some of their ideas and architectural components can be useful in more practical approaches right now. One great idea has to do with improving agent memory. Some frameworks provide a local database of issues that replaces markdown files and traditional plan elements with something much more robust. It prevents common failures in long-running agent work, and allows better sharing of context and lessons learned from agents working together. A very popular implementation is Beads and an alternative is Chainlink.
Beyond the ideas and components in these frameworks, it is still important to note their overall adoption and published case studies.
At the impossible speed of agent innovation we have come to expect, some of these frameworks will soon become more useful in creating real-world applications.
The line between supervised and unsupervised agent work is quite blurry. Even in the frameworks with very little human interaction, someone has to specify what is needed, deal with errors, and sign off on what emerges from the end of the process. For my purposes here, I am going to cover frameworks where the intent is that you are not doing much supervision. To assess this space, I will first show a case study about a practical application of unsupervised agents, and then discuss five publicly available orchestration frameworks.
Case Study: Custom Orchestration Tool to Update Many Repositories
Let’s start with an example of how a huge, well-known firm has saved thousands of developer hours with a unsupervised agents that make code changes to many repositories. Spotify recently published an excellent three-part series describing how it used unsupervised coding agents to do maintenance tasks. It’s not a surprise they tried this, as we all have done work to upgrade libraries or to run scripts that change databases.
The case study has useful details about what kinds of tasks can be done this way, what errors happen, and what they did about handling them. They admit that the custom system they wrote cannot handle complex coding tasks, but automating maintenance is huge win on its own. They even extended it to allow developers to submit straightforward prompts to these “background agents” to accomplish some ad-hoc tasks as well. The case study shows that this approach can provide tremendous business value if you know what tasks to use it on.
A Detailed Specification Can Safely Guide Many Agents
Our first orchestration framework is a gentle introduction to the space, and is a CLI-based GUI on top of the Plan Delegation techniques discussed in part 1 of this essay.
CodeMachine - which was released last fall like so many other orchestration frameworks - kicks off many types of agents to carry out a plan. What’s different here is that this will only work if you write a detailed specification for what you want to build, and that spec must follow certain rules.
A lot of coding agent users create specifications to ensure very good results, so this technique is proven. Of course, many application development efforts start with less than a complete set of requirements. A spec-based approach will not work well when too much is unknown at the start.
An Enterprise-Grade Solution with Commercial Support
Swarms AI is both an open source orchestration framework and a commercial offering with a huge user base. It uses a lot of the ideas of other frameworks. It also can handle typical enterprise requirements around integration, error handling, and security. Unlike Claude Flow, it works with many types of agents. It also has comprehensive documentation that is a bit intimidating, yet I recommend looking around for topics that interest you.
A Sophisticated Open Source Framework for Claude Code
Claude Flow is a popular open source orchestration framework for Claude Code agents. It is remarkably sophisticated and features 60 different agents, but it is easier to understand than the much larger Swarms AI framework.
It has great ideas around memory management, token efficiency, and strategies to keep groups of agents on task instead of drifting from plans.
Here is a high-level diagram from its README.md file:
It also has an illuminating table showing what you get with Claude Flow that you do not with Claude Code alone. It is useful to get a feel for what you get with orchestration tools:
A Viral Vibecoded Fantasy
One of many amusing and perhaps disturbing diagrams from Gas Town
Just a few weeks ago, a technically advanced new orchestration framework became a viral sensation among developers using coding agents. (I am not joking.) A well-respected senior developer named Steve Yegge vibecoded (his word!) a huge orchestration framework called “Gas Town” where the roles are not things like “Code Reviewer” and “Requirements Manager,” but “Mayor”, “Deacon”, “Witness”, “Crew”, and “Dogs.” It imagines a 19th-century factory town where the human developer is the “Overseer” and you can kick off dozens of agents simultaneously.
Yegge’s fantastical vision inspired the image I created at top of this essay. The sheer hubris of generating a framework for 30-40 agents to work simultaneously and without human supervision caused a lot of people to try it out and write blog posts analyzing it. The hype got so severe that a new cryptocurrency was created in its honor.
The verdict around Gas Town was that this approach will certainly not work right now. Even Yegge told people that he’d never even looked at the code he generated (!), and that nobody should use this for real application work. His exact words about using it were, “You will die.”
As part of a discussion in a large group of developers, a friend of mine called Gas Town “a concept car” showing future potential, and was not a vehicle you can drive. That feels right.
As for me, I have never so enjoyed spending a few hours looking at a framework I would never use. It was delightfully absurd. Like others, I thought, “But maybe we will do it this way someday.”
A great technical review of Gas Town and the issues it raises is here.
A Clever Response to Gas Town
Released just days after Gas Town stole the attention of thousands of advanced agent developers, the oddly-named Schmux seems to have been written in anger against Steve Yegge’s viral framework. In fact, in the documentation, the author dismisses it as “Gaslight Town.” (Not bad!)
Schmux is a smaller, technically-impressive orchestration framework that isolates agents into tmux terminals which are like independent window managers, with a lot of features to keep them isolated, durable, and manageable.
In order to try out the features, I used it to generate an application to process the results of Massachusetts elections that had several components. As you can see below in the web dashboard for my development work, you create sessions and then spawn specialized agents inside of them.
Then you can go into a session and see tabs for each agent process that are just familiar CLIs to your agents.
The interface is really clever, and that matters a lot in lightly supervising all of these agents. The tmux architecture is also quite intriguing. So I will be keeping an eye on Schmux.
Conclusion
I hope you come away from this tour of the space seeing the power and potential of supervised and less supervised agentic approaches to software development. They will surely become more feasible as underlying technologies and management techniques improve. In fact, some researchers analyzed the Claude Code application, and found that there is an unreleased orchestration framework hidden inside. It’s yet another signal about this direction for coding agents.
I will try to keep an eye on all of this, even the crazier offerings. Like a lot of places I’ve been, I wouldn’t want to live in Gas Town, but I did like visiting it. I returned home with a new certainty that a developer supervising one agent isn’t going to be the standard practice by the end of 2026.