Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

maggieappleton.com

Post reply on HN
Print view View original

231–240 of 466 posts

Re: Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

#231

Post by lupire »

square_usual wrote: post #205
wrs wrote: post #81

Earlier quoted context omitted.

Perhaps it was his followup post about how people are lining up to throw millions of VC dollars at his bizarre whimsical fever dream that disturbs people? I’m all for arts funding, but…

Isn't the point that he refused them? VCs can be dumb (see the crypto hype, even the recent inflated AI raises) so I wouldn't put too much stock in what they think is valuable.

He participated in a crypto pump and dump

https://pivot-to-ai.com/2026/01/22/steve-yegges-gas-town-vib...

Re: Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

#232

Post by Barrin92 »

mediaman wrote: post #46

I don't get the widespread hatred of Gas Town. If you read Steve's writeup, it's clear that this is a big fun experiment. It pushes and crosses boundaries, it is a mixture of technology and art, it is provocative. It takes stochastic neural nets and mashes them together in bizarre ways to see if anything coherent comes out the other end. And the reaction is a bunch of Very Serious Engineers who cross their arms and h…

>it is a mixture of technology and art, it is provocative

There's no art (or engineering) in this and the only provocative thing about it is that Yegge apparently decided to turn it into a crypto scam. I like the intersection of engineering and art but I prefer if it includes both actual engineering and art, 100 rabbits (100r.co) is a good example of it, not a blog post with 15 AI generated images in it that advocates some unholy combination of gambling, vibe coding and cryptocurrency crap.

Re: Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

#233

Post by eikenberry »

radlad wrote: post #38
turtlebits wrote: post #18

Earlier quoted context omitted.

No one is promising anything. It's just a giant experiment and the author explicitly tells you not to use it. I appreciate those that try new things, even it it's possibly akin to throwing s** at a wall and seeing what sticks. Maybe it changes how we code or maybe it doesn't. Vibe coding has definitely helped me write throwaway tools that were useful.

After listening to Yegge's interview, I'm not sure this is accurate: https://www.youtube.com/watch?v=zuJyJP517Uw For example, he makes a comment to the effect that anyone using an IDE to look at code in 2026 is a "bad engineer."

Hyperbole is very common.

Re: Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

#234

Post by 3vidence »

bbayles wrote: post #8
suriya-ganesh wrote: post #7

>Yegge is leaning into the true definition of vibecoding with this project: “It is 100% vibecoded. I’ve never seen the code, and I never care to.” I don't get it. Even with a very good understanding of what type of work I am doing and a prebuilt knowledge of the code, even for very well specced problem. Claude code etc. just plain fail or use sloppy code. How do these industry figures claim they see no part of a 225K…

I'm sympathetic to this view, but I also wonder if this is the same thing that assembly language programmers said about compilers. What do you mean that you never look at the machine code? What if the compiler does something inefficient?

This analogy has always been bad any time someone has used it. Compilers directly transform via known algorithms.

Vibecoding is literally just random probabilistic mapping between unknown inputs and outputs on an unknown domain.

Feels like saying because I don't know how my engine works that my car could've just been vibe-engineered. People have put 1000s of hours into making certain tools work up to a give standard and spec reviewed by many many people.

"I don't know how something works" != "This wasn't thoughtfully designed"

Why do people compare these things.

Re: Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

#235

Post by kaydub »

joshstrange wrote: post #192
kaydub wrote: post #189

Earlier quoted context omitted.

I haven't seen your issue, but git is actually one of the things I don't have the llm do. When I work on issues I create a new branch off of master, let the llm go to town on it, then I manually commit and push to remote for an MR/PR. If there are any errors on the commit hooks I just feed the errors back into the agent.

Interesting, ok, I might try that on my next attempt. I was trying to have it commit so that I could use pre-commit hooks to enforce things I want (test, lint, prettier, etc) but maybe instead I should handle that myself and make it more explicit in my prompts/CLAUDE.md to test/lint/etc. In reality I should just create a `/prep` command or similar that asks it to do all of that so that once it thinks it's done, I can…

In my projects there's generally a "developer" way to do things and an "llm agent" way to do things.

For the llm a lot of linting and build/test tools go into simple scripts that the llm can run and get shorthand info out of. Some tools, if you have the llm run them, they're going to ingest a lot from the output (like a big stacktrace or something). I want to keep context clean so I have the llm create the tool to use for build/test/linting and I tell it to create it so the outputs will keep its context clean, then I have it document it in the .md file.

When working with the LLM I have to start out pretty explicit about using the tooling. As we work through things it will start to automatically run the tooling. Sometimes it will want to do something else, I just nudge it back to use the tooling (or I'll ask it why or if there are benefits to the other way and if there are we'll rebuild the tooling to use the other way).

Finally, if the LLM is really having trouble, I kill the session and start a new one. It used to feel bad to do that. I'd feel like I'm losing a lot of info that's in context. But now, I feel like it's not so bad... but I'm not sure if that's because the llms are better or if my workflow has adapted.

Now, let me backup a little bit. I mentioned that I don't have the llm use git. That's the control I maintain. And with that my workflow is: llm builds feature->llm runs linters/tests->I e2e test whatever I'm building by deploying to a dev/staging/local env->once verified I commit. Now I will continue that context window/session until I feel like the llm starts fucking up. Then I kill the session and start a new one. I rarely compact, but it does happen and I generally don't fret about it too much.

