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

“Vibe Coding” vs. Reality

cendyne.dev

Post reply on HN
Print view View original

181–190 of 312 posts

Re: “Vibe Coding” vs. Reality

#181

Post by bobxmax »

nextts wrote: post #156
bobxmax wrote: post #128

Earlier quoted context omitted.

They were good... probably a bit bloated. Without AI we could probably be 5 devs. With AI we can do it all in 1-2.

Trying to get my head around this. It must mean 90% of what they were doing was writing code. Like not even thinking, architecture, gathering requirements, make sure you built the right thing etc. Just generating syntax.

In my experience it's usually a few devs doing the most of that, and the rest are largely banging out features, debugging, refactoring. There's also just a lot more efficiency when you shrink the team.

Re: “Vibe Coding” vs. Reality

#182

Post by DonHopkins »

k__ wrote: post #39

"Like the NFT crowd, there is a bubble of unreality they cling to justifying their perception of the world." Seems like someone is quite bitter about new stuff.

Sounds like you're bitter about NFTs being a spectacular failure shilled by charlatans. How much did you lose?

Re: “Vibe Coding” vs. Reality

#183

Post by Apocryphon »

TeMPOraL wrote: post #157
oblio wrote: post #133

Earlier quoted context omitted.

My worry about this approach is: there is a reasonably popular saying that writing code is hard but debugging it is twice as hard (at least), which I think is an accurate description. LLMs will greatly increase code production, will they also increase debuggability to match?

LLMs don't just make it easy to accumulate code - they make it easy to throw code away and start again . This already enables taking a different approach to debuggability - if there's a bug and it can't be trivially solved, trash that bit of the code and write it again . It may not be broadly viable just yet, but it will be if the models keep getting cheaper and better. This is also implied in the idea of "vibe codin…

Sounds very maintainable and rigorously constructed

Re: “Vibe Coding” vs. Reality

#184

Post by Jensson »

TeMPOraL wrote: post #157
oblio wrote: post #133

Earlier quoted context omitted.

My worry about this approach is: there is a reasonably popular saying that writing code is hard but debugging it is twice as hard (at least), which I think is an accurate description. LLMs will greatly increase code production, will they also increase debuggability to match?

LLMs don't just make it easy to accumulate code - they make it easy to throw code away and start again . This already enables taking a different approach to debuggability - if there's a bug and it can't be trivially solved, trash that bit of the code and write it again . It may not be broadly viable just yet, but it will be if the models keep getting cheaper and better. This is also implied in the idea of "vibe codin…

> LLMs don't just make it easy to accumulate code - they make it easy to throw code away and start again.

To throw away code you have to understand it, so no its the opposite. Code you don't understand is the hardest to get rid of, so it stays the longest in your codebase.

> if there's a bug and it can't be trivially solved, trash that bit of the code and write it again

How do you know where the bug is if you don't understand the code? There is no known algorithm to take a bug description and return the place in the code the bug is, otherwise bug fixing would be trivial.

Edit: Not to mention that in real production systems your bugs will corrupt the database, and if you haven't set up a logging system etc you will likely not realize for a while forcing you to do a rollback to a very old state losing so much data. You wont last long doing that.

Re: “Vibe Coding” vs. Reality

#186

Post by lelandbatey »

TeMPOraL wrote: post #146
jmull wrote: post #126

Earlier quoted context omitted.

Well… to be frank, this is someone not reading TFA. The article is pointing out real limitations of vibe coding today (which you appear to agree with). It does suggest AI coding won’t be viable in the future. You should probably update your comment to say something like, “spot on”.

Nah, the article is generalizing from a single sample of current state, ignoring the larger trajectory (that, for AI coding, went from sci-fi to reality in two years ). Sure, the tools aren't perfect, so there's some art to using them now - which the author of TFA seems to be unaware of. Take for example: > You cannot ask these tools today to develop a performant React application. You cannot ask these tools to imple…

Ah yes, the classic "we didn't have this at all 2 years ago, so we can expect a linear increase in capability 2 years from now! Trends will of course continue!"

I think you're wrong. I think AI is going to stagnate and only the surrounding tooling will improve, but not enough to get us to the promised land. Arguably we already are seeing that happen. To see the supposed "this is how all code is written now" world AI proponents keep declaring, we're going to need to see improvements to the current AI where they can operate on context windows two orders of magnitude bigger than they are now, while costs for doing so also drop accordingly. Maybe that can be done, I'm betting it can't.

Re: “Vibe Coding” vs. Reality

#187

Post by Jensson »

TeMPOraL wrote: post #146
jmull wrote: post #126

Earlier quoted context omitted.

