Exploring Gas Town
The next logical progression
”The best executive is the one who has sense enough to pick good men to do what he wants done, and self-restraint enough to keep from meddling with them while they do it.”
-Theodore Roosevelt
Note: A warning, this post covers an advanced topic. If you’ve been struggling with how to manage 5-10+ agents simultaneously in your workflow, or you want to see where software development is headed, read on.
I’ve been doing multi-agent coding, having multiple coding agents running in parallel to accomplish tasks, for awhile now. It has made me incredibly effective but has also come with a whole set of issues:
How to to manage 10+ agents working simultaneously, both with funneling directions as well as intervening
How to have work persist through crashes, errors, restarts, filled context windows, and missed steps
A need to seamlessly spin up multiple workers without self managing multiple repo copies or git worktrees
Keeping agents on task and on track for complex multi-step workflows
Monitoring all development activity in a seamless manner
Getting updates on when workers need input or are done with their tasks
How to parallel process multiple projects at the same time
Luckily for me, in early January, I ran into Gas Town, Steve Yegge’s multi-agent orchestration system. Yegge describes Gas Town as follows:
Gas Town is a new take on the IDE for 2026. Gas Town helps you with the tedium of running lots of Claude Code instances. Stuff gets lost, it’s hard to track who’s doing what, etc. Gas Town helps with all that yak shaving, and lets you focus on what your Claude Codes are working on.
For this blog post, “Claude Code” means “Claude Code and all its identical-looking competitors”, i.e. Codex, Gemini CLI, Amp, Amazon Q-developer ClI, blah blah, because that’s what they are. Clones. The industry is an embarrassing little kid’s soccer team chasing the 2025 CLI form factor of Claude Code, rather than building what’s next.
I went ahead and built what’s next. First I predicted it, back in March, in Revenge of the Junior Developer. I predicted someone would lash the Claude Code camels together into chariots, and that is exactly what I’ve done with Gas Town. I’ve tamed them to where you can use 20–30 at once, productively, on a sustained basis.
I’ve been using Gas Town for the past six weeks. The results have fundamentally changed how I think about what a single developer can accomplish and, more importantly, what the actual limiting factor is. It isn’t code generation. The limiting factor is how fast you can think, give direction, and validate.
Before we dive into how Gas Town works, it helps to see how coding with software agents has evolved.
The Phase Transition at Stage 7
Yegge lays out eight stages of AI-assisted development:
Stage 1: Zero or Near-Zero AI: maybe code completions, sometimes ask Chat questions
Stage 2: Coding agent in IDE, permissions turned on. A narrow coding agent in a sidebar asks your permission to run tools.
Stage 3: Agent in IDE, YOLO mode: Trust goes up. You turn off permissions, agent gets wider.
Stage 4: In IDE, wide agent: Your agent gradually grows to fill the screen. Code is just for diffs.
Stage 5: CLI, single agent. YOLO. Diffs scroll by. You may or may not look at them.
Stage 6: CLI, multi-agent, YOLO. You regularly use 3 to 5 parallel instances. You are very fast.
Stage 7: 10+ agents, hand-managed. You are starting to push the limits of hand-management.
Stage 8: Building your own orchestrator. You are on the frontier, automating your workflow.
If you’re not at least Stage 7, or maybe Stage 6 and very brave, then you will not be able to use Gas Town. You aren’t ready yet.
Most developers I talk to are between Stages 3 and 5. A good chunk of experienced practitioners have reached Stage 6. But the jump from Stage 6 to Stage 7 isn’t incremental. It’s a phase transition. Terminal tabs become unmanageable. Context windows fill mid-task. Agents go off-course. Crashes eat progress. You spend more time babysitting than building.
The prevailing narrative says better models will solve this. Just wait for the next release, the next context window expansion. I’ve found that to be not true. The models are good enough right now. What’s missing is the orchestration layer. That’s where Gas Town comes in.
How Gas Town Works
At its core, Gas Town is a conversion engine. It takes your thoughts and specifications and converts them into completed, validated work by routing them through a system of agents, workflows, and verification steps. Gas Town also makes heavy use of Beads, Yegge’s issue-tracking system. Gas Town is structured such that the limiting factor is how quickly one can feed ideas and specifications into the system. This is because Gas Town contains systems that create tasks and spin up additional agents that immediately take on work to complete tasks without user intervention. These agents know the rules and operations of Gas Town along with what steps are needed or remaining to complete tasks. Gas Town is also flush with robust redundancies that provide multiple fallback mechanisms that ensure work is completed even if individual nodes or workers fail.
The magic here is that Yegge is devised a system that allows a user to operate at a higher level of operation by removing a lot of the managerial overhead while still providing the flexibility and control to interact directly with lower levels as needed to move work along in the right ways. This provides users who are operating at level 7 or above to use the skills they have gained along the way and augmenting those behaviors with a better use experience that acts as a force multiplier.
Yegge draws a comparison to Kubernetes, and it’s apt. Both systems coordinate unreliable workers toward a goal. Both have a control plane watching over execution nodes. Both use a source of truth the whole system reconciles against. However, the key difference: Kubernetes asks “Is it running?” Gas Town asks “Is it done?” Kubernetes optimizes for uptime. Gas Town optimizes for completion.
The Agent Roles
Gas Town is composed of multiple AI agents that play particular roles alongside some framework constructs. Each type of agent has different a purview of responsibility and level of permanence. There’s also a hierarchy between the roles that exists, with the user intervening or interacting more at the highest levels as opposed to the lowest levels. Gas Town has a bit of a Mad Max theming so you might see some similar names. Gas Town introduces a lot of new terminology, so let me cut through the jargon and explain the key components in plain terms.
Your workspace is called a Town.
Each project (git repo) within the town is called a Rig.
A mail system lets agents communicate with each other and with you, enabling coordination and task handoff that becomes essential at scale.
You, the human, are the Overseer, and you have your own inbox for notifications from the system. From there, work flows through a set of specialized agents, each solving a specific problem from the list I described at the top.
The Mayor is the agent you interact with most. You give the Mayor your specifications and it breaks them down into tasks, delegates work to other agents, and coordinates across the project. Instead of managing 20 agents yourself, you manage one, and it manages the rest.
Polecats are disposable coding workers. They spin up, receive a task from the Mayor (or other crew members), do the work, submit a merge request, and are destroyed. Gas Town can create and tear down as many parallel workers as needed without you manually managing repo copies or branches. Think of them as contractors who clock in, do a job, and leave.
The Crew are long-lived coding agents tied to a specific project. Unlike Polecats, they persist between tasks, which makes them excellent for design work or anything requiring extended back-and-forth discussion. I’ve worked up to 7-8 crew per rig.
The Witness watches each project to make sure the work being produced actually matches the task specifications. The agent doing the work might believe it’s finished, but the Witness verifies against the actual requirements before allowing it to move on.
The Deacon runs a continuous monitoring loop at the town level, checking on all active agents, nudging ones that have stalled, and flagging agents that have drifted off-task. It catches the situation where one of your agents has been spinning on the wrong problem for forty minutes before you noticed.
The Refinery handles the merge queue, identifying where conflicts are occurring, reviewing code, and landing completed work into the main branch.
The Witness, Deacon, and Refinery each have their own workflow loops they work through that are extensible and modifiable.
Work Tracking and Reusable Workflows
The agents handle how work is formed, handed off, routed, and completed. The next question is how work is tracked and sequenced. This is where Gas Town’s design gets intriguing because it enables a method of creating reusable, verified workflows to accomplish specific types of work that can be applied to a variety of tasks.
Here’s the rub: if you let agents manage their own to-do lists in text files, they’ll check off items they haven’t actually completed. When you point this out, they look at their own checked list and insist the work is done rather than re-verifying. Instead, you need an immutable way of tracking work so agents can’t tamper with it until it has been signed off as completed AND you need a way to enforce that steps have been completed in order. That’s where Beads comes in. It breaks the gaps of agents by forcing sequential completion. An agent cannot mark step 3 as done and skip to step 4 without external verification. It’s the difference between a student grading their own homework and a teacher verifying each answer before allowing them to proceed.
Beads are the atomic unit of work, stored as JSON and tracked in Git alongside your project. This is the foundational innovation: persistent, externalized task state that exists independently of any agent’s context window. Because everything is backed by Git, when Claude Code crashes, when context fills up, when an agent restarts, the new instance reads the bead state and picks up exactly where things left off. No progress is lost.
Beads can be chained together into molecules (read: a chain of commands): sequenced steps where each one gets executed by an agent and verified before the next step unlocks. These molecules can have loops, gates, and branching logic. More importantly, they can be templated into reusable Formulas (read: workflows), which is where the real leverage appears.
Consider a feature development formula: examine the issue -> generate a design -> assess the design against requirements -> write tests -> implement -> run the tests -> iterate on failures -> validate against the original spec. That formula gets applied consistently to every agent. You can create formulas for bug fixes, refactoring, code review, spikes, documentation, or any process you want to be repeatable. If you think about an algorithm you reuse across different parts of a codebase, you can abstract up a level: I want to design the system that designs the algorithms. That’s what formulas enable. You’re programming the process that generates code.
Why This Complexity Is Needed
Some might not see this as efficient. Supervisory agents watching coding agents. Verification steps at every transition. A mail system between entities that share a filesystem. It looks like overhead.
However, this redundancy exists for the same reason it exists in organizations. Companies have managers, reviews, stage gates, and handoff protocols because workers are imperfect and need structural support to stay aligned. AI agents need these structures even more. The stochastic nature of LLM outputs means fuzzy inputs produce fuzzy outputs, unless you constrain the process. Without Beads, agents lose track of what’s been done. Without the Witness, they’ll insist finished work is correct when it isn’t. Without the Deacon, stalled agents sit idle unnoticed. Without mail, agents working on related tasks can’t coordinate. Each component exists because removing it causes a specific, predictable failure.
You don’t make agents better by giving them more freedom. You make them better by constraining their workflow and externalizing their state. The Deacon costs tokens. The Witness costs tokens. You can burn through half of a Pro Max account (or several) in six to eight hours running hot. But those redundancies are what allow you to sustain 20-30 agents productively rather than losing work to the chaos of unmanaged parallelism.
Gas Town is the substrate that converts your thoughts and ideas into meaningful work. Instead of pretending agents are reliable and failing when they aren’t, it builds scaffolding around their unreliability. That’s the insight worth internalizing, because every multi-agent system will need to solve the same problem.
The Workflow Shift
So what changes about how you actually work? Having spent six weeks or so using Gas Town across multiple simultaneous projects, I believe I can describe the shift concretely. The bottleneck migrates from coding speed to the rate at which you can generate ideas, write specifications, and validate outputs. You are no longer limited by how fast you can build. You are limited by how fast you can think.
The developer’s job shifts from a majority of writing code to a majority of the three following activities:
Specification: defining what needs to happen with enough precision to be actionable but enough flexibility for agents to problem-solve.
Validation: verifying that outputs match intent.
Ideation: generating the next wave of work while current work executes. Writing code, reading code, debugging code: those are now largely delegated.
My practical workflow starts with 30-60 minutes of deep thinking before any agents spin up. No screens. Map out the direction you want things to go. This is the highest-leverage activity in the system because everything downstream depends on the quality of your thinking. From there, I write specifications in batches using voice dictation (Wispr Flow has been excellent for this), building a backlog of ready-to-deploy instructions so Gas Town always has work to feed agents.
Track your thinking externally. As you review agent output, you generate ideas faster than you can deploy them. Those thoughts compound. You see connections between projects, notice opportunities for shared components, identify patterns that apply elsewhere. There’s an exponential feedback loop at play: outputs generate observations, observations generate ideas, ideas generate work, work generates outputs. If you don’t capture these thoughts immediately, they can evaporate, and they’re often your best ones because they’re informed by real output.
This feedback loop also reveals what kind of developer thrives in this mode. I’ve been discussing with other practitioners whether seniority predicts success, and the emerging consensus is directional: it’s not seniority, it’s managerial instinct. Senior developers who are strong delegators, who write explicit but not micromanaging instructions and intuitively sense where things go wrong, are the ones who excel. Brilliant individual contributors sometimes struggle because their instinct is to do the work themselves, taking over from agents mid-task. That’s Stage 3 behavior applied to a Stage 8 problem. The feedback loop rewards people who can stay at the level of direction and validation rather than dropping into implementation.
The configuration is never done, either. Models change weekly. What worked as a formula last month may need revision because the underlying model handles context differently now. This is the Red Queen effect applied to development infrastructure. The developers who thrive will be those who treat their orchestration system as a living organism requiring the same amount of iteration as the software it produces.
Unification
What Gas Town represents isn’t just a new tool. It’s the emergence of a new way of working, one where the unit of work is not code but instructions that generate code, and where reusable abstractions aren’t libraries and frameworks but workflows and validation pipelines.
The patterns underneath Gas Town - externalized state, constrained workflows, supervisory agents, and inter-agent communication - are a response to a fundamental truth about current AI systems: they are capable but unreliable if not used properly. The answer isn’t to wait for them to get better. The answer is to build systems that account for their weaknesses while leveraging their strengths. We’re going to see a wave of multi-agent orchestration tools this year, and these underlying patterns will persist regardless of which tool wins.
If you’re at Stage 5 or 6 and want to start moving toward this: design your workflows as explicit sequences rather than ad-hoc prompting. Invest in specification-writing because the quality of your instructions is now your primary output. Build a backlog habit so you always have more work ready than agents to deploy it to. Before you start any task, ask how you’d explain it to a competent but literal-minded junior developer who can’t ask clarifying questions.
The question I keep coming back to is, if the limiting factor is truly the rate of ideas, what does an organization that’s optimized for idea throughput look like rather than one optimized for code throughput? I don’t have complete answers yet. But I suspect the people figuring this out first will have a compounding advantage that’s very difficult to catch.
Where do you fall on Yegge’s eight stages? Have you hit the coordination wall at Stage 7? I’d love to hear what patterns you’ve discovered, especially around specification quality, workflow design, and managing the shift from code to cognition.