HN

Comments (113)

• Menu

  dchuk
  I’m very bought in to the idea that raw coding is now a solved problem with the current models and agentic harnesses. Let alone what’s coming in the near term.That being said, I think we’re in a weird phase right now where people’s obvious mental health issues are appearing as “hyper productivity” due to the use of these tools to absolutely spam out code that isn’t necessarily broadly coherent but is locally impressive. I’m watching multiple people both publicly and privately clearly breaking down mentally because of the “power” AI is bestowing on them. Their wires are completely crossed when it comes to the value of outputs vs outcomes and they’re espousing generated nonsense as it’s thoughtful insight.It’s an interesting thing to watch play out.
• Menu

  bastawhiz
  The idea of gas town is simultaneously appealing and appalling to me. The waste and lack of control is wild, but at the same time there's at least a nugget of fascinating, useful work in there. In a world where compute is cheap and abundant and the models are a notch smarter, I think it's the start of a useful framework for what the future of augmented work might look like.I have no interest in using gas town as it is (for a plethora of reasons, not the least of which being that I'm uninterested in spending the money), but I've been fascinated with the idea of slowing it down and having it run with a low concurrency. If you've got a couple A100s, what does it look like if you keep them busy with two agents working concurrently (with 20+ agents total)? What does it mean to have the town focus the scope of work to a series of non-overlapping changesets instead of a continuous stream of work?If you don't plan to have it YOLO stuff in realtime and you can handle the models being dumber than Claude, I think you can have it do some really practical, useful things that are markedly better than the tools we have today.
• Menu

  keyle
  I'd help build Gas City and Gas State, and Gas Country if that would mean we actually would solve the things AI promised to solve. All sickness, famine, wealth ...The problem is, we're just fidgeting yolo-fizzbuzz ad nauseam.The return on investment at the moment is probably one of the worst in the history of human investments.AI does improve over time, still today, but we're going to run out of planet before we get there...
• furyofantares
  A couple/few years ago people were trying to do agents by just putting the LLM in a loop and letting it go, and it was just awful and didn't work at all. I think a bunch of things had to happen over the course of 1-2 years to get to coding agents being a real, useful thing: models had to get quite a bit smarter/cheaper/faster, models had to get good at tool use, and they needed to be executed in well-built harnesses with good tools available.This feels like the same thing. Too early, but we're definitely headed in the direction of finding ways to use more tokens to get more mileage per prompt.
• vessenes
  Very minor nit -- crew could be a person also - in fact that's how you're supposed to hack on a codebase in gas town directly - add yourself as crew.Other than that, this is a helpful list especially for someone who hasn't been hacking around on this thing as it's in rapid development mode. I find gas town super interesting, and tantalizingly close to being amazingly useful. That said, I wouldn't mind a slightly less 'flavored' set of names for workers.
• Menu

  jamestimmins
  I actually love the idea of totally new naming schemes for experimental software.Certain name types are so normalized (agent, worker, etc) that while they serve their role well, they likely limit our imagination when thinking about software, and it's a worthwhile effort to explore alternatives.
• Menu

  bfrog
  Claude is ok. Gas town seems like a Claude multiplier. I’m not sure more Claude is what I’d even want!Not sure I love what it does all the time, it tends to fit whatever box you setup and will easily break out if you aren’t veeeery specific. Is it better than writing a few thousand lines of code myself that I deeply understand that can debug and explain? I don’t know yet. I think it’d be good for writing functions one at a time with massive supervision.It’s great for writing scripts and things where precision and correctness outside the success path isn’t really needed. If a script fails and it wasn’t deleting a hard drive who cares. If my embedded code fails out in a product in the wild this is a much bigger nuisance and potentially fatal for the device (not the humans) which is wasteful.
• Menu

  fdr
  I use beads quite a bit, but not as steve intended. And definitely the opposite of "Gas Town," where I use the note-taking capability and integration with Git (that is, as something of a glorified Makefile and database) to debug contexts, to close the loop and increase accuracy over time. Nevertheless, it has been useful for large batch runs over my code base: the record has been processing for thirty hours straight while getting something useful, and enough trace data to make further improvements.Steve has gone "a bit" loopy, in a (so far) self aware manner, but he has some kind of insight into the software engineering process, I think. Yet, I predict beads will break under the weight of no-supervision eventually if he keeps churning it, but some others will pick up where he left off, with more modest goals. He did, to his credit, kill off several generations of project before this one in a similar category.
• zmmmmm
  It seems like one of the key events that needs to happen for any professional domain to take off is for it to develop an "inside" language that nobody else understands. For example, I still don't know what a kanban or a scrum is. So I'm very ill positioned to challenge their use or question how they are done. Hence they got to dodge a whole lot of opposition that would probably have brought it all down. The invention of a new mysterious terminology I think was critical for agile to take off.The problem with this phenomenon is that the same freedom from critique that is seemingly necessary for new domains to establish themselves also detaches them from necessary criticism. There's simply no way to tell if this isn't a load of baloney. And by the time it's a bullet point requirement on CVs to get employed it's too late for anybody to critique it.
• Menu

  devin
  Maintenance Manager Checker Agent and the rest of the nouns Yegge employs are ironic given his Kingdom of Nouns essay.
• vivzkestrel
  - someone really needs to rewrite that entire article without all that jargon
• anon
  undefined
• Menu

  Animats
  This looks familiar to people who have seen how the more elaborate NPC systems work in major multiplayer games. There are lots of semi-independent NPCs, with some degree of overall coordination. Groups of cops or soldiers may have a commander program for tactical coordination, and there may be a higher level system deploying units for strategic purposes.In games, what the NPCs can do is usually rather dumb. Move and shoot is usually most of their functionality. This keeps the overhead down so the system is affordable.Gas Town may be a step towards AIs which have an ongoing sense of what they're doing. I'm not going to get into the "consciousness" debate, but it's closer to liveness.
• Menu

  mccoyb
  I think Yegge and Huntley are smart guys.I don't think they're doing a good job incubating their ideas into being precise and clearly useful -- there is something to be said about being careful and methodical before showing your cards.The message they are spreading feels inevitable, but the things they are showing now are ... for lack of better words, not clear or sharp. In a recent video at AI Engineer, Yegge comments on "the Luddites" - but even for advocates of the technology, it is nigh impossible to buy the story he's telling from his blog posts.Show, don't tell -- my major complaint about this group is that they are proselytizing about vibe coding tools ... without serious software to show for it.Let's see some serious fucking software. I'm looking for new compilers, browsers, OSes -- and they better work. Otherwise, what are we talking about? We're counting foxes before the hunt.In any case, wouldn't trying to develop a serious piece of software like that _at the same time you're developing Gas Town or Loom_ make (what critics might call) the ~Emacs config tweaking for orchestration~ result driven?
• bob1029
  > Persistent Worker Agents, which you talk to directly (not through the Mayor),I had a bit of a chuckle.I think there is value in anything approximating a proposer-verifier loop, but I don't know that this is the most ideal approach.
• 0xbadcafebee
  Anyone have some kind of central hub of finding out about new tools/techniques? I'm convinced that headless multi-agent coordination is the way to go, but it needs a lot of guard rails, one of the biggest of which will be cost-control. I'm sure there will be a lot more developments in this space, but I don't want to just happen across them by accident...
• zbyforgotp
  At some point evolving software instead of designing it will work. Now the evolutionary pressure leads towards churning more tokens.
• Menu

  CuriouslyC
  I don't understand why people are making this so complicated. We have a battle tested SDLC. We don't need to reinvent this shit. We just need to make some affordances in the tools and processes we set up for the majority of the actors in the system to be agents (such as rationing human attention).Spec your software like an architect/po, decompose it into a task dag, then orchestrate for each lane and assemble all change sets in a merge branch rather than constantly repointing head.
• neilv
  I haven't read the Yegge post closely, so just commenting that namespaces (or naming conventions) would make the easier-to-casually-read names more practical...For example, if Polecat becomes GasTown.WorkerAgent (or GasTown.Worker), then you always have both an unambiguous way and a shorthand-in-context way of referring to the concept.(For naming conventions when you don't have namespaces as a language feature, use prefixes within the identifier, such as `GasTown_Worker`.)If GasTown.Worker is implemented with framework Foo, using that framework's Worker concept, GasTown.Worker might have a field named fooWorker of type Foo.Worker. (In the context of the implementation of GasTown, the unqualified name always means the GasTown concept, and you always disambiguate concepts from elsewhere that use the sane generic or similar terms.)Complicated names like GasTown.MaintenanceManagerCheckerAgent might need some creative name shortening, but hopefully are still descriptive, or easy to pick up and remember. Or, if the descriptive and distinguishing name was complicated because the concept is a weird special case within the framework, maybe consider whether it should be rethought.
