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.
If you give every idiot a worldwide heard voice, you will hear every idiot from the whole world. If you give every idiot a tool to make programs, you will see a lot of programs made by idiots.
There is a lot of research on how words/language influences what we think, and even what we can observe, like the Sapir-Whorf hypothesis. If in a langauge there is one word for 2 different colors, speakers of it are unable to see the difference between the colors.
I have a suspicion that extensive use of LLMs can result in damage to your brain. That's why we are seeing so many mental health issues surfacing up, and we are getting a bunch of blog posts about "an agentic coding psychosis".
It could be that llms go from bicycles for the brain to smoking for the brain, once we figure out the long term effects of it.
> If in a langauge there is one word for 2 different colors, speakers of it are unable to see the difference between the colors.
That is quite untrue. It is true that people may be slightly slower or less accurate in distinguishing colors that are within a labeled category than those that cross a category boundary, but that's far from saying they can't perceive the difference at all. The latter would imply that, for instance, English speakers cannot distinguish shades of blue or green.
> If in a langauge there is one word for 2 different colors, speakers of it are unable to see the difference between the colors.
Perhaps you mean to say that speakers are unable to name the difference between the colours?
I can easily see differences between (for example) different shades of red. But I can't name them other than "shade of red".
I do happen to subscribe to the Sapir-Whorf hypothesis, in the sense that I think the language you think in constrains your thoughts - but I don't think it is strong enough to prevent you from being able to see different colours.
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.
I put it in a VM and had it build a really simple todo app for me the other day. It wasted so many tokens that I can't help but agree with you right now. And I could certainly have done the same thing with beads and opus in approximately the same amount of time.
However, the gas town one was almost completely hands off. I think my only interventions were due to how beta it was, so I had to help it work around its own bugs to keep from doing stupid things.
Other than that, it implemented exactly what I asked for in a workable fashion with effectively one prompt. It would have taken several prompts and course corrections to get the same result without it.
Other than the riskyness (it runs in dangerous permissions mode) and incredible cost inefficiency, I'd certainly use it.
If gas town can actually do stuff well at any price it'll have a radical impact on how society is organized, because there are people out there who have practically unlimited money (billions of dollars of their own to spend, plus they can get the government to print more dollars for them if necessary; you probably already know who a few of these people are).
I've only started using coding agents recently and I think they go a long way to explain why different people get different mileage from "AI." My experience with Opencode using its default model, vs. Github Copilot using its default model, is night and day. One is amazing, the other is pretty crappy. That's a product of both the software/interface and the model itself I'd suspect.
Where I think this goes in the medium term is we will absolutely spin up our own teams of agents, probably not conforming to the silly anthropomorphized "town" model with mayors and polecats and so on, but they'll be specialized to particular purposes and respond to specific events within a software architecture or a project or even a business model. Currently the sky's the limit in my mind for all the possible applications of this, and a lot of it can be done with existing and fairly cheap models too, so the bottleneck is, surprise surprise... developer time! The industry won't disappear but it will increasingly revolve around orchestrating these teams of models, and software will continue to eat the world.
If software engineers can agree on anything, it's that LLM experiences are wildly inconsistent. People have similar inconsistencies. We have different experiences, intellects, educations, priorities, motivations, value systems. And in software specifically (and institutions generally) we create methodologies and processes that diminish our inconsistencies and leverage our strengths.
Gas town is a demonstration of a methodology for getting a consistent result from inconsistent agents. The case in point is that Yegge claims to have solved the MAKER problem (tower of Hanoi) via prompting alone. With the right structure, quantity has a quality all its own.
I feel like each of these things is going to be bitter lessoned by a model who you can just say "yeah get a bunch of agents together and clone twitter, get em to put requirements together first, ya know, measure once and all that. promise em a beer when done".
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...
As of yet, the AI models doing important work are still pretty specialized. I'd be happy to pitch in to run something like an open source version of alpha-fold, but I'm not aware of any such projects.
I have trouble seeing LLMs making meaningful progress on those frontiers without reaching ASI, but I'd be happy to be wrong.
I think part of the problem/difference is that all "important work" needs to be auditable and understood by humans. We need to be able to fix bugs, and not just roll the dice and hoping that a lack of symptoms means everything is cured.
The prototype phase meant data centers are now measured in MW instead of TFLOPS.
At a time where we were desperate to reduce emissions, data centers now consume around 20% of the energy consumed by the entire aviation sector, with consumption is rising at 15% YoY.
Never mind the water required to cool them, or the energy and resources required to build them, the capital allocation, and the opportunity cost of not allocating all of that to something else.
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.
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.
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.
This reminds me of Moldbug's Urbit. I can't be bothered to look it up, but his comment was along the lines of "existing words bring assumptions, so safest to make new ones". To which, my comment would be: perflufflington flibnik qupnux.
I do too, but you can take things too far, which I'd argue has happened the moment "figuring out what the names mean" becomes enough of an intellectual challenge to provide a dopamine hit; at that point, you've (intentionally or otherwise) germinated a cult. It's human nature: people will support the design not on its merits but rather as loss aversion for the work they put into decoding it.
Yes at some point innovative software and naming are at cross purposes, and if your naming gets too extreme ultimately that will get all of the attention.
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.
I’d like gastown more if it could run cursor-CLI instead of claude, and thus be able to choose models. Claude is okay. But these things certainly have personalities. I’m not sure which would be best for each role. But gastown’s different actors seem like a great place to take advantage of the different quirks of each. And I certainly don’t choose Claude consistently when given a choice.
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.
That entire article sounds like my friends who think AI is real and keep sending their parents money into crypto scams.
I think I’ll just develop a drinking problem if this is Gas Town becomes something real in the industry and this kind of person is now one of our thought leaders.
that's one reason I am less worried about him than some, although, I don't want to say that only to have something bad happen to him, that is, a form of complacency. Just because (say) Boltzmann and Cantor had useful insights along the way didn't mean people shouldn't have been looking to support them.
the main area I'd like to see some departure from beads is to use markdown files (or something) to be able to see the issue context/comments better in a diff generated by git.
The other area I'd like to see some software engineering thinking that's more open ended is on regression testing: ways of storing or referencing old versions of texts to see if the agent can complete old transformations properly even with a context change that patches up a weakness in a transformation that is desirable. This is tricky as it interacts with something essential in software engineering, the ability to run test suites and responding to the outcome. I don't think we know yet when to apply what fidelity of testing, e.g. one-shot on snippets versus a more realistic test based on git worktrees.
This is not something you'd want for every context, but a lot of my effort is spent building up prompt fragments to normalize and clean up the code coming out of a model that did some ad-hoc work that meets the test coverage bar, which constrains it decently into having achieved "something." Kind of like a prototype. But often, a lot of ungratifying massaging is required to even cover the annoying but not dangerous tics of the LLM, to bring clarity to where it wrote, well, very bad and unprincipled code...as it does sometimes.
I was disappointed to see that this is still 10x the code needed for the feature set and that it still insists on duplicating state into a SQLite index for such minuscule amounts of data.
I've seen 25-30 similar efforts to make a Beads alternative and they all do this for some reason.
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.
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.
What games are notable in this regard? The classic Majesty series comes to mind. UO aspired to complex NPC systems. Fable as well. I always dreamt of a more advanced Sim City-meets-MMO that just went all in on that.
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?
Here's a separate, optimistic comment about Yegge and Huntley: they are obviously on the right track.
In a recent video about Loom (Huntley's orchestration tool), Huntley comments:
"I've got a single goal and that is autonomous evolutionary software and figuring out what's needed to be there."
which is extremely interesting and sounds like great fun.
When you take these ideas seriously, if the agents get better (by hook and crook or RLVR) -- you can see the implications: "grad student descent" on whatever piece of software you want. RAG over ideas, A/B testing of anything, endless looping, moving software.
It's a nightmare for the model of software development and human organization which is "productive" today, but an extremely compelling vision for those dabbling in the alternative.
It's a science project. I think the "I am so crazy" messaging is deliberate to scare most people away while attracting a few like-minded beta testers. He's telling you not to use it, which some people will take as a dare...
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...
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.
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.
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?
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.
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.
It's not a joke, but I think it's an example of the same thing we're seeing with folks who think they're talking to god when they talk to ChatGPT, or those who spiral and in some cases, sadly take their own life.
These chatbots create an echo chamber unlike that which we've ever had to deal with before. If we thought social media was bad, this is way worse.
I think Gastown and Beads are examples of this applied to software engineering. Good software is built with input from others. I've seen many junior engineers go off and spend weeks building the wrong thing, and it's a mess, but we learn to get input, we learn to have our ideas critiqued.
LLMs give us the illusion of pair programming, of working with a team, but they're not. LLMs vastly accelerate the rate at which you can spiral spiral down the wrong path, or down a path that doesn't even make sense. Gastown and Beads are that. They're fever dreams. They work, somewhat, but even just a little bit of oversight, critique, input from others, would have made them far better.
It's a double edged sword. If it can lead the uninformed down the wrong path faster, it can lead the informed down the right path faster. It's not only fast in one direction.
The problem with Gas Town is how it was presented. The heavy metaphor and branding felt distracting.
It’s a bit like reading the Dune book, where you have to learn a whole vocabulary of new terms before you can get to the interesting mechanics, which is a tough ask in an already crowded AI space.
Gas town is the cackling mad laughter emitting from someone who knows they are being both insane and prescient simultaneously. Today, it is insane. But I fully expect to be hearing about a very serious thing in the near future about which people will say “gas town was an early attempt at this”
I've been tinkering with it for the past two days. It's a very real system for coordinating work between a plurality of humans and agents. Someone likened it to kubernetes in that it's a complex system that is going to necessitate a lot of invention and opinions, the fact that it *looks* like a meme is immaterial, and might be an effort to avoid people taking it too seriously.
Who knows where it ends up, but we will see more of this and whatever it is will have lessons learned from Gas Town in it.
It's a real open source tool Yegge has built and been using for a while now. And no, it's not insane, he's literally written a book with Gene Kim about the fundamental lessons that go into it, and he's been on lots of podcasts where he explains more.
I expect major companies will soon be NIH-ing their own version of it. Even bleeding tokens as it does, the cost is less than an engineer, and produces working software much faster. The more it can be made to scale, the more incentive there is. A competitive business can't justify not using a system like this.
> If it's not a joke... I have no words. You've all gone insane.
How is it insane to jump to the logical conclusion of all of this? The article was full of warnings, its not a sensible thing to do but its a cool thing to do. We might ask whether or not it works, but does that actually matter? It read as an experiment using experimental software doing experimental things.
Consider a deterministic life form looking at how we program software today, that might look insane to it and gastown might look considerably more sane.
Everything that ever happens in human creation begins as a thought, then as a prototype before it becomes adopted and maybe (if it works/scales) something we eventually take for granted. I mean I hate it but maybe I've misunderstood my profession when I thought this job was being able to prove the correctness of the system that we release. Maybe the business side of the org was never actually interested in that in the first place. Dev and business have been misaligned with competing interests for decades. Maybe this is actually the fit. Give greater control of software engineering to people higher up the org chart.
Maybe this is how we actually sink c-suite and let their ideas crash against the rocks forcing c-suite to eventually become extremely technical to be able to harness this. Instead of today's reality where c-suite gorge on the majority of the profit with an extremely loosely coupled feedback loop where its incredibly difficult to square cause and effect. Stock went up on Tuesday afternoon did it? I deserve eleventy million dollars for that. I just find it odd to crap on gastown when I think our status quo is kinda insane too.
It's kinda like how edgy political takes are often wrapped in seven layers of meta-irony. If the audience reaction is negative you can say it was just a joke that didn't land.
And that's not necessarily a bad thing, if it allows exploring new ideas with relative safety. I think that's what's going on here. It's a crazy idea that might just work, but if it doesn't work it can be retconned as satirical performance art.
No, not a joke. The author also co-vibe-coded a book, called Vibe Coding, describing and recommending exactly the sort of system he's trying to build as Gas Town.
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.
He was right about Google in [1] when I was still drinking the Kool-Aid, in big and tangible ways that aren't discussed publicly.
[2] is 100% accurate, Grok was the backbone / glue of Google's internal developer tools.
I don't disagree on the current situation, and I'm uncomfortable sticking my neck out on this because I'm basically saying "the guy who kinda seems out of it, totally wasn't out of it, when you think he was", but [1] and [2] definitely aren't grandiose, the claims he makes re: Google and his work there are accurate. A small piece of why I feel comfortable in this, is that both of these were public blogs his employer was 100% happy about when hiring him to top positions.
I should be specific. I think the technical analysis is reasonable and I actually enjoy someone staking on a big vision, which is why I saved these pieces.
An example:
"I’ve seen Grab’s hunger. I’ve felt it. I have it. This space is win or die. They will fight to the death, and I am with them. This company, with some 3000 employees I think, is more unified than I’ve seen with most 5-person companies. This is the kind of focused camaraderie, cooperation and discipline that you typically only see in the military, in times of war.
Which should hardly surprise you, because that’s exactly what this is. This is war.
I am giving everything I’ve got to help Grab win. I am all in. You’d be amazed at what you can accomplish when you’re all in."
This is the writing of someone planning to make a capstone career move instead of leaving in 18 months. It's not the worst thing to do (He says he left b/c the time difference to support a team in SE Asia was hard physically, and he's getting older) and I support taking big swings. I'm just saying Yegge's writing has a pattern.
Crypto and what Yegge is doing with $GAS is dangerous because if the token price crashes and people betting their life savings think he didn't deliver on his promises... I like Steve personally which is why I'm saying anything.
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. YMMV
Did 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.
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.
If you give every idiot a worldwide heard voice, you will hear every idiot from the whole world. If you give every idiot a tool to make programs, you will see a lot of programs made by idiots.
> where people’s obvious mental health issues
I think the kids would call this "getting one-shotted by AI"
Yeah I am definitely trying to stay off hype and just use the damn tool
There is a lot of research on how words/language influences what we think, and even what we can observe, like the Sapir-Whorf hypothesis. If in a langauge there is one word for 2 different colors, speakers of it are unable to see the difference between the colors.
I have a suspicion that extensive use of LLMs can result in damage to your brain. That's why we are seeing so many mental health issues surfacing up, and we are getting a bunch of blog posts about "an agentic coding psychosis".
It could be that llms go from bicycles for the brain to smoking for the brain, once we figure out the long term effects of it.
> If in a langauge there is one word for 2 different colors, speakers of it are unable to see the difference between the colors.
That is quite untrue. It is true that people may be slightly slower or less accurate in distinguishing colors that are within a labeled category than those that cross a category boundary, but that's far from saying they can't perceive the difference at all. The latter would imply that, for instance, English speakers cannot distinguish shades of blue or green.
2 replies →
> If in a langauge there is one word for 2 different colors, speakers of it are unable to see the difference between the colors.
Perhaps you mean to say that speakers are unable to name the difference between the colours?
I can easily see differences between (for example) different shades of red. But I can't name them other than "shade of red".
I do happen to subscribe to the Sapir-Whorf hypothesis, in the sense that I think the language you think in constrains your thoughts - but I don't think it is strong enough to prevent you from being able to see different colours.
8 replies →
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.
I put it in a VM and had it build a really simple todo app for me the other day. It wasted so many tokens that I can't help but agree with you right now. And I could certainly have done the same thing with beads and opus in approximately the same amount of time.
However, the gas town one was almost completely hands off. I think my only interventions were due to how beta it was, so I had to help it work around its own bugs to keep from doing stupid things.
Other than that, it implemented exactly what I asked for in a workable fashion with effectively one prompt. It would have taken several prompts and course corrections to get the same result without it.
Other than the riskyness (it runs in dangerous permissions mode) and incredible cost inefficiency, I'd certainly use it.
If gas town can actually do stuff well at any price it'll have a radical impact on how society is organized, because there are people out there who have practically unlimited money (billions of dollars of their own to spend, plus they can get the government to print more dollars for them if necessary; you probably already know who a few of these people are).
I've only started using coding agents recently and I think they go a long way to explain why different people get different mileage from "AI." My experience with Opencode using its default model, vs. Github Copilot using its default model, is night and day. One is amazing, the other is pretty crappy. That's a product of both the software/interface and the model itself I'd suspect.
Where I think this goes in the medium term is we will absolutely spin up our own teams of agents, probably not conforming to the silly anthropomorphized "town" model with mayors and polecats and so on, but they'll be specialized to particular purposes and respond to specific events within a software architecture or a project or even a business model. Currently the sky's the limit in my mind for all the possible applications of this, and a lot of it can be done with existing and fairly cheap models too, so the bottleneck is, surprise surprise... developer time! The industry won't disappear but it will increasingly revolve around orchestrating these teams of models, and software will continue to eat the world.
I guess tokens get cheaper all the time, and we can fix the risk via sufficient sand boxing. (I mean the risk to your computer.)
1 reply →
If software engineers can agree on anything, it's that LLM experiences are wildly inconsistent. People have similar inconsistencies. We have different experiences, intellects, educations, priorities, motivations, value systems. And in software specifically (and institutions generally) we create methodologies and processes that diminish our inconsistencies and leverage our strengths.
Gas town is a demonstration of a methodology for getting a consistent result from inconsistent agents. The case in point is that Yegge claims to have solved the MAKER problem (tower of Hanoi) via prompting alone. With the right structure, quantity has a quality all its own.
I feel like each of these things is going to be bitter lessoned by a model who you can just say "yeah get a bunch of agents together and clone twitter, get em to put requirements together first, ya know, measure once and all that. promise em a beer when done".
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...
As of yet, the AI models doing important work are still pretty specialized. I'd be happy to pitch in to run something like an open source version of alpha-fold, but I'm not aware of any such projects.
I have trouble seeing LLMs making meaningful progress on those frontiers without reaching ASI, but I'd be happy to be wrong.
I think part of the problem/difference is that all "important work" needs to be auditable and understood by humans. We need to be able to fix bugs, and not just roll the dice and hoping that a lack of symptoms means everything is cured.
AI can't even find a cure for the common cold.
The Wright brothers are idiots, if it were me I'd have made a supersonic jet from the get go and not waste my time mucking around with prototypes.
The prototype phase meant data centers are now measured in MW instead of TFLOPS.
At a time where we were desperate to reduce emissions, data centers now consume around 20% of the energy consumed by the entire aviation sector, with consumption is rising at 15% YoY.
Never mind the water required to cool them, or the energy and resources required to build them, the capital allocation, and the opportunity cost of not allocating all of that to something else.
And this is, your words, the prototype phase.
the Wright brothers sold me a subscription to a supersonic jet and I've got a bundle of matchsticks and some canvas.
We were promised supersonic jets today or very soon though and our economies have been held hostage waiting for that promise.
6 replies →
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.
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.
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.
This reminds me of Moldbug's Urbit. I can't be bothered to look it up, but his comment was along the lines of "existing words bring assumptions, so safest to make new ones". To which, my comment would be: perflufflington flibnik qupnux.
I do too, but you can take things too far, which I'd argue has happened the moment "figuring out what the names mean" becomes enough of an intellectual challenge to provide a dopamine hit; at that point, you've (intentionally or otherwise) germinated a cult. It's human nature: people will support the design not on its merits but rather as loss aversion for the work they put into decoding it.
Yes at some point innovative software and naming are at cross purposes, and if your naming gets too extreme ultimately that will get all of the attention.
1 reply →
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.
I’d like gastown more if it could run cursor-CLI instead of claude, and thus be able to choose models. Claude is okay. But these things certainly have personalities. I’m not sure which would be best for each role. But gastown’s different actors seem like a great place to take advantage of the different quirks of each. And I certainly don’t choose Claude consistently when given a choice.
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.
His latest post is endorsing a crypto exchange because they paid him $50k.
https://steve-yegge.medium.com/bags-and-the-creator-economy-...
That entire article sounds like my friends who think AI is real and keep sending their parents money into crypto scams.
I think I’ll just develop a drinking problem if this is Gas Town becomes something real in the industry and this kind of person is now one of our thought leaders.
To be fair, he's always been a little loopy. At least, I think this post of his was loopy: https://steve-yegge.blogspot.com/2007/06/that-old-marshmallo...
It was also one of my favorite posts of his and has aged incredibly well as my experience has grown.
that's one reason I am less worried about him than some, although, I don't want to say that only to have something bad happen to him, that is, a form of complacency. Just because (say) Boltzmann and Cantor had useful insights along the way didn't mean people shouldn't have been looking to support them.
> but some others will pick up where he left off, with more modest goals
Already happening :-) https://github.com/Dicklesworthstone/beads_rust
the main area I'd like to see some departure from beads is to use markdown files (or something) to be able to see the issue context/comments better in a diff generated by git.
The other area I'd like to see some software engineering thinking that's more open ended is on regression testing: ways of storing or referencing old versions of texts to see if the agent can complete old transformations properly even with a context change that patches up a weakness in a transformation that is desirable. This is tricky as it interacts with something essential in software engineering, the ability to run test suites and responding to the outcome. I don't think we know yet when to apply what fidelity of testing, e.g. one-shot on snippets versus a more realistic test based on git worktrees.
This is not something you'd want for every context, but a lot of my effort is spent building up prompt fragments to normalize and clean up the code coming out of a model that did some ad-hoc work that meets the test coverage bar, which constrains it decently into having achieved "something." Kind of like a prototype. But often, a lot of ungratifying massaging is required to even cover the annoying but not dangerous tics of the LLM, to bring clarity to where it wrote, well, very bad and unprincipled code...as it does sometimes.
I was disappointed to see that this is still 10x the code needed for the feature set and that it still insists on duplicating state into a SQLite index for such minuscule amounts of data.
I've seen 25-30 similar efforts to make a Beads alternative and they all do this for some reason.
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.
Maintenance Manager Checker Agent and the rest of the nouns Yegge employs are ironic given his Kingdom of Nouns essay.
“Maintenance Manager Checker Agent is not a noun Yegge employs”, it is Brinker’s term for Yegge’s “Boot the Dog”.
- someone really needs to rewrite that entire article without all that jargon
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.
What games are notable in this regard? The classic Majesty series comes to mind. UO aspired to complex NPC systems. Fable as well. I always dreamt of a more advanced Sim City-meets-MMO that just went all in on that.
UO? I don't remember any complex NPC systems there. Ultima 7 had daily schedules and the veneer of a functioning economy though
https://www.rockpapershotgun.com/why-fears-ai-is-still-the-b...
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?
Here's a separate, optimistic comment about Yegge and Huntley: they are obviously on the right track.
In a recent video about Loom (Huntley's orchestration tool), Huntley comments:
"I've got a single goal and that is autonomous evolutionary software and figuring out what's needed to be there."
which is extremely interesting and sounds like great fun.
When you take these ideas seriously, if the agents get better (by hook and crook or RLVR) -- you can see the implications: "grad student descent" on whatever piece of software you want. RAG over ideas, A/B testing of anything, endless looping, moving software.
It's a nightmare for the model of software development and human organization which is "productive" today, but an extremely compelling vision for those dabbling in the alternative.
It's a science project. I think the "I am so crazy" messaging is deliberate to scare most people away while attracting a few like-minded beta testers. He's telling you not to use it, which some people will take as a dare...
> 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.
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...
At some point evolving software instead of designing it will work. Now the evolutionary pressure leads towards churning more tokens.
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.
SDLC = Software Development Life Cycle (?)
Correct
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.
The overuse of metaphors makes me feel like this person is trying to reinvent Chef, but for AI.
Steve Yegge used to have interesting, albeit long winded, things to say re software.
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?
Gas Town wasn't satire?
Poe's law &c.
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?
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.
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.
It's not a joke, but I think it's an example of the same thing we're seeing with folks who think they're talking to god when they talk to ChatGPT, or those who spiral and in some cases, sadly take their own life.
These chatbots create an echo chamber unlike that which we've ever had to deal with before. If we thought social media was bad, this is way worse.
I think Gastown and Beads are examples of this applied to software engineering. Good software is built with input from others. I've seen many junior engineers go off and spend weeks building the wrong thing, and it's a mess, but we learn to get input, we learn to have our ideas critiqued.
LLMs give us the illusion of pair programming, of working with a team, but they're not. LLMs vastly accelerate the rate at which you can spiral spiral down the wrong path, or down a path that doesn't even make sense. Gastown and Beads are that. They're fever dreams. They work, somewhat, but even just a little bit of oversight, critique, input from others, would have made them far better.
It's a double edged sword. If it can lead the uninformed down the wrong path faster, it can lead the informed down the right path faster. It's not only fast in one direction.
3 replies →
Not sure you’ve actually tried using it, but beads has been an absolute game changer for my projects. “Game changer” is even underselling it.
8 replies →
I think the underlying approach seems sensible.
The problem with Gas Town is how it was presented. The heavy metaphor and branding felt distracting.
It’s a bit like reading the Dune book, where you have to learn a whole vocabulary of new terms before you can get to the interesting mechanics, which is a tough ask in an already crowded AI space.
1 reply →
Gas town is the cackling mad laughter emitting from someone who knows they are being both insane and prescient simultaneously. Today, it is insane. But I fully expect to be hearing about a very serious thing in the near future about which people will say “gas town was an early attempt at this”
This is the best take I've seen in here.
I've been tinkering with it for the past two days. It's a very real system for coordinating work between a plurality of humans and agents. Someone likened it to kubernetes in that it's a complex system that is going to necessitate a lot of invention and opinions, the fact that it *looks* like a meme is immaterial, and might be an effort to avoid people taking it too seriously.
Who knows where it ends up, but we will see more of this and whatever it is will have lessons learned from Gas Town in it.
It's a real open source tool Yegge has built and been using for a while now. And no, it's not insane, he's literally written a book with Gene Kim about the fundamental lessons that go into it, and he's been on lots of podcasts where he explains more.
I expect major companies will soon be NIH-ing their own version of it. Even bleeding tokens as it does, the cost is less than an engineer, and produces working software much faster. The more it can be made to scale, the more incentive there is. A competitive business can't justify not using a system like this.
Where is the working software it produces? Do you have a repo you've made with it as an example?
> If it's not a joke... I have no words. You've all gone insane.
How is it insane to jump to the logical conclusion of all of this? The article was full of warnings, its not a sensible thing to do but its a cool thing to do. We might ask whether or not it works, but does that actually matter? It read as an experiment using experimental software doing experimental things.
Consider a deterministic life form looking at how we program software today, that might look insane to it and gastown might look considerably more sane.
Everything that ever happens in human creation begins as a thought, then as a prototype before it becomes adopted and maybe (if it works/scales) something we eventually take for granted. I mean I hate it but maybe I've misunderstood my profession when I thought this job was being able to prove the correctness of the system that we release. Maybe the business side of the org was never actually interested in that in the first place. Dev and business have been misaligned with competing interests for decades. Maybe this is actually the fit. Give greater control of software engineering to people higher up the org chart.
Maybe this is how we actually sink c-suite and let their ideas crash against the rocks forcing c-suite to eventually become extremely technical to be able to harness this. Instead of today's reality where c-suite gorge on the majority of the profit with an extremely loosely coupled feedback loop where its incredibly difficult to square cause and effect. Stock went up on Tuesday afternoon did it? I deserve eleventy million dollars for that. I just find it odd to crap on gastown when I think our status quo is kinda insane too.
It doesn't have to exclusively be one or the other.
> If it's not a joke... I have no words. You've all gone insane.
I think this is covered by the part in Yegge's post where he says not to run it unless you're so rich you don't care if it works or not.
How rich do you have to be not care about the environmental cost?
4 replies →
It's kinda like how edgy political takes are often wrapped in seven layers of meta-irony. If the audience reaction is negative you can say it was just a joke that didn't land.
And that's not necessarily a bad thing, if it allows exploring new ideas with relative safety. I think that's what's going on here. It's a crazy idea that might just work, but if it doesn't work it can be retconned as satirical performance art.
No, not a joke. The author also co-vibe-coded a book, called Vibe Coding, describing and recommending exactly the sort of system he's trying to build as Gas Town.
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
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.
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
He was right about Google in [1] when I was still drinking the Kool-Aid, in big and tangible ways that aren't discussed publicly.
[2] is 100% accurate, Grok was the backbone / glue of Google's internal developer tools.
I don't disagree on the current situation, and I'm uncomfortable sticking my neck out on this because I'm basically saying "the guy who kinda seems out of it, totally wasn't out of it, when you think he was", but [1] and [2] definitely aren't grandiose, the claims he makes re: Google and his work there are accurate. A small piece of why I feel comfortable in this, is that both of these were public blogs his employer was 100% happy about when hiring him to top positions.
I should be specific. I think the technical analysis is reasonable and I actually enjoy someone staking on a big vision, which is why I saved these pieces.
An example:
"I’ve seen Grab’s hunger. I’ve felt it. I have it. This space is win or die. They will fight to the death, and I am with them. This company, with some 3000 employees I think, is more unified than I’ve seen with most 5-person companies. This is the kind of focused camaraderie, cooperation and discipline that you typically only see in the military, in times of war.
Which should hardly surprise you, because that’s exactly what this is. This is war.
I am giving everything I’ve got to help Grab win. I am all in. You’d be amazed at what you can accomplish when you’re all in."
This is the writing of someone planning to make a capstone career move instead of leaving in 18 months. It's not the worst thing to do (He says he left b/c the time difference to support a team in SE Asia was hard physically, and he's getting older) and I support taking big swings. I'm just saying Yegge's writing has a pattern.
Crypto and what Yegge is doing with $GAS is dangerous because if the token price crashes and people betting their life savings think he didn't deliver on his promises... I like Steve personally which is why I'm saying anything.
2 replies →
The Gas Town post reads like some type of manic psychosis. I hope he snaps out of it and gets help.
Please don't do internet psychiatric diagnosis on HN. I know that often the intention is good, but it leads to bad places.
https://hn.algolia.com/?sort=byDate&type=comment&dateRange=a...
(and I realize the GP was the place the line started getting crossed)
1 reply →
[dead]
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. YMMV
Did 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...