I try to keep my units of work small and I feel like it does the best when I do. But then I often find myself surprised at how much it can do from a single prompt, so idk. I do understand some of the skepticism because a lot of this stuff sounds "hand-wavy". I'm hoping we all start to hone in on some general more concrete patterns but with it being so non-deterministic I'm not sure if we will. It feels like everyone is using it differently and people are having successes and failures across different things. People where I work LOVE MCPs but I can't stand them. When I use them it always feels like I have to remind the llm that it has an MCP, then it feels like the MCP takes too much context window and sometimes the llm still trips over how to use it.

Re: Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

#236

Post by kaydub »

toraway wrote: post #213
joshstrange wrote: post #192

Earlier quoted context omitted.

Interesting, ok, I might try that on my next attempt. I was trying to have it commit so that I could use pre-commit hooks to enforce things I want (test, lint, prettier, etc) but maybe instead I should handle that myself and make it more explicit in my prompts/CLAUDE.md to test/lint/etc. In reality I should just create a `/prep` command or similar that asks it to do all of that so that once it thinks it's done, I can…

You’ll likely have the same issue relying on CLAUDE.md instructions to test/lint/etc, mine get ignored constantly to the point of uselessness. I’m trying to redesign my setup to use hooks now instead because poor adherence to rules files across all the agentic CLIs is exhausting to workaround. (and no, Opus 4.5 didn’t magically solve this problem to preemptively respond to that reply)

What do your rules files look like?

I wonder if some people are putting in too much into their markdown files of what NOT to do.

I hate people saying the llms are just better auto-correct, but in some ways they're right. I think putting in too much "don't do this" is leading the llm down the path to do "this" because you mentioned it at all. The LLM is probabilistically generating it's response based on what you've said and what's in the markdown files, the fact you put some of that stuff in there at all probably increases the probability those things will show up.

Re: Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

#238

Post by kaydub »

enraged_camel wrote: post #195
kaydub wrote: post #157

Earlier quoted context omitted.

Nah, our best devs/engineers use the tools the most. In my real life experience it's been the middling devs that always talk about "ai slop" and how the tools can't do their jobs.

On our team there's a very clear distinction between three groups: - those who have embraced AI and learned to use it well - those who have embraced AI but treat it as a silver bullet - those who reject AI First group is by far the most productive and adds the most value to the team.

Yeah, it's similar where I'm at.

If anything the silver bullet people are mostly managers and C levels... some of which don't even use the tools themselves.

Of the devs that rejected it at first, the ones with the same sentiment I'm seeing online in threads like these, we forced one to give it a try. He now treats totters between using it well and treating it as a silver bullet. I still hear him incredulous about the things claude does at meetings, "I had to do and I thought I'd let claude get a crack at it... did it in one shot"

Re: Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

#239

Post by joshstrange »

kaydub wrote: post #235
joshstrange wrote: post #192

Earlier quoted context omitted.

Interesting, ok, I might try that on my next attempt. I was trying to have it commit so that I could use pre-commit hooks to enforce things I want (test, lint, prettier, etc) but maybe instead I should handle that myself and make it more explicit in my prompts/CLAUDE.md to test/lint/etc. In reality I should just create a `/prep` command or similar that asks it to do all of that so that once it thinks it's done, I can…

In my projects there's generally a "developer" way to do things and an "llm agent" way to do things. For the llm a lot of linting and build/test tools go into simple scripts that the llm can run and get shorthand info out of. Some tools, if you have the llm run them, they're going to ingest a lot from the output (like a big stacktrace or something). I want to keep context clean so I have the llm create the tool to us…

Ok, that's a good tip about separate tools/scripts for the LLM, I did something similar less than a year ago so that I kept lint/test output to a minimum but it was still invoked via git hooks. I'll try again with scripts next time I'm doing this. My hope was to let the agent commit to a branch (with code that passed lint/test/prettier/etc), push it, auto-deploys to preview branches, and then that's where I'd do my e2e/QA and once I was happy I could merge it and it get deployed to the main site.

Re: Gas Town's agent patterns, design bottlenecks, and vibecoding at scale

#240

Post by juanre »

zingar wrote: post #184
juanre wrote: post #112

I have not tried Gas Town yet, but Steve's beads https://github.com/steveyegge/beads (used by Gas Town) has been a game-changer, on the order of what claude code was when it arrived.

Do you have any workflow tips or write up with beads?

My workflow tends to be very simple: start a session; ask the agent "what's next", which prompts it to check beads; and more often than not ask it to just pick up whichever bead "makes more sense".

In claude I have a code-reviewer agent, and I remind cc often to run the code reviewer before closing any bead. It works surprisingly well.

I used to monitor context and start afresh when it reached ~80%, but I stopped doing that. Compacting is not as disruptive as it used to be, and with beads agents don't lose track.

I spent some time trying to measure the productivity change due to beads, analysing cc and codex logs and linking them to deltas and commits in git [1]. But I did not fully believe the result (5x increase when using beads, there has to be some hidden variable) and I moved on to other things.

Part of the complexity is that these days I often work on two or three projects at the same time, so attribution is difficult.

[1] Analysis code is at https://github.com/juanre/agent-taylor

Post reply on HN