• rilindo
  The overuse of metaphors makes me feel like this person is trying to reinvent Chef, but for AI.
• Menu

  grebc
  Steve Yegge used to have interesting, albeit long winded, things to say re software.
• Menu

  dcmatt
  Gas Town wasn't satire?
• hota_mazi
  Show, don't tell.If you need ten pages to explain your project and even after I read your description, I'm still left confused why I need it at all, then maybe... I don't need it?
• ipnon
  It's like Conway's Law. Both humans and agents arrive at roughly identical hierarchies for organizing labor. There is something inherent in the game of telephone required by limited working memory that requires this structure. Gas Town's only failure is not being familiar with prior art and coming up with very strange names for established patterns that already exist in large hierarchical organizations like governments, corporations and militaries.
• Menu

  ohazi
  Real, genuinely confused human here: Can someone please clarify whether or not gas town is/was a joke? I've searched repeatedly and can't find anything that looks like an obvious tell, and I'm not sure if this is because it's actually real and people are taking it seriously, or because the pages and pages of discourse surrounding it is AI generated and taking itself literally.If it's not a joke... I have no words. You've all gone insane.
• hota_mazi
  I mean, Gas Town is 100% vibe coded, and its very own author says AI can't be trusted to write reliable code.Draw your own conclusion.
