[HN Gopher] Welcome to Gas Town
___________________________________________________________________
Welcome to Gas Town
Author : gmays
Score : 129 points
Date : 2026-01-01 22:36 UTC (4 days ago)
(HTM) web link (steve-yegge.medium.com)
(TXT) w3m dump (steve-yegge.medium.com)
| mccoyb wrote:
| The article seems to be about fun, which I'm all for, and I
| highly appreciate the usage of MAKER as an evaluation task
| (finally, people are actually evaluating their theories on
| something quantitative) but the messaging here seems inherently
| contradictory:
|
| > Gas Town helps with all that yak shaving, and lets you focus on
| what your Claude Codes are working on.
|
| Then:
|
| > Working effectively in Gas Town involves committing to vibe
| coding. Work becomes fluid, an uncountable that you sling around
| freely, like slopping shiny fish into wooden barrels at the
| docks. Most work gets done; some work gets lost. Fish fall out of
| the barrel. Some escape back to sea, or get stepped on. More fish
| will come. The focus is throughput: creation and correction at
| the speed of thought.
|
| I see -- so where exactly is my focus supposed to sit?
|
| As someone who sits comfortably in the "Stage 8" category that
| this article defines, my concern has never been throughput, it
| has always been about retaining a high-degree of quality while
| organizing work so that, when context switching occurs, it
| transitions me to near-orthogonal tasks which are easy to
| remember so I can give high-quality feedback before switching
| again.
|
| For instance, I know Project A -- these are the concerns of
| Project A. I know Project B -- these are the concerns of Project
| B. I have the insight to design these projects so they compose,
| so I don't have to keep track of a hundred parallel issues in a
| mono Project C.
|
| On each of those projects, run a single agent -- with review
| gates for 2-3 independent agents (fresh context, different
| models! Codex and Gemini). Use a loop, let the agents go back and
| forth.
|
| This works and actually gets shit done. I'm not convinced that 20
| Claudes or massively parallel worktrees or whatever improves on
| quality, because, indeed, I always have to intervene at some
| point. The blocker for me is not throughput, it's me -- a human
| being -- my focus, and the random points of intervention which
| ... by definition ... occur stochastically (because agents).
|
| Finally:
|
| > Opus 4.5 can handle any reasonably sized task, so your job is
| to make tasks for it. That's it.
|
| This is laughably not true, for anyone who has used Opus 4.5 for
| non-trivial tasks. Claude Code _constantly_ gives up early,
| corrupts itself with self-bias, the list goes on and on. It 's
| getting better, but it's not that good.
| iamwil wrote:
| > For instance, I know Project A -- these are the concerns of
| Project A. I know Project B -- these are the concerns of
| Project B. I have the insight to design these projects so they
| compose, so I don't have to keep track of a hundred parallel
| issues in a mono Project C. On each of those projects, run a
| single agent -- with review gates for 2-3 independent agents
| (fresh context, different models! Codex and Gemini). Use a
| loop, let the agents go back and forth.
|
| Can you talk more about the structure of your workflow and how
| you evolved it to be that?
| mccoyb wrote:
| 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.
| mlady wrote:
| I'm sure we're just working with the same tools thinking
| through the same ideas. Just curious if you've seen my
| newsletter/channel @enterprisevibecode
| https://www.enterprisevibecode.com/p/let-it-rip
|
| It's cool to see others thinking the same thing!
| anthonypasq wrote:
| a response like this is confusing to me. what you are saying
| makes sense, but seems irrelevant. something like gas town is
| clearly not attempting to be a production grade tool. its an
| opinionated glimpse into the future. i think the astethic was
| fitting and intentional.
|
| this is the equivalent of some crazy inventor in the 19th
| century strapping a steam engine onto a unicycle and telling
| you that some day youll be able to go 100mph on a bike. He was
| right in the end, but no one is actually going to build
| something usable with current technology.
|
| Opus 4.5 isnt there. But will there be a model in 3-5 years
| thats smart enough, fast enough, and cheap enough for a refined
| vision of this to be possible? Im going to bet on yes to that
| question.
| leftbehinds wrote:
| in 3-5years, sure, just like we are all currently using
| crypto to pay for groceries and smart contracts for all legal
| matters.
| anthonypasq wrote:
| ... no one ever used crypto to buy things. most engineers
| are currently already using AI. such a dumb comparison that
| really just doesnt pass the sniff test.
| fragmede wrote:
| Their green username is leftbehinds. Let them hold their
| wrong opinions based on outdated information.
| wredcoll wrote:
| Boy this smells a lot like early days of blogging about block
| chains, specifically ethereum and friends.
|
| It's not that there's nothing useful, maybe even important, in
| there, it's just so far it's all just the easy parts: playing
| around inside a computer.
|
| I've noticed a certain trend over the years where you get certain
| types of projects that get lots of hype and excitement and much
| progress seems to be made, but when you dig deep enough you find
| out that it's all just the fun, easy sort of progress.
|
| The fun progress, which not at all coincidentallly tends to also
| be the easy progress, is the type that happens solely inside a
| computer.
|
| What do I mean by that? I mean programs who only operate at the
| level of artificial computer abstractions.
|
| The hard part is always dealing with "the real world": hardware
| that returns "impossible" results to your nicely abstract api
| functions, things that stop working in places they really
| shouldn't be able to, or even, and this is the really tricky bit,
| dealing with humans.
|
| Databases are a good example of this kind of thing. It's easy to
| start off a database writing all the clever (and fun) bits like
| btrees and hash maps and chained hashes that spill to disk to
| optimize certain types of tables and so on, but I'd wager that at
| least half of the code in a "real" database like sqlite or
| postgresql is devoted to dealing with strange hardware errors or
| leaky api abstractions across multiple platforms or the various
| ways a human can send nonsensical input into the system and
| really screw things up.
|
| I'd also bet that this type of code is a lot less fun to write
| and took much longer than the rest (which incidentally is why I
| always get annoyes when programming language demos show code with
| only a happy path, but that's another rant and this comment is
| already excessive).
|
| Anyways, this AI thing is definitely a gold rush and it's
| important to keep in mind that there was in fact a lot of gold
| that got dug up but, as everyone constantly repeats, the more
| consistent way to benefit is sell the shovels and this is very
| definitely an ad for a shovel.
| ForHackernews wrote:
| Naming your energy-guzzling "just throw more agents at it"
| thingamajig after a location in the post-apocalyptic Mad Max
| universe is certainly a choice.
| qcnguy wrote:
| This is clearly going to develop the same problem Beads has. I've
| used it. I'm in stage 7. Beads is a good idea with a bad
| implementation. It's not a designed product in the sense we are
| used to, it's more like a stream of consciousness converted
| directly into code. There are many features that overlap
| significantly, strange bugs, and the docs are also AI generated
| so have fun reading them. It's a program that isn't only vibe
| coded, it was vibe designed too.
|
| Gas Town is clearly the same thing multiplied by ten thousand.
| The number of overlapping and adhoc concepts in this design is
| overwhelming. Steve is ahead of his time but we aren't going to
| end up using this stuff. Instead a few of the core insights will
| get incorporated into other agents in a simpler but no less
| effective way.
|
| And anyway the big problem is accountability. The reason everyone
| makes a face when Steve preaches agent orchestration is that he
| must be in an unusual social situation. Gas Town sounds fun if
| you are accountable to nobody: not for code quality, design
| coherence or inferencing costs. The rest of us are accountable
| for at least the first two and even in corporate scenarios where
| there is a blank check for tokens, that can't last. So the
| bottleneck is going to be how fast humans can review code and
| agree to take responsibility for it. Meaning, if it's crap code
| with embarrassing bugs then that goes on your EOY perf review.
| Lots of parallel agents can't solve that fundamental bottleneck.
| ac29 wrote:
| >This is clearly going to develop the same problem Beads has.
| I've used it. I'm in stage 7. Beads is a good idea with a bad
| implementation. It's not a designed product in the sense we are
| used to, it's more like a stream of consciousness converted
| directly into code. There are many features that overlap
| significantly, strange bugs, and the docs are also AI generated
| so have fun reading them. It's a program that isn't only vibe
| coded, it was vibe designed too.
|
| Yeah this describes my feeling on beads too. I actually really
| like the idea - a lightweight task/issue tracker integrated
| with a coding agent does seem more useful than a pile of
| markdown todos/plans/etc. But it just doesnt work that well.
| Its really buggy and the bugs seem to confuse the agent since
| it was given instructions to do things a certain way that dont
| work consistently.
| laxori666 wrote:
| 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.
| NamlchakKhandro wrote:
| 100%.
|
| There's a lot of strange things going on in that project.
|
| try to add some common sense, and you'll get shouted out.
|
| which is fine, I'll just make my own version without the slop.
| haburka wrote:
| This is either a meme or the way everyone will code in 2 years,
| in both cases, it terrifies me.
| lifetimerubyist wrote:
| I was trying to be patient, hoping this entire thing would
| collapse sooner rather than later - but now I think I'm just
| going to start planning my exit from this industry forever.
| mccoyb wrote:
| There are no concepts in this blog post. It is the author's
| opinions in the form of a pseudo-Erlang program with
| probabilities. If one reads it like it is a program, you realize
| that the underlying core has been obfuscated by implementation
| details.
|
| I'm looking for "the Emacs" of whatever this is, and I haven't
| read a blog post which isolates the design yet.
| leftbehinds wrote:
| excellent summary, thanks
| nobodywillobsrv wrote:
| It's nice to see someone else going mad, even deeper down the
| well.
|
| I don't known the details but I was wondering why people aren't
| "just" writing chat venues any commns protocols for the chats? So
| the fundamental unit is a chat that humans and agents can be a
| member of.
|
| You can also have DMs etc to avoid chattiness.
|
| But fundmantally if you start with this kind of madness you don't
| have a strict hierarchy and it might also be fun to see how it
| goes.
|
| I briefly started building this but just spun out and am stuck
| using PAL MCP for now and some dumb scripts. Not super content
| with any of it yet.
| dang wrote:
| (We re-upped this post because it hadn't made the frontpage
| despite lots of upvotes - which happens sometimes.
|
| This explains why some of the comments have timestamps that
| appear older than the post itself. I got tired of trying to make
| them line up, sorry!)
| toast0 wrote:
| > I got tired of trying to make them line up, sorry!
|
| IMHO, it's less disorienting to have the post dated after the
| comments than it is to see a comment you thought you wrote a
| couple days ago but is dated today. So you're welcome to stop
| trying to line up timestamps.
| mhitza wrote:
| What happens sometimes, artifical uplifting of posts, posts
| with high vote count that don't reach the frontpage, or both?
| gneray wrote:
| > But first, before we get into Gas Town's operation, I need to
| get rid of you real quick.
|
| WARNING DANGER CAUTION GET THE F** OUT YOU WILL DIE
|
| I have never met Steve, but this warning alone is :chefskiss:
| giancarlostoro wrote:
| What's really amazing to me is this is how I've thought about
| building the same thing, by using beads... Glad someone in the
| hivemind did it.
| 22c wrote:
| > I've thought about building the same thing, by using beads...
| Glad someone in the hivemind did it.
|
| Gas Town is from the creator of beads.
| giancarlostoro wrote:
| 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.
| lifetimerubyist wrote:
| If babysitting 30 claude agents is the future of professional
| programming I want zero part of it.
___________________________________________________________________
(page generated 2026-01-05 23:00 UTC)