Maggie Appleton 写设计、人类学和智能体界面时，习惯先画清楚隐喻，再谈工具。把「Gas Town’s Agent Patterns, Design Bottlenecks, and Vibecoding at Scale」整理成可阅读的中文笔记：问题在哪、界面默认会把人带去哪、落地时该改什么。原站导航、评论回响和广告已去掉。

Welcome to Gas Town

A few weeks ago Steve Yegge published an elaborate manifesto and guide to Gas Town, his Mad-Max-Slow-Horses-Waterworld-etc-themed agent orchestrator that runs dozens of coding agents simultaneously in a metaphorical town of automated activity. Gas Town is entirely vibecoded, hastily designed with off-the-cuff solutions, and inefficiently burning through thousands of dollars a month in API costs.

This doesn’t sound promising, but it’s lit divisive debates and sparks of change across the software engineering community. A small hype machine has formed around it. It’s made the rounds through every engineering team’s Slack, probably twice. There’s somehow already a $GAS meme coin doing over $400k in earnings. This was not Yegge’s doing – someone else set it up on the crypto platform Bags which ties tokens to individual creators. The coin holds no legit

1. Design and planning becomes the bottleneck when agents write all the code

You should at least skim through Yegge’s original article before continuing to read my reflections. First, because I’m not going to comprehensively summarise it. A challenging task given the sprawling, haphazard nature of the piece And second, because even a one minute glance over Yegge’s style of writing will make the vibes clear.

We should take Yegge’s creation seriously not because it’s a serious, working tool for today’s developers (it isn’t). But because it’s a good piece of speculative design fiction that asks provocative questions and reveals the shape of constraints we’ll face as agentic coding systems mature and grow.

2. Buried in the chaos are sketches of future agent orchestration patterns

What is Design Fiction? Read more “Design fiction” or “speculative design” is a branch of design where you create things (objects, prototypes, sketches) from a plausible near future. Not to predict what’s going to happen, but to provoke questions and start conversations about what could happen. Not in a bright-and-glorious-flying-cars way that futurism can sometimes fall into. But, most helpfully, in a way that thinks about banal details, overlooked everyd

I also think Yegge deserves praise for exercising agency and taking a swing at a system like this, despite the inefficiencies and chaos of this iteration. And then running a public tour of his shitty, quarter-built plane while it’s mid-flight.

Agents have specialised roles with hierarchical supervision

When I was taken to the Tate Modern as a child I’d point at Mark Rothko pieces and say to my mother “I could do that”, and she would say “yes, but you didn’t.” Many people have talked about what large-scale, automated agent orchestration systems could look like in a few years, and no one else attempted to sincerely build it.

“Orange and Yellow” and “Royal Red and Blue” by Mark Rothko Paintings I could totally make myself, but did not I should be transparent and say that I have not used Gas Town in earnest on any serious work. I have only lightly poked at it, because I do not qualify as a serious user when I’m still hovering around stages 4-6 in Yegge’s 8 levels of automation:

Agent roles and tasks persist, sessions are ephemeral

Yegge's eight levels of automation. From stage 1: using autocomplete to an IDE through to stage 8: using an agent orchestrator – Source: Welcome to Gas Town I currently juggle a handful of consecutive Claude Code and OpenCode agents, but pay close attention to the diffs and regularly check code in an IDE. Which I guess puts me in the agentically conservative camp in this distressingly breakneck moment in history.

Gas Town is a full-on stage 8 piece of tooling: using an orchestrator that manages dozens+ of other coding agents for you. Yegge also warned me not to seriously use Gas Town multiple times, in increasingly threatening typography. I trust his guidance on his own slush pile.

Feeding agents continuous streams of work

Yegge's emphatic warnings and reasons why we shouldn't use Gas Town (highlights mine) But I have grokked the basic concepts and spent more time with this manifesto than is warranted. And here is what stood out to me from the parts I could comprehend:

When you have a fat stack of agents churning through code tasks, development time is no longer the bottleneck. Yegge says “Gas Town churns through implementation plans so quickly that you have to do a LOT of design and planning to keep the engine fed.” Design becomes the limiting factor: imagining what you want to create and then figuring out all the gnarly little details required to make your imagination into reality.

值得单独记下的观察

• The Mayor is the human concierge: it’s the main agent you talk to. It talks to all the other agents for you, kicking off work, receiving notifications when things finish, and managing the flow of production.
• Polecats are temporary grunt workers. They complete single, isolated tasks, then disappear after submitting their work to be merged.
• The Witness supervises the Polecats and helps them get unstuck. Its job is to solve problems and nudge the proletariat workers along.

落地时建议先做的 5 件事

1. 先写清这个工具在强化思考还是在替人思考。
2. 默认交互不要只会谄媚：该追问、该给反例、该要求证据。
3. 智能体界面要露出推理步骤，而不是只给一个光滑答案。
4. 知识发布用可生长的笔记，而不是一次性营销长文。
5. 改产品前先画隐喻：用户以为自己在做什么，系统实际在做什么。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，最该从这类笔记里拿走的是「别把聊天框当唯一界面」。数字员工要能追问、能验证、能把过程摊开，而不是只负责说好话。

本文侧重智能体生命周期与技能边界。若你要动手验证，优先用 Playground 做小任务压测；权限与托管再单独规划，避免「先装一堆再治理」。 相关：Playground · 创建智能体 · 学习中心