Live data from Hacker News

The cult of vibe coding is dogfooding run amok

bramcohen.com

511–520 of 555 posts

Re: The cult of vibe coding is dogfooding run amok

#511

Earlier quoted context omitted.

That's an interesting list. I think that the humans that will make the most progress in the next few years are the ones that push themselves up to the highest level of that list. Right now is a period of intense disruption and there are many coders that don't like the idea that their way of life is dead. There are still blacksmiths around today but for the most part it's made by factories and cheap 3rd world labor. I…

> I think the same is currently happening with coding, except it will allow single builders and designers to do the same thing as an entire team 5 years ago. This part of your post I think signals that you are either very new or haven't been paying attention; single developers were outperforming entire teams on the regular long before LLMs were a thing in software development, and they still are. This isn't because t…

> single developers were outperforming entire teams on the regular long before LLMs were a thing in software development

No they weren't, especially if you want the full vertical stack, ie. back-end, front-end, mobile and devops.

Re: The cult of vibe coding is dogfooding run amok

#512

Earlier quoted context omitted.

It's an unpopular truth for our industry, but the point of commercial software development is not to write good code; it's to write profitable code. There are some cases where the most profitable code is also good code. We like those. But in most (99%+) cases, the code is not going to survive contact with the market and so spending any time on making it good is wasted.

Yep this is especially true in the pre-product-market-fit phase. Most if not all of that code should be written to be thrown away. Any time you spend writing perfect code instead of your MVP is burnt runway and a chance for competitors to catch up. Once you show PMF though the balance changes to long-term sustainability and maintainability. What's going to be interesting is getting to a place where it generates bette…

> Any time you spend writing perfect code instead of your MVP is burnt runway

This. Once we crashed a product/company becaues of "we want it to be engineered perfectly" :-X

Re: The cult of vibe coding is dogfooding run amok

#513
post #238

Earlier quoted context omitted.

Betamax was arguably better. https://en.wikipedia.org/wiki/Videotape_format_war

It depends which definition of "better" you use. VHS won the adoption race, so it was better there. While Betamax may have been technologically superior, in hindsight we can say it apparently failed to address other key aspects of the technology adoption lifecycle.

Who cares? It couldn’t hold a movie on one tape. Thats what the market ended up selecting for. As soon as renting movies took off Beta lost.

When they compromised quality to get there, they were just more expensive.

And later S-VHS improved quality anyway.

Re: The cult of vibe coding is dogfooding run amok

#514

It’s truly strange that people keep citing the quality of Claude code’s leaked source as if it’s proof vibe coding doesn’t work. If anything, it’s the exact opposite. It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.

It's funny how so many of us took this unironically at first. I stopped using Claude Code a few weeks ago, and realized why I am still glad to use https://pi.dev . I don't miss any of the mess. Bring back Opus 4.5 I would say

I guess I meant pre-4.5. Claude Code peaked at or before November 2025 IMHO.

Re: The cult of vibe coding is dogfooding run amok

#515
post #139
post #57

In my opinion there are two main groups on the spectrum of "vibe coding". The non technical users that love it but don't understand software engineering enough to know what it takes to make a production grade product. The opposite are the AI haters that used chatgpt 3.5 and decided LLM code is garbage. Both of these camps are the loudest voices on the internet, but there is a quiet but extremely productive camp somew…

> extremely productive camp somewhere in the middle How do you quantify and measure this productivity gain?

I agree with the other comment that measuring productivity is pointless, as there has never been a good way to do this.

But the closest answer I can give you (without detailed examples of work projects) is I can prototype things faster than my team of 5 devs + 1 BA + 1 Manager before AI / Covid. The speed isn't just the faster code generation, but a fundamental paradigm shift from the commonly accepted project management philosophies. Agile and scrum are (in my experience) meant to protect developers from "wasted work" or "throwaway code" and also placate this non technical stakeholder fantasy that they know the best about product and can micromanage their way into a predictable timeline.

I have effectively been working as a team of 1 and I have been able to prototype things in days or weeks that would of taken months before. 95% of the code generated by claude is throwaway but the goal is to discover the real requirements faster. In the old model every step and possible risk needs to survive 3 meetings. If the story points are arbitrarily high then we have to split the tasks into more tasks.

Ironically, the obsession of quantifying productivity is what killed the productivity. People that live through spreadsheets would rather have 10 units of measurable productivity vs 50 units of unmeasurable productivity.

Re: The cult of vibe coding is dogfooding run amok

#516

It’s truly strange that people keep citing the quality of Claude code’s leaked source as if it’s proof vibe coding doesn’t work. If anything, it’s the exact opposite. It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.

Claude Code allows subsidized access to Anthropic's models! The product quality doesn't really matter, which is an argument FOR vibe coding sure, but only in cases where software quality does not matter.

You cannot extrapolate from Claude Code that software quality does not matter in all cases.

Re: The cult of vibe coding is dogfooding run amok

#517
post #470

Earlier quoted context omitted.

To my believe there was not a goal to write good code. The goal was maintainability and to keep it simple, so that people understand. People come and go, you constantly get to see foreign code and you have to do something with it. Anyways, i see the maintainability hell coming onto us. I still wonder how i organize this with AI. I definitly do not want to touch it what is written by AI.

