Welcome to Gas Town

I've tried most of the agentic "let it rip" tools. Quickly I realized that GPT 5~ was significantly better at reasoning and more exhaustive than Claude Code (Opus, RL finetuned for Claude Code).

"What if Opus wrote the code, and GPT 5~ reviewed it?" I started evaluating this question, and started to get higher quality results and better control of complexity.

I could also trust this process to a greater degree than my previous process of trying to drive Opus, look at the code myself, try and drive Opus again, etc. Codex was catching bugs I would not catch with the same amount of time, including bugs in hard math, etc -- so I started having a great degree of trust in its reasoning capabilities.

I've codified this workflow into a plugin which I've started developing recently: https://github.com/evil-mind-evil-sword/idle

It's a Claude Code plugin -- it combines the "don't let Claude stop until condition" (Stop hook) with a few CLI tools to induce (what the article calls) review gates: Claude will work indefinitely until the reviewer is satisfied.

In this case, the reviewer is a fresh Opus subagent which can invoke and discuss with Codex and Gemini.

One perspective I have which relates to this article is that the thing one wants to optimize for is minimizing the error per unit of work. If you have a dynamic programming style orchestration pattern for agents, you want the thing that solves the small unit of work (a task) to have as low error as possible, or else I suspect the error compounds quickly with these stochastic systems.

I'm trying this stuff for fairly advanced work (in a PhD), so I'm dogfooding ideas (like the ones presented in this article) in complex settings. I think there is still a lot of room to learn here.

in 3-5years, sure, just like we are all currently using crypto to pay for groceries and smart contracts for all legal matters.

I think this read is generous:

> something like gas town is clearly not attempting to be a production grade tool.

Compare to the first two sentences:

> Gas Town is a new take on the IDE for 2026. Gas Town helps you with the tedium of running lots of Claude Code instances. Stuff gets lost, it’s hard to track who’s doing what, etc. Gas Town helps with all that yak shaving, and lets you focus on what your Claude Codes are working on.

Compared to your read, my read is confused: is it or is it not intending to be a useful tool (we can debate "production" quality, here I'm just thinking something I'd actually use meaningfully -- like Claude Code)?

I think the author wants us to take this post seriously, so I'm taking it seriously, and my critique in the original post was a serious reaction.

I’m luckily in a situation where I can afford to explore this stuff without the concerns that come from using it within an organization (and those concerns are 100% valid and haven’t been solved yet, especially not by this blog post)

I tried using beads. There kept being merge conflicts and the agent just kept one or the other changes instead of merging it intelligently, killing any work I did on making tasks or resolving others. Still haven't seen how beads solves this problem... and it's also an unnecessary one. This should be a separate piece of it that doesn't rely on agent not funging up the merge.

excellent summary, thanks

Why can't you use an issue tracker that is built into the git control, like forgejo? It feels like it would be easy to use this with an API key, out or direct database access (I'm doing both with agents). If you self host, you've got a very standard and reliable issue tracker. Why does beads need to exist? What can't an agent do with that setup I've described above?

Look at cc-mirror, and use the mclaude there.

It unlocks a (still) hidden multiagent orchestration function in Claude code. The person making it unminified the code and figured out how to unlock it.

I find it quite well done - I started a orchestrator project a few days ago and scrapped it because it'll be fully integrated soon it seems.

Looks interesting. Might want to link to Linear in the README; I hadn't heard of it before.

What do you like about Linear? Is it suitable for hobby projects?

The problem is that it leads to endless confusion that ends up taking over threads. We tried it!

Status quo sucks also, it just sucks less. Haven't yet figured out an actually good solution. Sorry!

Agreed, although perhaps not as strongly; I remember seeing these comments from a few days ago, so I was feeling a little gaslit seeing the new timestamps and wondered if I'd hallucinated the original thread.

I meant the latter, but both!

Re artificial uplifting a.k.a. re-upping, see https://news.ycombinator.com/item?id=26998308 and https://news.ycombinator.com/pool

This makes even more sense, it definitely feels like a logical step with beads. I use Beads a lot, its one of the few things I use with Claude Code.

I use Zed (this is completely optional since claude code can work 100% stand alone), Claude Code (I have Max) and Beads. I also take advantage of the .claude/instructions.md file and let Claude know to ALWAYS use Beads, and to use rg instead of "grep" which is kind of slow (if anyone from Anthropic is reading this, for the love of GOD use ripgrep instead of grep), a small summary about the project, and some ground rules. If there's key tickets that matter for the project I tell it to note them in the instructions. The instructions files the first thing Claude reads when you first open up a chat window with it, if you make amendments ask it to reread the file.

Outside of that its trial and error, but I've learned you don't need to kick off a new chat instance very much if at all. I also like Beads because if I have to "run" or go offline I can tell it to pause and log where it left off / where its at.

For some projects I tell claude not to close tickets without my direct approval because sometimes it closes them without testing, my baseline across all projects is that it compiles and runs without major errors.