Well… to be frank, this is someone not reading TFA. The article is pointing out real limitations of vibe coding today (which you appear to agree with). It does suggest AI coding won’t be viable in the future. You should probably update your comment to say something like, “spot on”.

Nah, the article is generalizing from a single sample of current state, ignoring the larger trajectory (that, for AI coding, went from sci-fi to reality in two years ). Sure, the tools aren't perfect, so there's some art to using them now - which the author of TFA seems to be unaware of. Take for example: > You cannot ask these tools today to develop a performant React application. You cannot ask these tools to imple…

> Of course you can ask them to do it. You can literally ask them to "write better code" (yes, with this exact phrase; see [0]), and you'll get better code. More performant, or more secure - it depends on specifics of the case.

That wasn't the requirement though. He said he wanted a performant or secure app, not "more performant" or "more secure". "more" is trivial, but actually getting to a good state is not.

To actually make a larger program secure or performant you need a unified higher level architecture that is adhered to everywhere, vibe coding can't get you that. It can do some micro optimizations as you said, but it can't do these macro contexts and architecture. You can ask it for suggestions for such architectures, but you can't make it implement a full scale large app with all components using it.

Re: “Vibe Coding” vs. Reality

#188

Post by IshKebab »

bigstrat2003 wrote: post #81
IshKebab wrote: post #60

Earlier quoted context omitted.

Yeah but AI coding does speed up some simple tasks. Sometimes by a lot. But we have to endure these tedious self-congratulatory "mwa ha well it's still not as good as my code" posts. No shit. Nobody is saying AI can write a web browser or a compiler or even many far simpler things. But it can do some very simple things like making basic websites. And sure it gets a lot of stuff wrong and you have to correct it, or fi…

> This post feels like complaining about cruise control because it isn't level 5 autonomy. It's nothing like that, because cruise control works reliably . There is never a situation where cruise control randomly starts going 90mph or 10mph while I have it set to 60mph. LLMs on the other hand... This is why I disagree with people who argue (as you did) "it really does speed up simple tasks". No it doesn't, because eve…

> In less than the time it takes me to do that, I could've written the code myself.

This hasn't been my experience at all. At worst you skim the code and think "nah that's total nonsense, I'll write it myself from scratch", but that only takes a few seconds. So at worst it wastes a few seconds.

Usually though it spits out a load of stuff, which definitely requires fixing up and tweaking, but is usually way faster than doing it all.

Obviously it depends on the domain too. I wouldn't ask it to write a device driver or something UVM or whatever. But a website interface? Sure. "Spawn a process in C and capture its stdout"? Definitely. There's no way you are doing that faster by hand.

Re: “Vibe Coding” vs. Reality

#189

Post by acdha »

TeMPOraL wrote: post #168
acdha wrote: post #136

Earlier quoted context omitted.

I’ve seen a number of outsourcing project failures. The two things they all had in common were that the organizations in question were terrible at managing projects but they blamed the developers for management’s inability to plan or make decisions, and they were trying for unrealistic savings – it wasn’t enough to save 30-50% on salary, they wanted 90% even if that was below the market rate for those skills even in…

> the seagull guys who come in, declare that their favorite framework will solve everything, and leave are more vulnerable to being replaced by an LLM than someone who knows how to code but is also bringing actual business-relevant experience and judgement which an LLM can’t have. But that's just a continuous variant of the discrete-sounding claim that programming will get eaten by AI soon. After all, the "actual bus…

I think that’s a question of how you define jobs. For example, I’ve worked with very few managers who could document their business processes in sufficient detail to build an app. Now, is the person who does a business analyst, architect, senior developer, etc.? Who sits down with the users, gets feedback, but understands the needs of multiple parties well enough to tell which points are traps, which should be developed in a different direction, etc.?

Basically, I’m saying people should stop expecting to get six figures for being able to run create-react-app and deploy a container. The analytical and social parts of the job are where I predict LLMs to make fewer inroads because they require non-generic understanding.

Re: “Vibe Coding” vs. Reality

#190

Post by bardak »

gooseus wrote: post #138

I've been "Vibe-TDDing" all afternoon and I'll tell you what, vibe tests are better than no tests. And so long as you have some decent-to-solid understanding of coding and testing (this is non-trivial, I've been coding for professionally for ~20 years) then you can direct the machine to put up decent guardrails first, and then you can kinda go nuts and let shit grow, prune it back, repeat. Basically, if you know what…

I think it comes down to the fact that LLMs are powerful tools but just like a really good saw can be extremely helpful to a talented carpenter to an untrained person it useless unless they actually learn to do the job
Post reply on HN