I think the industry-wide hope is that AI manages the AI-written code, but it’s unclear whether that’s actually going to work out in practice. Right now, my experience is that is dicey. I’ve had AI mess up a codebase to the point where I threw it away and restarted. Maybe I was doing it wrong, though, in that I was looking at the code and was increasingly horrified by the slop. I get the feeling that in this new worl…

IME AI-native engineering requires a lot of infrastructure to make it viable. Teams who are just opening up cursor and putting it on "auto" and trying to one shot features may get stuff that works but is indeed slop.

Since the beginning of the year, I've been spearheading a low-stakes AI-native project (an internal tool). No one's written a single line of code. And we've learned so much from this experience. The first rule was our product manager, who is technical but isn't typically in the weeds, needs to be able to one-shot prompts with cursor auto. And so many rules stem from there, from e2e tests to ensure he doesn't break stuff, to custom linters to ensure that code lives in the right place, to architectural spec sheets so the LLM doesn't try to do raw DB queries from the client.

We're still not there, but we're getting closer and learning and improving every day.

I think the folks who are vibe coding a lot either aren't working in a team, or they are omitting the fact that they have spent a long time building harnesses to ensure the LLM doesn't run amok.

And I think the people who hate vibe coding are likely just asking Claude Code to do X without using Skills that have opinionated ways to do X.

All that said, I don't think we should ignore how the sausage is made at all. Part of what makes me able to move quickly in this project is knowing where stuff lives. I may not understand the line-by-line code, but if I know where to look to find out why I'm missing data that's in the DB, I can move a lot faster than if I have no idea what's going on in the codebase. Then when I find the problematic file or function, I can ask the LLM why it's like X and tell it it should be like Y.

Re: The cult of vibe coding is dogfooding run amok

#518
Wrote this as a reply to another comment, then realized it probably makes more sense as a top-level comment, so reposting here.

IME AI-native engineering requires a lot of infrastructure to make it viable. Teams who are just opening up cursor and putting it on "auto" and trying to one shot features may get stuff that works but is indeed slop.

Since the beginning of the year, I've been spearheading a low-stakes AI-native project (an internal tool). No one's written a single line of code. And we've learned so much from this experience. The first rule was our product manager, who is technical but isn't typically in the weeds, needs to be able to one-shot prompts with cursor auto. And so many rules stem from there, from e2e tests to ensure he doesn't break stuff, to custom linters to ensure that code lives in the right place, to architectural spec sheets so the LLM doesn't try to do raw DB queries from the client.

We're still not there, but we're getting closer and learning and improving every day.

I think the folks who are vibe coding a lot either aren't working in a team, or they are omitting the fact that they have spent a long time building harnesses to ensure the LLM doesn't run amok.

And I think the people who hate vibe coding are likely just asking Claude Code to do X without using Skills that have opinionated ways to do X.

All that said, I don't think we should ignore how the sausage is made at all. Part of what makes me able to move quickly in this project is knowing where stuff lives. I may not understand the line-by-line code, but if I know where to look to find out why I'm missing data that's in the DB, I can move a lot faster than if I have no idea what's going on in the codebase. Then when I find the problematic file or function, I can ask the LLM why it's like X and tell it it should be like Y.

Re: The cult of vibe coding is dogfooding run amok

#519

Earlier quoted context omitted.

^ This is a troll; new account, troll username.

Not a troll. I’ve been doing a lot of self reflection on this topic lately. Some people seem to enjoy software for the act & craft, where the outcome / artifact is secondary or irrelevant. I don’t. Some people enjoy the artifacts it produces, for their utility or economic value. Not really me either. Often people frame it as this dichotomy, but I’ve realized my enjoyment and self-fulfillment comes from creating an ar…

This is all valid. Your original comment came across as a troll because it implied that nobody could ever feel good about stuff they built with AI. Asserting that you know more about the emotional state of strangers on the internet than they know themselves is arrogant.

Re: The cult of vibe coding is dogfooding run amok

#520
post #491

Earlier quoted context omitted.

You're right that it's a spectrum. Just like anything else, you can be 'mostly' vibe coding or 'somewhat' vibe coding. But the threshold where it stops being vibe coding isn't entirely subjective. If you are trusting the AI's logic and primarily verifying the output (the app runs, the button works), you are vibe coding. If you are reading the diffs, verifying the architecture, you are transitioning back toward engine…

You say the threshold is not entirely subjective, but then you describe a subjective (you just know it) and ambiguous (transitioning back toward engineering) threshold. Sure seems to me like it's subjective. Also, I've nedlver ever heard so much talk about "verifying architecture" as when people talk about vibe coding. That's not something you usually do. The architecture is the overall structure of a design, and has…

Hm you could do like five degrees of vibecoding. Level one. You laboriously still look at the code and the diffs being generated. Level two: You sometimes look at the code being generated. You have a feel for how the classes are architected together but don't know the details. Level 4. You're aware of the classes and files in use, but beyond that, you have no idea what's going on.

Level 5. You just spit stuff at the LLM and have it shit out code that you have zero clue what it's doing. You don't even know if you're using react or not!

Post reply on HN