Hacker News Reader

Comment by SwellJoe | Hacker News Reader

Based on my understanding of Gas Town, Beads, and Yegge's philosophy on AI that he's expressed in a variety of media, everything about the whole stack is designed to burn tokens. If you're not burning tokens, real fast, 24/7, you're losing the race. The race to where, I have no idea. Apparently, that includes him burning your tokens, too.

View on HN

I just had to post this somewhere in this thread, but I bought his Vibe Coding book after listening to him talk through it. I figured it would help me understand his approach and therefore help me get into the same mindset for vibe coding on a serious level. It was garbage. The book is largely written and edited by LLMs and it shows on every page. It was a slop how-to book without many useful gems on how to go about vibe coding outside of "just do it".

> help me get into the same mindset for vibe coding on a serious level

> vibe coding on a serious level

I hope your experience with the book has taught you a valuable lesson about "vibe coding", it seems like it was unintentionally very accurate.

I have historically liked Yegge's writing, and he's been pretty tuned into what's happening in tech...he rightly predicted JavaScript would take over the world (many people predicted it, as well, including me, but it wasn't obviously true to everyone for another year or two after that prediction was made). I don't think I ever really deeply disagreed with something so much as I disagree with him on AI.

I mean, it's inarguable that our industry has changed dramatically and most code going forward will be written by LLMs. But, I don't think it follows that you can produce quality software without a human in the loop. And, I don't think it follows that burning tokens 24/7 by way of creating unending busy work for agents is going to result in utility. I haven't actually tried Gas Town (it's too ridiculous on its face for me to be willing to invest time in learning it), but I'd still wager that a single competent dev sitting in front of Claude Code can produce better software faster than anyone, experienced or otherwise, trying to get Gas Town's infinite monkeys driving in the same direction.

I think his writing is a mix of word salad and eloquent bs.

It didn’t used to be. Back in the mid 2000s I basically designed our company’s tech interview process based on a few articles he’d written about how he was doing the same at Amazon. He was a must follow for me back in the salad days of RSS. When I saw the Gastown announcement I had trouble reconciling the author and the writing.

And even still, it’s hard to ignore him because he’ll still have some insight like “token efficiency is going to be the big thing we care about in the future,” which was a small section of one of his Gastown blogs. And after you’re done asking yourself if that means Gastown is performance art, or he just said that as a hedge against his “vomit tokens” approach so that he could say “look I knew it all along” when this is all proven to be misguided, you’ll start to mull on just the concept of “token efficiency” and realize “someone who can do work in 1/10th the tokens will be king.” I mean hell, Gastown preceded real support for multiagent orchestration in Claude and potentially nudged it along that path.

Yeah, it's just depressing because one of the links in here took me to his Twitter (my mistake) and I was just like, "Oh, got it, life event (maybe a divorce, maybe just aging) turned you toxic and now you're lost in the wilderness. +/- 6 months until he is claiming ketamine solved/ broke him.

(It's nice to have the superpower to judge people on social media posts, I know. It's a gift, I try not to use it for evil.)

It certainly is now, but it's also seemingly all written by LLMs now, as well. He wasn't always like this, though he has always been prone to exaggeration and simplification. He had a lot of solid insights, though, and I enjoyed reading him. Things change.

His Vibe Coding book is invaluable as a textbook example of slop.

Did you end up finding a reference you liked better? I'm default suspicious of anything called "vibe coding" but there are probably some good lessons in that territory.

My take at this point is that everything is still too fresh to really settle on some new paradigm for working. Yegge is clearly very passionate about this, and that's what got me to try his book. I just don't think he can really articulate some strategy to it yet.

To answer your question, no. I'm growing deeply suspicious of outright vibe coding as a practice. We still need to figure out the tools and process, so experimentation is pretty much where we're still at.

I have some practices that seem to be very effective but I wouldn't call them "vibe coding" and they're not really exciting enough to write a blog post about. Mostly: code is cheap, review labor is not, write down your process and make templates for all the documents in it (pretty much implementation plan, commit message), make sure the agent keeps a log of everything it's done and why (so it doesn't repeat work), periodically improve the process by instructing the agent to review your session transcripts and pull request comments for ways to make the process more reliable and efficient. The amount of tool churn in this world is pretty funny.

Edit: One concrete thing that the robo coding changes is it's totally reasonable to have the tools synthesize requirements based on a Slack thread, write a design doc, polish that, do a draft implementation, and then finally open a ticket to do the work with the benefit of having tested many of the assumptions.

The Venn diagram of crypto scam artistry and AI scam artistry is a circle

> I figured it would help me understand his approach

> It was a slop how-to book

So, it did.

Tokens are the new "lines of code". In the 80s managers believed that the more lines of code a programmer produced, the better (s)he is. Nowadays managers believe the more tokens a programmer burns, the better (s)he is.

The outcome will be similar.

Reply on news.ycombinator.com