Live data from Hacker News

Vibe Coding is not an excuse for low-quality work

addyo.substack.com

21–30 of 213 posts

Re: Vibe Coding is not an excuse for low-quality work

#21

What percentage of companies can hire an engineer who writes better code than o3?

Whatever percentage that can hire an engineer at all.

This won't be 100%, but that'll be the companies who're able to hire somebody to parse the problems that arise. Without that engineer, they'll be doing what OP calls 'vibe coding', meaning they'll neither understand nor be able to fix when the whole thing blows up.

Re: Vibe Coding is not an excuse for low-quality work

#22

Different people clearly mean different things when they talk about software quality. There is quality as perceived by the user: few bugs, accurately models the problem they have, no more complicated than necessary, etc. Then there is this other notion of quality as something to do with how the software is built. How neat and clear it is. How easy it is to extend or change. The first kind of quality is the only kind…

> The first kind of quality is the only kind that matters in the end.

How easy it is to maintain and extend does absolutely matter, in a world where software is constantly growing and evolving and never "finished"

Re: Vibe Coding is not an excuse for low-quality work

#23
post #5

So what have we redefined vibe coding to mean exactly? The original tweet[1] talked very specifically about not caring about quality, just accepting whatever code the AI produces blindly, as long as you get the black box output you're looking for, and just randomly try again if you didn't. Are people now using this term to mean "giving an AI agent broad tasks"? [1] https://x.com/karpathy/status/1886192184808149383?la…

From that tweet: > I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it That sums up vibe coding, imo. The article talks about code quality with vibe coding, but I think that misses the point. The real problem is code knowledge. When a vibe coder inevitably needs to debug something, if they have no idea what any of the code does, or why it is the w…

Like you, I’m far too risk averse to not fact check everything an LLM outputs, but I’ve also fixed bugs that have been present for 5+ years. Maybe at a certain point you can just wait for the next generation of model to fix the bugs. And wait for the generation after that to fix the newly introduced and/or more subtle bugs.

Re: Vibe Coding is not an excuse for low-quality work

#24
post #5

So what have we redefined vibe coding to mean exactly? The original tweet[1] talked very specifically about not caring about quality, just accepting whatever code the AI produces blindly, as long as you get the black box output you're looking for, and just randomly try again if you didn't. Are people now using this term to mean "giving an AI agent broad tasks"? [1] https://x.com/karpathy/status/1886192184808149383?la…

From that tweet: > I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it That sums up vibe coding, imo. The article talks about code quality with vibe coding, but I think that misses the point. The real problem is code knowledge. When a vibe coder inevitably needs to debug something, if they have no idea what any of the code does, or why it is the w…

Also from the tweet;

> It's not too bad for throwaway weekend projects, but still quite amusing

You were never supposed to vibe code on serious projects.

Re: Vibe Coding is not an excuse for low-quality work

#26

Different people clearly mean different things when they talk about software quality. There is quality as perceived by the user: few bugs, accurately models the problem they have, no more complicated than necessary, etc. Then there is this other notion of quality as something to do with how the software is built. How neat and clear it is. How easy it is to extend or change. The first kind of quality is the only kind…

The problem is that the first kind of quality is something that's hard for even human programmers to do well, while AI is, like the rest of the tools that came before, much better at the second.

Re: Vibe Coding is not an excuse for low-quality work

#27
post #18

This all reminds me a lot of the early 2000's, when big corporations thought they could save a lot of money by outsourcing development work to low-income countries and have their expensive in-house engineers only write specifications. Turns out most of those outsourcing parties won't truly understand the core ideas behind the system you're trying to build, won't think outside the box and make corrections where necess…

Deleted

Re: Vibe Coding is not an excuse for low-quality work

#28
post #5

So what have we redefined vibe coding to mean exactly? The original tweet[1] talked very specifically about not caring about quality, just accepting whatever code the AI produces blindly, as long as you get the black box output you're looking for, and just randomly try again if you didn't. Are people now using this term to mean "giving an AI agent broad tasks"? [1] https://x.com/karpathy/status/1886192184808149383?la…

It is a scam. Invented by someone who is an AI researcher, but not a software engineer which the latter rigorously focuses on code quality.

"Vibe-coding" as it is defined, throws away all the principles of software engineering and adopts an unchecked approach into using AI generated code with "accept all changes" then duct-taping it with more code on top of a chaotic code architecture or none (single massive file) and especially with zero tests.

The fact is, it encourages carelessness and ignores security principles just to make it acceptable to create low quality and broken software that can be hacked very easily.

You can spot some of these "vibe-coders" if they believe that they can destroy Docusign in a day with Cursor + Claude with their solution.

Who's going to tell them?

Re: Vibe Coding is not an excuse for low-quality work

#30
post #18

This all reminds me a lot of the early 2000's, when big corporations thought they could save a lot of money by outsourcing development work to low-income countries and have their expensive in-house engineers only write specifications. Turns out most of those outsourcing parties won't truly understand the core ideas behind the system you're trying to build, won't think outside the box and make corrections where necess…

Deleted

I don’t think this addresses the comment you’re replying to.
Post reply on HN