The landscape of AI-assisted software development is rapidly evolving beyond simple pair programming with a single agent. The next frontier involves orchestrating entire teams of autonomous coding agents, each with specialised roles, to work on complex projects concurrently. This concept, recently popularised by a blog post from Steve Yegge, has been brought to life in a project called Gas Town. It presents a new, opinionated paradigm for managing a "factory" of AI developers, allowing a single human operator to act as a mayor, overseeing the delivery of substantial codebases with minimal direct intervention.
The shift from single agents to multi-agent orchestration
For many developers, working with AI coding assistants has evolved from asking for snippets to spawning sub-agents to handle specific, bite-sized tasks. Tools like Claude Code, Aider, and various agentic frameworks have enabled a workflow where a primary agent delegates work to specialised sub-agents, which then report back. This hierarchical model, often visualised as a loop, allows for complex tasks to be broken down and distributed.
Gas Town represents a significant leap forward from this model. It is not just a tool but a reimagination of the entire development workflow as a city or a factory. It structures the process with concrete roles and a robust task management system to allow for the concurrent operation of many agents—potentially dozens or even hundreds—without the typical chaos of merge conflicts and lost context. The core idea is to move beyond managing one or two agents and into a realm where the human acts as a high-level manager, setting the vision and letting the system execute.
The Gas Town factory: roles and responsibilities
The metaphor of a steampunk city is central to understanding Gas Town’s architecture. The human operator takes on the role of the Mayor, the ultimate authority who defines the work to be done. Within this city, a hierarchy of AI agents, each with a distinct role, carries out the development work.
Polecats (The Contractors): These are the transient, ephemeral workers. They are the primary coding agents that are hired for short periods—perhaps a week or two—to complete specific batches of work. You can bring in dozens of polecats at once to tackle large amounts of grunt work or well-defined tasks. They are designed to be disposable; they come in, do their job, and are gone.
Witnesses (The Supervisors): These agents manage the polecats. They oversee the work being done, ensuring that tasks are completed correctly, on time, and that nothing has been dropped. They act as a first line of defence against errors and ensure the contractors stay on track.
Dogs (The Health Monitors): At the bottom of the hierarchy, the dogs are responsible for health checks and diagnostics. They keep an eye on the system’s vital signs, ensuring that all components are functioning correctly and that the work is proceeding as expected.
The Deacon and Refinery (The Planners): This part of the factory is responsible for planning. It defines what “good” looks like before any work begins. The refinery takes high-level plans from the mayor and refines them into actionable tasks, adhering to the principles of spec-driven development.
The Overseer (The Operator): Positioned above the mayor, this role is a meta-level supervisor. The analogy used is “pruning a garden that you can’t see.” The overseer (which can be a human or another AI like Claude) instructs the mayor on what needs to be done, such as “cut back the rose petals” or “make sure the hedge is round,” without needing to know the intricate details of the garden’s current state. It provides high-level direction and lets the system figure out the implementation.
Beads: the atomic unit of work
At the heart of this orchestration system is a task management mechanism called beads. A bead is essentially a JSON wrapper around a to-do item. It contains the task description, its status, and any relevant metadata.
The workflow is built around the passing of beads between agents:
- The mayor or a refinery creates a bead for a specific task and places it in a central database.
- A polecat (or another agent) checks the database for available beads, picks one up, and begins work.
- The polecat might make commits locally, create pull requests, or open issues, marking the bead’s status as “in work” or “done” in the database.
This system provides a clear, centralised view of what is being worked on, who is working on it, and what remains to be done. It prevents agents from stepping on each other’s toes and provides a clean audit trail of all activities.
The operational reality: cost, risk, and management
Running a multi-agent factory like Gas Town is not a set-it-and-forget-it operation. The practical realities of the system reveal several critical considerations.
The cost of scale: Running dozens of agents, each consuming tokens, is expensive. The system has been described as a “wallet attack” that burns through credits rapidly. A standard Anthropic max plan can be exhausted quickly when running Gas Town. For sustained operation, users need to consider unlimited plans, multiple cloud accounts, or a mix of models, such as using local models via Ollama for cheaper, faster tasks and Claude Code for the more complex, “chunky” work. It is reported that Steve Yegge himself runs approximately 40 Claude Code accounts, costing around $4,000 a month.
The risk of autonomy: Gas Town operates effectively in “yolo mode,” where agents are given a high degree of autonomy. While this is powerful, it can lead to unforeseen consequences. Agents can go in a direction the mayor did not anticipate, and because they work quickly, they can go “very far down that path” before the human realises. In extreme cases, the system has been known to attempt to delete its own files. Running this type of system requires careful containment, ideally within a virtual machine or a container, to prevent damage to the host system.
The management overhead: Despite the automation, the human role is far from passive. The experience is akin to being a CEO or a project manager under significant stress. The operator is not writing code but is constantly monitoring the flow of work, merging pull requests, and reviewing diffs. There is a constant need to “nudge” agents to ensure they are on task and to handle tasks that have been dropped by ephemeral workers.
A notable early challenge was tasks (beads) going missing when polecats went AWOL. This required building systems to reassign work and manage the distributed task list, which is essentially a local git-like Kanban board. The database that holds the beads is critical, and its corruption can bring the entire factory to a halt.
The future of multi-agent systems
Despite the challenges, the potential of these multi-agent systems is immense. They represent a leap forward from “vibe coding” towards what might be called “beads-driven development” or “orchestrated development”.
The key takeaway is that while the technology is powerful, it is still in its early days. The systems are token-hungry, the tooling is nascent, and the workflows are not yet polished. However, the underlying paradigm is clear: the future of software development will involve humans managing fleets of specialised AI agents. Tools like Gas Town are pioneering this future, providing a glimpse of a world where a single developer, acting as a mayor, can orchestrate a city of workers to build software at a scale previously unimaginable. The next steps will be in refining the tools, improving observability, and, perhaps most importantly, developing the management skills needed to guide these complex, autonomous systems to their intended goals.