My keyboard doesn't randomly input "banana" when I type "apple". If it did, it would be considered extremely defective.

Keyboards are highly deterministic. And when they're not, e.g. due to physical wear or software glitches, this makes them basically unusable for touch typists.

Yes, definitely. I spent about half that time poking around, understanding the setup, doing some bug fixing and put in a PR for gas town itself, although I used Claude Code separately for making the PR.

I pointed it at a Postgres time series project I was working on, and it deployed a much better UI and (with some nudging) fixed docker errors on a remote server, which involved logging in to the server to check logs. It probably opened and fixed 50 or so beads in total.

I'd reach for it first to do something complicated ("convoy" or epic) over Claude Code even as is -- like, e.g. "copy this data ingestion we do for site x, and implement it for sites y,z,,a,b,c,d. start with a formal architecture that respects our current one and remains extensible for all these sites" is something I think it would do a fair job at.

As to cost - I did not run out of my claude pro max subscription poking around with it. It infers ... a lot ... though. I pulled together a PR that would let you point some or all of the agent types at local or other endpoints, but it's a little early, I think for the codebase. I'd definitely reach for some cheaper and/or faster inference for some of the use cases.

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...

I am interested in this as well. From the article:

```Gas Town is also expensive as hell. You won’t like Gas Town if you ever have to think, even for a moment, about where money comes from. I had to get my second Claude Code account, finally; they don’t let you siphon unlimited dollars from a single account, so you need multiple emails and siphons, it’s all very silly. My calculations show that now that Gas Town has finally achieved liftoff, I will need a third Claude Code account by the end of next week. It is a cash guzzler.'''

Since I am quite capable of shitting my own code up for free, and I've got zero interest in this stupid AI shit anyway, I'm vanishingly unlikely to actually use this. But, still: I like to keep half an eye on what is going on, even if I hate it. And I am more than somewhat intrigued about what the numbers actually look like.

I don't know if I'm understanding you correctly, but my experience reflects what (I think) you're saying. Given a fully formed older project and a clean set of feature requests, Claude can be a beast. On the other hand, steering it through a greenfield project feels more labor intensive than writing the code myself.

I'm a full stack dev, and solo, so I write data schema, backends and frontends at the same time, usually flipping between them to test parts of new features. As far as AI use, I'm really just at the level of using a single Claude agent in an IDE - and only occasionally, because it writes a lot of nonsense. So maybe I'm missing out on the benefits of multiple agents. But where I currently see value in it is in writing (1) boilerplate and (b) sugar - where it has full access to a large and stable codebase. Where I think it fails is in writing overarching logical structures, especially early on in a project. It isn't good at writing elegant code with a clear view of how data, back and front should work together. When I've tried to start projects from scratch with Claude, it feels like I'm fighting against its micro-view of each piece of code, where it's unable to gain a macro-view of how to orchestrate the whole system.

So like, maybe a bottomless wallet and a dozen agents would help with that, but there isn't so much room for errors or bugs in my work code as there is in my fun/play/casual game code. As a result I'm not really seeing that much value in it for paid work.

> We’re still living in the heavily-corporate-subsidized AI world

There's little evidence this is true. Even OpenAI who is spending more than anyone is only losing money because of the free version of ChatGPT. Anthropic says they will be profitable next year.

> Plus, and maybe it’s just my personal cynicism showing, but when did tech ever reduce pricing while maintaining quality on a provided service in the long run? In an industry laser focused on profit, I just don’t see how something so many believe to be a revolutionary force in the market will be given away for less than it is today.

Really?

I mean I guess I'm showing my age but the idea I can get a VM for a couple of dollars a month and expect it to be reliable make me love the world I live in. But I guess when I started working there was no cloud and to get root on a server meant investing thousands of dollars.

There are already providers that are comically cheap at the moment. Minimax/M2.1 for example is good-enough for many things and 15min long sessions still cost something like 2c. Another version or two and Claude is likely going to start feeling the pressure (or minimax will raise the prices - we'll see)

This seems too pessimistic? Moore's law is a thing. Price reductions with better quality have been going on for a long time in computing and networking.

We're also seeing significant price reductions every year for LLM's. Not for frontier models, but you can get the equivalent of last year's model for cheaper. Hard to tell from the outside, but I don't think it's all subsidized?

I think maybe people over-updated on Bitcoin mining. Most tech is not inherently expensive.

> but when did tech ever reduce pricing while maintaining quality on a provided service in the long run

That's an old world that we experienced in 2000s, and maybe in early 2010s, where we cared about the quality on a provided service in the long run. For anything web-app-general-stuff related, that's long gone, as everyone (reads: mostly everyone) has very short attention span, and what is needed is "if the thing i desire can be done right now". In long run? Who cares. I keep seeing this in every day life, at work, discussions with my previous clients and etc.

Once again, I wish it wasn't true, but nothing is pointing that it's not true.

I wonder if this needs frontier models?

Or, if it does _now_, how long it'll be before it' will work well using downloadable models that'll run on, say, a new car's worth of Mac Studios with a bunch of RAM in them to allow a small fleet of 70B and 120B models (or larger) to run locally? Perhaps even specialised models for each of the roles this uses?

Many of the billions being invested are for the power bill of training of new models. Not to mention the hardware needed to do so. Any hardware training a new model, isn't being used for inference.

If training of new models ceased, and hardware was just dedicated to inference, what would that do to prices and speed? It's not clear to me how much inference is actually being subsidized over the actual cost to run the hardware to do it. If there's good data on that I'd love to learn more though.

The thing about beginners (and I'm sure we can all relate to them from our past) is they won't really know which path is good or bad. In roguelike, when you make a mistake, you kinda know why you made a mistake and how you got there. For beginners, even if you have version control, you never developed that "sense of what feels right". Or "there HAS TO BE a simpler way of doing it, i just have to ask" sense. I have no idea how to describe it, but I think you might get what I mean?

Best comment in this thread. Bamboo is hell. Search the web about how to limit its spread. It's a war operation (trenches included)

I've been reading Steve for a long long time. He's had a lot of good ideas, issued some solid advice, but has always had a quirky sense of humor. A few pages into it I thought "this has to be a joke". But I couldn't find the punchline. This is the most depressing comment section I've read in a long time. I might have to enter the lottery to become an apprentice electrician.

This is not the same Steve Yegge that had an old "blog of rants", or is it?

I have nothing against automated code completion on steroids or agents. What I cannot condone is not reading and understanding the generated code. If you have not understood your agent generated code, you will be "surprised" for sure, sooner or later.

I’ve come to appreciate that there is a new totally valid (imo) kind of software development one can do now where you simply do not read the code at all. I do this when prototyping things with vibe coding for example for personal use, and I’ve posted at least one such project on GitHub for others who may want to run the code.

Of course as a developer you still have to take responsibility for your code, minimally including a disclaimer, and not dumping this code in to someone else’s code base. For example at work when submitting MRs I do generally read the code and keep MRs concise.

I’ve found that there is a certain kind of coder that hears of someone not reading the code and this sounds like some kind of moral violation to them. It’s not. It’s some weird new kind of coding where I’m more creating a detailed description of the functionality I want and incrementally refining it and iterating on it by describing in text how I want it to change. For example I use it to write GUI programs for Ubuntu using GTK and python. I’m not familiar with python-gtk library syntax or GTK GUI methods so there’s not really much of a point in reading the code - I ask the machine to write that precisely because I’m unfamiliar with it. When I need to verify things I have to come up with ways for the machine to test the code on its own.

Point is I think it’s honestly one new legitimate way of using these tools, with a lot of caveats around how such generated code can be responsibly used. If someone vibe coded something and didn’t read it and I’m worried it contains something dangerous, I can ask Claude to analyze it and then run it in a docker container. I treat the code the same way the author does - as a slightly unknown pile of functions which seem to perform a function but may need further verification.

I’m not sure what this means for the software world. On the face of it it seems like it’s probably some kind of problem, but I think at the same time we will find durable use cases for this new mode of interacting with code. Much the same as when compilers abstracted away the assembly code.

You are ignoring the obvious difference between errors introduced while translating one near-formal-intent-clear language to another as opposed to ambiguous-natural-language to code done through a non-deterministic intermediary. At some point in the future the non-deterministic intermediary will become stable enough (when temperature is low and model versions won't affect output much) but the ambiguity of the prompting language is still going to remain an issue. Hence, read before commit will always be a requirement I think. A good friend of mine wrote somewhere that at about 5 agents or so per project is when he is the bottleneck. I respect that assessment. Trust but verify. This way of getting faster output by removing that bottleneck altogether is, at least for me, not a good path forward.

Static analysis helps a lot. For example, I use jscpd [0] to solve the problem of AI duplicating code.

[0] https://github.com/kucherenko/jscpd

I have noticed in just the past two weeks or so, a lot of the naysayers have changed their tunes. I expect over the next 2 months there will be another sea change as the network effect and new frameworks kick in.

This is pretty much how I use LLMs as well. These interactions have convinced me that while the LLMs are very convincing with persuasive arguments, they are wrong often on things I am good at; so much so that I would have a hard time opening PRs for code edited by them without reading it carefully. Gell-man amnesia and all that seems appropriate here even though that anthropomorphizes LLMs to an uncomfortable extent. At some point in the future I can see them becoming very good at recognizing my intent and also reasoning correctly. Not there yet.

Compilers only obtained that level of trust through huge amounts of testing and deterministic execution. You don't look at compiler output because it's nearly always correct. People find compiler bugs horrifying for that reason.

LLMs are far from being as trustworthy as compilers.

If I use the same codebase and the same compiler version and the same compiler flags over and over again to produce a binary, I expect the binary to be the deterministically be the same machine code. I would not expect that from an LLM.

This assumes the regeneration is deterministic, or at least its output no worse than what it's replacing.