Ten days ago, I wrote The 19-Agent Trap. Complex AI scaffolding appeals to people who understand traditional SDLC. Phase gates, handoffs, specialized roles. But it optimizes for explainability, not effectiveness.
Then Steve Yegge shipped Gas Town.
An orchestrator running 20-30 Claude Code instances in parallel. Built on Beads, the memory framework I praised a month ago. The CNC machine he predicted was coming in 2026.
Is Gas Town the trap I warned about? Or something different?
The Two Architectures
BMAD and SpecKit simulate org charts. Analyst agent hands off to PM agent, which hands off to Architect agent, which hands off to Developer agent. Each role has a persona, defined responsibilities, phase gates. The AI mimics how humans coordinate.
Gas Town uses operational roles. Mayor orchestrates work distribution, Polecats execute tasks in parallel, Witness and Deacon monitor system health, Refinery manages merges. Each worker gets a Git worktree, a task from Beads, and runs until completion. State lives externally, not in bloated context windows.
BMAD simulates how humans coordinate - SDLC phases with handoffs between specialized personas. Gas Town simulates how systems coordinate - operational roles with external state management. One recreates org chart friction. The other distributes work across isolated environments.
| 19-Agent Trap | Gas Town |
|---|---|
| SDLC personas (Analyst, PM, Dev) | Operational roles (Mayor, Polecat, Witness) |
| Sequential handoffs | Parallel execution |
| Phase gates as quality control | Git-based persistence |
| Context pollution from role prompts | External memory (Beads) |
Where Gas Town Diverges
Gas Town avoids several traps that plague BMAD-style scaffolding:
- External memory over context bloat. Beads handles task tracking outside the agent’s context window. Roles are operational, not elaborate SDLC personas competing for attention.
- Operational roles, not SDLC simulation. Mayor coordinates, Polecats execute, Witness monitors. No confusion about whether you’re in the “requirements phase” or “implementation phase.”
- GUPP principle. Git Up, Pull, Push. Deterministic handoffs through version control, not LLM-judged phase gates.
- Git worktrees for isolation. Each agent works in its own directory. Crashes don’t corrupt shared state.
This is the orchestrated swarm Yegge predicted. Not bigger tanks for a single diver - multiple divers with their own tanks, coordinated from above.
The Chaos Is Real
But let’s not romanticize it. Gas Town is two weeks old and the chaos is palpable.
— Steve Yegge, on XThis is my third $200/month Claude Pro Max plan. My first two have maxed out their weekly limits, and now I’m about to hit a session limit in my third one. And I’m trying to dial UP my usage, with Gas Town.
DoltHub’s experience running Gas Town included:
- $100/hour token burn rate at peak
- Auto-merging failing tests into main
- “Murderous rampaging Deacon” - an agent deleting code unpredictably
- 5 force pushes to main to recover from corrupted state
This isn’t dismissible as growing pains. These are real costs. Justin Abrahms notes Gas Town requires constant steering - it’s not a hands-off system.
The architecture is different from BMAD. The complexity costs are still real.
The Reconciliation
Here’s how I square these positions:
The 19-agent trap is still a trap. Cargo cult SDLC. Persona prompts competing for context. Sequential handoffs recreating human coordination friction. Optimizing for explainability over effectiveness.
Gas Town is a different architecture. Operational roles with external state. Git-based isolation. Parallel execution without SDLC phase gates. The problems are engineering challenges, not architectural mistakes.
Boris’s vanilla approach is still optimal for most. His setup - Plan Mode, focused CLAUDE.md, verification loops, parallel sessions - handles what most developers need. No orchestration layer required.
Gas Town is for a specific ambition level. Massive parallelization across a large codebase. Automated issue triage, planning, and implementation at scale. If you’re not operating at that level, the complexity isn’t worth it.
Gas Town isn’t the trap. But it’s also not ready. Two weeks of development, wild chaos on real codebases, $100/hour burns. Yegge’s vision is directionally correct. Execution is early.
What This Means
If your PM sends you a link to BMAD or SpecKit, my advice is unchanged. Start vanilla. The scaffolding that mimics org charts is solving the wrong problem.
If you’re watching Gas Town, watch it closely. The architecture is sound. External memory, parallel execution, Git-based coordination. These are the right primitives for orchestrated agent swarms.
But don’t mistake “different architecture” for “ready for production.” DoltHub’s experience shows the gap between vision and execution. The murderous Deacon and $100/hour burns aren’t bugs to dismiss - they’re the current state of the art.
For now, Boris wins. Plan Mode, focused context, verification loops. Add complexity when you hit real limits, not theoretical ones.
Gas Town isn’t the trap. It’s the future, still under construction.
Related Posts
