Explainer · Steve Yegge (2026)
Yegge's Gas Town treats AI agents like a factory floor — and the developer becomes the operator
Gas Town is a multi-agent orchestrator that lets a single developer manage 20–30 parallel AI coding agents through a Mad Max–themed hierarchy of roles, turning software engineering into something closer to running a refinery than writing code.
Who built it
Steve Yegge — veteran engineer, ex-Google/Amazon, known for long-form tech essays
Why it exists
Running 20–30 Claude Code agents by hand is chaos — stuff gets lost, agents get stuck, merges collide
What it solves
Gives one developer a supervised hierarchy of AI agents that self-monitor, self-heal, and merge code cleanly
IDE-era
CLI / multi-agent era
Stage 1 — Near-zero AI
Manual coding, maybe tab-complete
Stage 2 — IDE agent, permissions on
Copilot-style suggestions, you approve each one
Stage 3 — IDE agent, YOLO mode
Auto-accept suggestions, trust the model more
Stage 4 — IDE, agentic mode
Agent fills the screen — edits, runs, debugs inside the IDE
Stage 5 — CLI, single agent
Move to the terminal, one Claude Code instance, full YOLO
Stage 6 — CLI, 3–5 agents
Multiple agents in parallel, you tab between them
Stage 7 — 10+ agents, hand-managed
Things start falling through the cracks, agents get stuck
Stage 8 — Orchestrator (Gas Town)
Purpose-built infra to supervise, heal, and merge agent work
Gas Town is built for developers who've hit the ceiling of Stage 7
What is it
On New Year's Day 2026, veteran engineer Steve Yegge published a blog post introducing Gas Town — his fourth attempt at building a multi-agent orchestrator over the course of 2025. Written in Go on top of his Git-backed issue-tracking system Beads, Gas Town lets a developer spin up colonies of Claude Code agents that work on different parts of a codebase simultaneously, while a hierarchy of supervisor agents keeps everything from derailing.
The pitch draws a deliberate comparison to Kubernetes. Both systems coordinate unreliable workers toward a goal. Both have a control plane watching over execution nodes. Both reconcile against a persistent source of truth. But where Kubernetes optimises for uptime ("Is it running?"), Gas Town optimises for completion ("Is it done?"). Workers are spun up, finish a task, land their code, and get torn down.
Human operator
Town-level role
Per-Rig role
Mayor
Town-level · Concierge
Deacon
Town-level · Heartbeat
Boot the Dog
Town-level · Watchdog
Rig (per-project)
Witness
Supervisor
Polecats
Workers (ephemeral)
Refinery
Merge queue
Crew
Interactive (reports to you)
The Crew's dashed border indicates it reports directly to the Overseer, bypassing the Witness
A loose analogy, not a literal org chart
The Mad Max theming is flavour, not structure. In the films, Gas Town is a refinery settlement ruled by a warlord. Yegge borrows the aesthetic — Polecats, the Witness, the War Rig — but maps them onto software-engineering concerns like merge queues, health checks, and task scheduling. There's no antagonist, no scarcity politics, and no hierarchy of violence. Think of it as a memorable naming convention for what is, underneath, a fairly standard supervisor-worker-monitor pattern with an event-driven heartbeat loop.
Agent roles
Who Does What in Gas Town
The Overseer (You)
Human
The developer. You talk to the Mayor, review diffs, and set priorities. You interact mostly at the top of the hierarchy.
The Mayor
Town-level · Persistent
Your concierge and chief-of-staff. The main agent you communicate with — it delegates work downward and reports status back to you.
The Deacon
Town-level · Persistent
Pinged by a daemon every couple of minutes with "do your job." It intelligently propagates this heartbeat signal downward, keeping the whole system moving.
Boot the Dog
Town-level · Periodic
Wakes every 5 minutes solely to check on the Deacon. Decides whether to nudge, restart, or leave it alone — then goes back to sleep.
The Witness
Per-Rig · Supervisory
Patrols Polecats and the Refinery within a Rig, checking their health and unsticking stuck workers. Also peeks in on the Deacon.
Polecats
Per-Rig · Ephemeral
The actual coding agents. They swarm in parallel, execute tasks, produce merge requests, then hand them off to the Refinery and get torn down.
The Refinery
Per-Rig · Persistent
Manages the merge queue. Takes merge requests from Polecats and lands them cleanly so parallel work doesn't collide.
The Crew
Per-Rig · Interactive
Coding agents that work directly for the Overseer (you), outside the Witness's supervision. For hands-on, interactive work.
The high-level pattern
Strip away the Mad Max paint and Gas Town implements a hierarchical supervisor-worker pattern with reconciliation. A persistent control plane (the Mayor, Deacon, Boot) manages intent and scheduling. Per-project execution nodes (Rigs) host ephemeral workers (Polecats) that do the actual coding. Monitors (the Witness) detect stuck or failed workers and intervene. A merge layer (the Refinery) serialises parallel output into a coherent codebase. All state is persisted in a Git-backed store (Beads) that every agent can read from, making the whole system recoverable after any crash.
This is the same control-loop pattern that powers Kubernetes — observe, diff, act — applied to task completion instead of container uptime. The Deacon's heartbeat is the reconciliation tick. Each cycle, supervisors check whether the world matches the desired state and nudge workers accordingly. The key insight is that because LLM agents are unreliable (they hallucinate, get stuck, or wander off-task), you need the same kind of fault-tolerance infrastructure that distributed systems have needed for decades.
Why it matters
Gas Town represents a bet that the future of software engineering looks less like "a developer with an AI assistant" and more like "a developer operating a factory of agents." Yegge's 8-stage maturity model frames this as an inevitable progression: you start with autocomplete, graduate to a single CLI agent, then discover you can run five in parallel, and eventually you need purpose-built infrastructure to keep them all productive. Gas Town is that infrastructure.
Whether or not Gas Town itself becomes widely adopted, the architectural pattern it demonstrates — hierarchical supervision, ephemeral workers, persistent state, heartbeat-driven reconciliation — is likely to show up in every serious multi-agent system. It's the same pattern the industry converged on for containers, just re-applied one abstraction layer up.
Key Takeaway
Multi-agent AI systems need the same infrastructure that distributed computing needed: supervision hierarchies, health checks, merge serialisation, and crash recovery. Gas Town wraps that engineering in a memorable metaphor and bets that developers will manage agent colonies the way site-reliability engineers manage container clusters.