Summarizer

I put in 15 hours or so with gas town this weekend, from just around the 0.1 release. Think of as an extended bipolar-optimism-fueled glimpse into the future. Steve's MO is laid out in the medium post - but basically, it's okay to lose things, rewrite whole subsystems, whatever, this is the future. It's really fun and interesting to watch the speed of development. I've made a few multi agent coding setups in the last year, and I think gas town has the team side about right: big boss (mayor), operations boss (deacon), relatively linear keeper of truth (witness), single point for merges (refiner), lots of coders with their code held lightly. I love the idea of formulas - a lot of what makes gas town work and informs how well it ultimately will work is the formulas. They're close conceptually to skills. I don't love the mad max branding, but meh, whatever, it's fun, and a perk of the brave new world where you can make stuff like for a few hundred bucks a month sent to anthropic - software can have personality again, yay. Conceptually I think there is a product team element to this still missing - deploy engineers, product managers, visual testing. Everything is sort of out there, janky in parts, but workable to glue together right now, and will only improve. That said, the mad max town analogy is going to get overstretched at some point; we already have pretty good names for all the parts that are needed, and as coordination improves, we're going to want to add more stuff into the coordination. So, I'd like to see a version of this with normal names and expanded. Upshot - worth a look - if beads is any indication, give it a month or two or four to settle down unless you like living on the bleeding bleeding edge.

I had a lot of fun reading the articles about Gas Town although I started to lose track of the odd naming. Only odd because they make sense to Steve and others who have seen the Mad Max, Water World movies. I promptly gave Claude the text to the articles and had him rewrite using idiomatic distributed systems naming. Fun times!

Care to share that with the rest of the class? I'd love to hear what those idiomatic distributed systems namings are!

Ran it through ChatGPT: Town = Central orchestrator / control plane Rig = Project or workspace namespace Polecat = Ephemeral worker job Refinery = Merge queue manager Witness = Worker health monitor Crew = Persistent worker pool Beads = Persistent work items / tasks Hooks = Work queues / task slots GUPP = Work processing guarantee Molecules/Wisps = Structured, persistent workflows Convoys = Grouped feature work units https://chatgpt.com/share/695c6216-e7a4-800d-b83d-fc1a22fd8a...

Thank you! Is this the future? Everyone gets to have their own cutesy translation of everything? If I want "kubectl apply" to have a Tron theme, while my coworker wants a Disney theme. Is the runbook going to be in Klingon if I'm fluent in that?

I love this take. I think what you're describing is very much happened with the Industrial Revolution. It was just a bunch of powerful, dangerous machines at first, doing small jobs faster. Scaling it up took the whole planet and a long time. I think we are at the beginning of the second such journey. Lots of people will get hurt while we learn how to scale it up. It's why I've gone with dangerous sounding theming and lots of caution with Gas Town. I only think it takes 2 years this time though.

I tried it out but despite what the README says ( https://github.com/steveyegge/gastown ), the mayor didn't create a convoy or anything, the mayor is just doing all the work itself, appearing no different than a `claude` invocation. Update: I was hoping it'd at least be smart enough to automatically test the project still builds but it did not. It also didn't commit the changes. > are you the mayor? Yes. I violated the Mayor protocol - I should have dispatched this work to the gmailthreading crew worktree instead of implementing it directly myself. The CLAUDE.md is clear: "Mayor Does NOT Edit Code" and "Coordinate, don't implement." Maybe Yegge should have build it around Codex instead - Codex is a lot better at adhering to instructions. Pros: The overall system architecture is similar to my own latest attempt at solving this problem. I like the tmux-based console-monitoring approach (rather than going full SDK + custom UI), it makes it easier to inspect what is going on. The overlap between my ideas and Steve's is around 75%. Cons: Arguing with "The Mayor" about some other detached processes poor workmanship seems like a major disconnect and architectural gap. A game of telephone is unlikely to be better than simply using claude. I was also hoping gastown would amplify my intent to complete the task of "Add feature X" without early-stopping, but so far it's more work than both 1. Vibing with claude directly and 2. Creating a highly-detailed spec with checkboxes and piping in "do the next task" until it's done. Definitely looking forward to seeing how the tools in this space evolve. Eventually someone is bound to get it right! P.s. the choice of nomenclature throughout the article is a bit odd, making it hard to follow. Movie characters, dogs and raccoons, huh? How about striving for descriptive SWE clarity?

Naming your energy-guzzling "just throw more agents at it" thingamajig after a location in the post-apocalyptic Mad Max universe is certainly a choice.

There's a simpler design here begging to show itself. We're trying to orchestrate a horde of agents. The workers (polecats?) are the main problem solvers. Now you need a top level agent (mayor) to breakdown the problem and delegate work, and then a merger to resolve conflicts in the resulting code (refinery). Sometimes agents get stuck and need encouragement. The molecules stuff confused me, but I think they're just "policy docs," checklists to do common tasks. But this is baby stuff. Only one level of hierarchy? Show me a design for your VP agent and I'll be impressed for real.