Live data from Hacker News

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

maggieappleton.com

331–340 of 466 posts

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

#331
Very interesting to read people’s belief in English as an unambiguous and testable language.

One comment claims it’s not necessary to read code when there is documentation (generated by an LLM)

Language varies with geography and with time. British, Americans, and Canadians speak “similar” English, but not identical.

And read a book from 70-80 years ago to see that many words appear to be used for their “secondary meaning.” Of course, what we consider their secondary meaning today was the primary meaning back then.

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

#332

Earlier quoted context omitted.

I write JS, and I have never directly observed the IRs or assembly code that my code becomes. Yet I certainly assume that the compiler author has looked at the compiled output in the process of writing a compiler! For me the difference is prognosis. Gas Town has no ratchet of quality: its fate was written on the wall since the day Steve decided he didn't want to know what the code says: it will grow to a moderate but…

or he will find a way to get the AI to create harnesses so it becomes stable. The lack of imagination and willingness to experiment in the HN crowd is AMAZING me and worrying me at the same time. Never thought a group of engineers would be the most conservative and close minded people I could discuss with.

There's a difference between "imagination and willingness to experiment" and "blind faith and gullibility".

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

#333

Lots of comments about Gas Town (which I get, it's hard not to talk about it!), but I thought this was a pretty good article -- nice job of summing up various questions and suggesting ways to think about them. I like this bit in particular: > A more conservative, easier to consider, debate is: how close should the code be in agentic software development tools? How easy should it be to access? How often do we expect d…

> Buried in the chaos are sketches of future agent orchestration patterns

I'm not sure if there are that many. We need to be vigilant of "it feels useful & powerful", because it's so easy to feel that way.

When I write complex plans, I can tell Claude to spawn agents for each task and I can successfully 1-shot a 30-60 minute implementation.

I've toyed with more complicated patterns, but unlike this speculative fiction, I did need my result both simple and working.

A couple of times now I've had to spend a lot of hours trying to unfuck a design i let slip through. The kind where 1 agent injects some duplicate code/architecture pattern into the system that's correct enough not to be flagged, but wrong enough to forever trip up every subsequent fresh agents that stumble on it.

I tell people my job now is to kick these things every 15 minutes. Its a kinda joke kinda not. But they definitely need kicking. Without, the decoherence of a non-trivial project is too high, and you still need time to know; where and how to kick.

I'm not sure what I'd need to be convinced a higher level of orchestration can do that. I do like to try new things. But my spider-sense is telling me this is a Collatz-conjecture-esque dead-end. People get the feeling of making giant leaps of progress, which anybody using these things should be familiar with by now, but something valuable is always just out of reach with the tools we currently have.

There are some big gains by guiding agents/users to use more sub agents with a clean context - perhaps with some more knobs - but I'd advise against acting under the assumption using grander orchestration tools will inevitably have a positive ROI.

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

#335
post #157

Earlier quoted context omitted.

It lets 0.05X developers be 0.2X developers and 1X developers be 0.9-1.1X developers. The problem is some 0.05X developers thought they were 0.5X and now they think they're 2X.

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.

I mean, not all workplaces hire the best.

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

#336

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…

> If you read Steve's writeup, it's clear that this is a big fun experiment: So, Steve has the big scary "YOU WILL DIE" statements in there, but he also has this: > I went ahead and built what’s next. First I predicted it, back in March, in Revenge of the Junior Developer. I predicted someone would lash the Claude Code camels together into chariots, and that is exactly what I’ve done with Gas Town. I’ve tamed them to…

> "What's next"? Not an experiment.

I think what’s next after an experiment very often is another experiment, especially when you’re doing this kind of exploratory R&D.

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

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

I mean, that fits with what I said.

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

#338

Earlier quoted context omitted.

> If you read Steve's writeup, it's clear that this is a big fun experiment: So, Steve has the big scary "YOU WILL DIE" statements in there, but he also has this: > I went ahead and built what’s next. First I predicted it, back in March, in Revenge of the Junior Developer. I predicted someone would lash the Claude Code camels together into chariots, and that is exactly what I’ve done with Gas Town. I’ve tamed them to…

These are some very tortured interpretations you're making. - "what's next" does not mean "production quality" and is in no way mutually exclusive with "experimental". It means exactly what it says, which is that what comes next in the evolution of LLM-based coding is orchestration of numerous agents. It does not somehow mean that his orchestrator writes production-grade code and I don't really understand why one wou…

> Don't believe me? Copy-paste his post into any LLM and ask it whether the post is contradictory or whether it's ambiguous whether this is production-grade software or not.

Bleak

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

#339
There is nothing professional, analytical or scientific about Gas Town at all.

He is just making up a fantasy world where his elves run in specific patterns to please him.

There is no metrics or statistics on code quality, bugs produced, feature requirements met.. or anything.

Just a gigantic wank session really.

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

#340
First time I'm seeing this on HN. Maybe it was posted earlier.

Have been doing manual orchestration where I write a big spec which contains phases (each done by an agent) and instructions for the top level agent on how to interact with the sub agent. Works well but it's hard utilize effectively. No doubt this is the future. This approach is bottlenecked by limitations of the CC client; mainly that I cannot see inter-agent interactions fully, only the tool calls. Using a hacked client or compatible reimplementation of CC may be the answer. Unless the API was priced attractively, or other models could do the work. Gemini 3 may be able to handle it better than Opus 4.5. The Gemini 3 pricing model is complex to say the least though (really).

Post reply on HN