• never_inline
  From Steve yegge's post> Better UIs will come. But tmux is what you have for now. And it’s worth learning.So brother has 2 claude code accounts and couldn't vibe code a UI, huh?
• SomaticPirate
  Don’t forget the apparent crypto grift angle now (something related to BAGS)Ridiculous. Beads might be passable software but gas town just appears to be a good way to burn tokens at the moment
• Menu

  Cedricgc
  I'm developing concern for Steve. He's been a well known developer and writer in the industry for years now (See his popular 'Google Platforms Rant' essay from years ago) [0].Now, Yegge's writing tilts towards the grandoise... see his writing when joining Grab [1] and Sourcegraph [2] respectively versus how things actually played out.I prefer optimism and I'm not anti AI by any means, but given his observed behavior and how AI can't exacerbate certain pathologies... not great. Adding the recent crypto activities on top and all that entails is the ingredients for a powder keg.Hope someone is looking out for him.[0] https://courses.cs.washington.edu/courses/cse452/23wi/papers...[1] https://steve-yegge.medium.com/why-i-left-google-to-join-gra...[2] https://sourcegraph.com/blog/introducing-steve-yegge
• b00ty4breakfast
  [dead]
• jumploops
  I ran the Gas Town intro post through ChatGPT 5.2 Pro[0]Based on my initial read, and a pass at this summary, it seems mostly right. YMMVDid some further dives into the little public usage data from Gas Town, and found that most of the "Beads" are tasks that are broken down quite small, almost too small imo.Super interesting project with the goal of keeping Claude "busy" however it feels more like a casino game than something I'd use for production engineering.[0]https://gist.github.com/jumploops/2e49032438650426aafee6f43d...