Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

If I can be a bit bold and observe that this tic is also a very old rhetorical trick you see in our industry. Call it Schrodinger's Modest Proposal if you will.

In it someone writes something provocative, but casts it as both a joke and deadly serious at various points. Depending on how the audience reacts they can then double down on it being all-in-good-jest or yes-absolutely-totally. People who enjoy the author will explain the nonsensical tension as "nuance".

You see it in rationalist writing all the time. It's a tiresome rhetorical "trick" that doesn't fool anyone any more.

- "what's next" does not mean "production quality" and is in no way mutually exclusive with "experimental". It means exactly what it says, which is that what comes next in the evolution of LLM-based coding is orchestration of numerous agents. It does not somehow mean that his orchestrator writes production-grade code and I don't really understand why one would think it does mean that.

- "productively" also does not mean "production quality". It means getting things done, not getting things done at production-grade quality. Someone can be a productive tinkerer or they can be a productive engineer on enterprise software. Just because they have the word "product" in them does not make them the same word.

- "working effectively" is a phrase taken out of the context of this extremely clear paragraph which is saying the opposite of production-grade: "Working effectively in Gas Town involves committing to vibe coding. Work becomes fluid, an uncountable substance that you sling around freely, like slopping shiny fish into wooden barrels at the docks. Most work gets done; some work gets lost."

If he wanted to say that Gas Town wrote production grade code, he would have said that somewhere in his 8000-word post. But he did not. In fact, he said the opposite, many many many many many many times.

You're taking individual words out of context, using them to build a strawman representing a promise he never came close to making, and then attacking that strawman.

What possible motivation could you have for doing this? I have no idea.

> If you say two different and contradictory things...

He did not. Nothing in the blog post explicitly says or even remotely implies that this is production quality software. In addition, the post explicitly, unambiguously, and repeatedly screams at you that this is highly experimental, unreliable, spaghetti code, meant for writing spaghetti code.

The blog post could not possibly have been more clear.

> ...because you did it to yourself.

No, you're doing this to his words.

Don't believe me? Copy-paste his post into any LLM and ask it whether the post is contradictory or whether it's ambiguous whether this is production-grade software or not. No objective reader of this would come to the conclusion that it's ambiguous or misleading.

Our industry is held back in so many ways by engineers clinging to black-and-white thinking.

Sometimes there isn’t a “final” answer, and sometimes there is no “right” answer. Sometimes two conflicting ideas can be “true” and “correct” simultaneously.

It would do us a world of good to get comfortable with that.

I think it's possible to convey that you believe strongly in your idea and it could be the future (or "is the future" if you're so sure of self) while it still being experimental. I think he would get less critics if he wasn't so hyperbolic in his pitch and had fewer inflammatory personal remarks about people who he hasn't managed to bring on side.

People I know who communicate like that generally struggle to contribute constructively to nuanced discussions, and tend to seek out confrontation for the sake of it.

I think what’s next after an experiment very often is another experiment, especially when you’re doing this kind of exploratory R&D.

> $GAS is not equity and does not give you any ownership interest in Gas Town or my work. This post is for informational purposes only and is not a solicitation or recommendation to buy, sell, or hold any token. Crypto markets are volatile and speculative — do not risk money you can’t afford to lose.

...

> Note: The next few sections are about online gambling in all its forms, where “investing” is the buy-and-hold long-form “acceptable” form of gambling because it’s tied to world GDP growth. Cryptocurrencies are subject to wild swings and spikes, and the currency tied to Gas Town is on a wild swing up. But it’s still gambling, and this stuff is only for people who are into that… which is not me, and should probably not be you either.

In the next post he said he wasn't going to shill it any more, and then the price collapsed and people sent him death threats on Twitter. It probably would have collapsed anyway. Perhaps there was supposedly some implicit bargain that he shouldn't take the money if he wasn't going to shill? Well, there's certainly no rule saying you have to do that.

I think he's not very much to blame for taking the money from degenerate gamblers, and the cryptocurrency idiots are mostly to blame for their own mistakes.

Exactly!

https://steve-yegge.medium.com/bags-and-the-creator-economy-...

A couple of days ago I was sitting in a meeting of 10-15 devs, discussing our AI agents. People were raising issues and brainstorming ways around the problems with AI. How to make the AI better.

Our devs were occupied doing AI things, not accounting/banking things.

If the time savings were as promised, we should have been 3 devs (with the remaining devs replaced by 7-10 AI agents) discussing accounting/banking.

If Gas Town succeeds, it will just be the next toy we play with instead of doing our jobs.

I go to tech meetups regularly. The speed at which any conversation end up on the topic of AI is extremely grating to me. No more discussions about interesting problems and creative solutions that people come up with. It's all just AI, agentic, vibe code.

At what point are we going to see the loss of practical skills if people keep on relying on LLMs for all their thinking?

(And similar to the two, I expect many of the initial ideas for LLM application to be bad, perhaps obviously stupid in hindsight. But enough of them will work to make LLMs become a lasting thing in every aspect of people's lives - again, just like electricity and the Internet did).

I ran a 260KB session log where I convened a simulated symposium of computing pioneers to design an Adventure Compiler — a tool that compiles YAML adventure definitions that run on MOOLLM under cursor into standalone deterministic browser games requiring no LLM at runtime.

The twist: the "attendees" include AI-simulated tributes to Will Wright, Alan Kay, Marvin Minsky, Seymour Papert, Ted Nelson, Ken Kahn, Gary Drescher, and 25+ others — both living legends and memorial candles for those who've passed. All clearly marked as simulated tributes, not transcripts.

What emerged from this thought experiment:

- Pie menus as the universal interface (rooms, inventory, dialogue trees)

- Sims-style needs system with YAML Jazz inner voice ("hunger: 1 # FOOD. FOOD. FOOD.")

- Prototype-based objects (Self/JavaScript delegation chains)

- Schema mechanism + LLM = "teaching them to fly"

- Git as the collaboration operating system

- ToonTalk-inspired "programming by petting" for terpene kittens

- Speed of Light simulation — the opposite of "carrier pigeon" multi-agent architectures

On that last point: most multi-agent systems use message passing between separate LLM calls. Agent A generates output, it gets detokenized to text, sent over IPC, retokenized into Agent B's context. MOOLLM inverts this. Everything happens in one LLM call.

The spatial MOO map (rooms connected by exits) provides navigation, but communication is instantaneous within a call. Many agents, many turns, zero latency between them — and zero token requantization or semantic noise from successive detokenization/tokenization loops.

The session includes adversarial brainstorming where Barbara Liskov challenges schema contracts, James Gosling questions performance, Amy Ko pushes accessibility, and Bret Victor demands immediate feedback. Each critique gets a concrete response.

Concrete outputs: a working linter, architecture decisions, 53 indexed topics from "Food Oriented Programming" to "Hidden Objects as Invisible Infrastructure."

This is MOOLLM's Play-Learn-Lift methodology in action — play with ideas, extract patterns, lift into reusable skills and efficient scripts.

Session log (260KB, 8000+ lines): https://github.com/SimHacker/moollm/blob/main/examples/adven...

MOOLLM repo: https://github.com/SimHacker/moollm

The session uses representation ethics guidelines — all simulated people are clearly marked, deceased figures invoked with memorial candles, and the framing is explicitly "educational thought experiment."

Happy to discuss the ethics of simulating people, the architecture decisions, or how this relates to my earlier Gas Town comparison post.

Then Opus 4.5 was released. I had already had my CC cluade.md, and Windsurf global rules + workspace rules set up. Also, my main money making project is React/Vite/Refine.dev/antd/Supabase... known patterns.

My point is that given all that, I can now deploy amazing features that "just work," and have excellent ux in a single prompt. I still review all commits, but they are now 95% correct on front end, and ~75% correct on Postgres migrations.

Is it magic? Yes. What's worse is that I believe Dario. In a year or so, many people will just create their own Loom or Monday.com equivalent apps with a one page request. Will it be production ready? No. Will it have all the features that everyone wants? No. But it will do that they want, which is 5% of most SaaS feature sets. That will kill at least 10% of basic SaaS.

If Sonnet 3.5 (~Nov 2024) to Opus 4.5 (Nov 2025) progress is a thing, then we are slightly fucked.

"May you live in interesting times" - turns out to be a curse. I had no idea. I really thought it was a blessing all this time.

Like, why are you manually tidying and fixing things? The first pass is never perfect. Maybe the functionality is there but the code is spaghetti or untestable. Have another agent review and feed that review back into the original agent that built out the code. Keep iterating like that.

My usual workflow:

Agent 1 - Build feature Agent 2 - Review these parts of the code, see if you find any code smells, bad architecture, scalability problems that will pop up, untestable code, or anything else falling outside of modern coding best practices Agent 1 - Here's the code review for your changes, please fix Agent 2 - Do another review Agent 1 - Here's the code review for your changes, please fix

Repeat until testable, maybe throw in a full codebase review instead of just the feature.

Agent 1 - Code looks good, start writing unit tests, go step by step, let's walk through everything, etc. etc. etc.

Then update your .md directive files to tell the agents how to test.

Voila, you have an llm agent loop that will write decent code and get features out the door.

I've written two seperate moderately-sized codebases using agentic techniques (oftentimes being very lazy and just blanket approving changes), and I don't encounter logic or off-by-one errors very often if at all. It seems quite good at the basic task of writing working code, but it sucks at architecture and you need occasional code review rounds to keep the codebase tidy and readable. My code reviews with the AI are like 50% DRY and separating concerns

You can't be too prescriptive or verbose when interacting with them, you have to interact with them a bit to start understanding how they think and go from there to determine what information or context to provide. Same for understanding their programming styles, they will typically do what they're told but sometimes they go on a tangent.

You need to know how to communicate your expectations. Especially around testing and interaction with existing systems, performance standards, technology, the list goes on.

The problem is some 0.05X developers thought they were 0.5X and now they think they're 2X.

One thing that stands out in your steps and that I’ve noticed myself- yeah, by prompt 10, it starts to suck. If it ever hits “compaction” then that’s beyond the point of return.

I still find myself slipping into this trap sometimes because I’m just in the flow of getting good results (until it nosedives), but the better strategy is to do a small unit of work per session. It keeps the context small and that keeps the model smarter.

“Ralph” is one way to do this. (decent intro here: https://www.aihero.dev/getting-started-with-ralph)

Another way is “Write out what we did to PROGRESS.md” - then start new session - then “Read @PROGRESS.md and do X”

Just playing around with ways to split up the work into smaller tasks basically, and crucially, not doing all of those small tasks in one long chat.

Maybe that is the time to start making changes by hand. I think this dream of humans never ever writing any more code might be too far and unnecessary.

But I still haven't actually used Gastown. It looks cool. I think it probably works, at least somewhat. I get it. But it's just not what I need right now. It's bleeding edge and experimental.

The main thing holding me back from even tinkering with it is the cost. Otherwise I'd probably play with it a little, but it's not something I'd expect to use and ship production code right now. And I ship a ton of production code with claude.

It's your coworker's problem. The one who actually understands the big picture and how the system fits into it. They'll deal with it.

For example, he makes a comment to the effect that anyone using an IDE to look at code in 2026 is a "bad engineer."

No, he threw up a hyperbolic warning and then dove deep into how this is the future of all coding in the rest of his talks/writing.

It’s as good a warning as someone saying “I’m not {X} but {something blatantly showing I am X}”

Compilers are deterministic. People who write them test that they will produce correct results. You can expect the same code to compile to the same assembly.

With LLMs two people giving the exact same prompts can get wildly different results. That is not a tool you can use to blindly ship production code. Imagine if your compiler randomly threw in a syscall to delete your hard drive, or decide to pass credentials in plain text. LLMs can and will do those things.

For me the difference is prognosis. Gas Town has no ratchet of quality: its fate was written on the wall since the day Steve decided he didn't want to know what the code says: it will grow to a moderate but unimpressive size before it collapses under its own weight. Even if someone tried to prop it up with stable infra, Steve would surely vibe the stable infra out of existence since he does not care about that

With LLMs all bets are off. Is your code going to import leftpad, call leftpad-as-a-service, write its own leftpad implementation, decide that padding isn't needed after all, use a close-enough rightpad instead? Who knows! It's just rolling dice, so have fun finding out!

But as a programmer writing C code, you're still building out the software by hand. You're having to read and write a slightly higher level encoding of the software.

With vibe coding, you don't even deal with encodings. You just prompt and move on.

Vibecoding is literally just random probabilistic mapping between unknown inputs and outputs on an unknown domain.

Feels like saying because I don't know how my engine works that my car could've just been vibe-engineered. People have put 1000s of hours into making certain tools work up to a give standard and spec reviewed by many many people.

"I don't know how something works" != "This wasn't thoughtfully designed"

Why do people compare these things.

1. Chefs do learn the chemistry, at least enough to know why their techniques work.

2. Food scientist is a real job

3. The supply chain absolutely does have scientists involved in day to day operations lol.

A better analogy is just shoving the entire contents of the fridge into a pot, plastic containers and all, and assuming it'll be fine.

Any examples you can share?

I have 100% vibecoded software that I now use instead of commercial implementation that cost me almost 200 usd a month (tool for radiology dictation and report generation).

You always have to review overall diff though and go back to agent with broader corrections to do.

I don't know why people keep repeating this but it's wrong. It works.

Parallelism and BFS style approaches do not exhibit this property. Anything that happens within the context or token stream is a much weaker solution. Most agent frameworks are interested in appearance of speed, so they miss out on the nuance of this execution model.

He's thrown out his experiments before. Maybe he'll start over one more time.

So apparently the medical field is not above this logic.

I think if you'd read the article through you'd know they were serious coz Yegge all but admits this himself.

> 3 days

still seems slow! I’m saying what happens in 2028 when your entire project is 5-10 minutes of total agent runtime - time actually spent writing code and implementing your plan? Trying to parallelize 10m of work with a “town” of agents seems like unnecessary complexity.

I believe agentic coding could eventually be a paradigm shift, if and only if the agents become self-conscious of design decisions and their implications on the system and its surrounding systems as a whole.

If that doesn’t happen, the entire workflow devolves into specifying system states and behavior in natural language, which is something humans are exceedingly bad at.

Coincidently, that is why we have invented programming languages: to be able to express program state and behavior unambiguously.

I’m not bullish on a future where I have to write specifications on all explicit and implicit corner and edge cases just to have an agent make software design choices which don’t feel batshit insane to humans.

We already have software corporations which produce that kind of code simply because the people doing the specifying don’t know the system or the domain it operates in, and the people doing the implementing of those specifications don’t necessarily know any of that either.

I take it you never played The Sims? The simulation madness ship sailed 26 years ago, and made well over $5 billion in revenue for Maxis/EA (as of 2019), and that's if you don't even count SimCity that shipped in 1986! ;)

The Sims Franchise Has Made Over $5 Billion In Revenue (Published Oct 30, 2019):

https://www.thegamer.com/the-sims-franchise-revenue-over-5-b...

Palm is a fictional character in a text adventure -- same tradition as Zork, LambdaMOO, and every MUD since 1978. The emojis are deliberate (navigation aids for LLMs, actually, and ethical simulated person flagging). The whimsy is intentional.

emoji-disclosure.yml -- Visual Markers for Representation Ethics:

https://github.com/SimHacker/moollm/blob/main/skills/represe...

I've been building simulated characters, world and city building tools since before The Sims shipped. This is just the next iteration.

The Sims Steering Committee - June 4 1998:

https://www.youtube.com/watch?v=zC52jE60KjY

You may recognize tributes to many classic simulated characters in MOOLLM.

MC Frontalot -- It Is Pitch Dark:

https://www.youtube.com/watch?v=4nigRT2KmCE

The Grue monster carries his own game mechanics with him, eating you if you go for long enough in the maze without your lamp lit:

grue: https://github.com/SimHacker/moollm/tree/main/examples/adven...

The Wumpus has prototypes for his game playing pieces in his character directory, and even the BASIC source code as the single source of truth:

https://en.wikipedia.org/wiki/Wumpus

wumpus-snorax: https://github.com/SimHacker/moollm/tree/main/examples/adven...

BOTTOMLESS-PIT.yml: https://github.com/SimHacker/moollm/blob/main/examples/adven...

SUPERBATS.yml: https://github.com/SimHacker/moollm/blob/main/examples/adven...

Hunt the Wumpus — Original BASIC Source (1973), By Gregory Yob, published in Creative Computing (October 1975) and The Best of Creative Computing (1976):

https://github.com/SimHacker/moollm/blob/main/examples/adven...

The Grue and the Wumpus can both orchestrate their games in the same maze at the same time without interference! No special hacks required, they all just compose and interoperate seamlessly and naturally.

The monkey named "Palm" multiply inherits directly from Lucas Art's game "Monkey Island" and W. W. Jacobs' classic book, "The Monkey's Paw", all thanks to Self's simple, flexible, prototype object model:

Monkey Island: https://en.wikipedia.org/wiki/Monkey_Island

The Monkey's Paw: https://en.wikipedia.org/wiki/The_Monkey%27s_Paw

Palm's CHARACTER.yml Soul File:

https://github.com/SimHacker/moollm/blob/main/examples/adven...

  # ONTOLOGICAL INHERITANCE
  inherits:
    - skills/fictional     # A character in the adventure
    - skills/mythic        # Origin as cursed artifact
    - skills/animal        # Now a whole monkey

  # TRADITION INVOCATION (Self Prototype Multiple Inheritance)
  # Palm inherits from multiple well-known fictional traditions,
  # simply by naming them — they're so deeply embedded in the training
  # data that invocation IS inheritance. No copying needed.
  # See:

MOOLLM is deliberately playful, in the spirit and tradition of Seymour Papert's Constructionist Philosophy, and Mitchel Resnick's Lifelong Kindergarten -- it's a text adventure game framework, not a vibe-coded hallucination. The monkey writes philosophy because that's funnier than a generic NPC.

And it makes fun of crypto scams instead of shilling them:

https://github.com/SimHacker/moollm/blob/main/skills/economy...

Time Cube didn't have rubric-scored game sessions with receipts, and MOOLLM isn't racist like Terry Davis, so you can easily clone on github and play with in Cursor yourself.

Seymour Papert and Idit Harel: Situating Constructionism:

https://web.media.mit.edu/~calla/web_comunidad/Reading-En/si...

Lifelong Kindergarten: how to learn like a kid, from the co-creator of Scratch:

https://www.media.mit.edu/articles/lifelong-kindergarten-how...

And yes, it works great, and is fun and easy to author, faster and for less money than Steve's costly "Infinite Number of Typewriters Communicating Via Carrier Pigeon" approach.

And since you mentioned you like fully-introspectable modern virtual machines:

https://combo.cc/posts/what-i-would-like-to-see-in-a-modern-...

sph> What I would like to see in a modern Virtual Machine

sph> As I was gathering inspiration (or doing research, if you want to be fancy about it) for the fully-introspectable computing platform introduced in the previous post, I figured it might be worth taking the idea of abstracting the hardware, to make user-facing software easier to program, to its limit.

You should check out the practical MOOLLM skill Cursor Mirror, introspection into cursor prompts, thought, and context assembly:

https://github.com/SimHacker/moollm/tree/main/skills/cursor-...

>Ever wondered what the hell Cursor is actually doing? Why it read 47 files when you asked a simple question? What context it assembled? What it was thinking in those hidden reasoning blocks?

>cursor-mirror cracks open Cursor's brain. 59 read-only commands to inspect every conversation, every tool call, every file it touched, every decision it made. SQLite databases + plaintext transcripts + cached tool results — all intertwingled, all queryable.

Here is an example Cursor Mirror report on a complex long running simulation, dynamic rule generation, and coherent image generation:

Cursor Mirror Analysis: Amsterdam Fluxx Championship: Deep comprehensive scan of the entire FAFO tournament development:

https://github.com/SimHacker/moollm/blob/main/skills/experim...

It's seamlessly composable with other skills, and here are two practical exemplary skills built on top of Cursor Mirror:

Skill Snitch provides security auditing for MOOLLM skills through static analysis and runtime surveillance, like Little Snitch for LLMs.

https://github.com/SimHacker/moollm/tree/main/skills/skill-s...

>Security auditing for MOOLLM skills through static analysis and runtime surveillance.

>Skill Snitch is a prompt-driven skill (no Python code) that audits skills for security issues. It's entirely data-driven and extensible.

Thoughtful Commitment writes git commits that link to the thinking that produced them.

https://github.com/SimHacker/moollm/tree/main/skills/thought...

>When you work with an AI coding assistant, the session holds valuable context: what you asked, what the AI considered, what alternatives were rejected, why it made certain choices. When you close the IDE, all of that vanishes. Your commit says "fix: auth bug" but six months later you have no idea why.

>This skill captures that ephemeral reasoning and freezes it into permanent git history.

In claude I have a code-reviewer agent, and I remind cc often to run the code reviewer before closing any bead. It works surprisingly well.

I used to monitor context and start afresh when it reached ~80%, but I stopped doing that. Compacting is not as disruptive as it used to be, and with beads agents don't lose track.

I spent some time trying to measure the productivity change due to beads, analysing cc and codex logs and linking them to deltas and commits in git [1]. But I did not fully believe the result (5x increase when using beads, there has to be some hidden variable) and I moved on to other things.

Part of the complexity is that these days I often work on two or three projects at the same time, so attribution is difficult.

[1] Analysis code is at https://github.com/juanre/agent-taylor