Live data from Hacker News

“Vibe Coding” vs. Reality

cendyne.dev

51–60 of 312 posts

Re: “Vibe Coding” vs. Reality

#51
post #14
post #3

Vibe Coding is a trigger word for devs who insist it's a pointless exercise because it doesn't do 100% of the job. Devs don't seem to realize that's not the point - the point is you can hire less devs if you're only worried about the remaining 20%. Also this article is immensely distracting.

Currently, AIs emulate a less skilled, junior developer. They can certainly get you up and running, but adding junior developers doesn’t speed up a lot of projects. What we are seeing is people falling into the “mythical man month” trap, where they believe that adding another coding entity will reduce the amount of work humans do, but that isn’t how most projects come out. To put it simply, it doesn’t matter if AI do…

Indeed. My roommate has just been put on a new project at his workplace. No AI involved anywhere. But he inherited a half-done project. Code is even 90% done. But he is spending so much time trying to understand all that existing code, noting down the issues it has which he'll need to fix. It's not just completing the remaining 10%. It's understanding and fixing and partially reworking the existing 90%. Which he has to do, since he'll be responsible for the thing once released. It's approaching a point where just building it from scratch on his own would have been more time efficient.

It seems to me that LLM output creates a similar situation.

Re: “Vibe Coding” vs. Reality

#52
post #40

I mean ... most code out there is pretty bad, so LLM assistants contributing pretty bad code just keeps the mean where it is. And obviously it has to be, how can anybody expect an LLM to produce output with quality that's higher than its training input? Expecting that is appealing to magic or some consciousness that doesn't actually exist or just plain anthropomorphising. If you are working at a place where that qual…

"Bad" is doing s lot of work in your sentence. Do you mean slow? Or buggy? Or unmaintainable? Or unextendable? Uses patterns the tech lead hates? Hard to read? High cyclomatic complexity? Doesn't meet requirements? Security issues? Uses out of date libraries? Too much reliance on 3rd party code? Too much NIH? ...

I think "one shot ready for production code" is what AI cannot do yet. Which is why I am not worried for another 12 months at least :)

Re: “Vibe Coding” vs. Reality

#53

At this point in time, we're following the time corporate got on the outsourcing craze step for step. It had all the hype, hands off, cheaper for the same work, faster to market, every other argument you've all certainly heard. Then the reality hit. The whole discussion around LLM coding agents feels indistinguishable.

My first job in the industry was cleaning up a large codebase created overseas by indian developers. Maybe the new kids today will break into the industry by cleaning up messes that have been generated by AI.

Re: “Vibe Coding” vs. Reality

#54

At this point in time, we're following the time corporate got on the outsourcing craze step for step. It had all the hype, hands off, cheaper for the same work, faster to market, every other argument you've all certainly heard. Then the reality hit. The whole discussion around LLM coding agents feels indistinguishable.

> Then the reality hit.

Are we talking about the reality where the size of the global software outsourcing market is $618 billion and growing? https://groovetechnology.com/blog/software-development/outso...

Re: “Vibe Coding” vs. Reality

#55
If you believe in vibe coding, surely you are holding a massive short position in every major software company, no? I mean, surely, any day now, a bored student will vibe code a full replacement for a major software package and destroy the income of the SW giants one by one, right?

Wake me up when someone vibe codes a Chrome replacement, or an iOS replacement, or MS Office...

Except we know this won't happen anytime soon because we all know vibe coding isn't very useful beyond toy projects that leverage complex libraries written by actual developers.

Re: “Vibe Coding” vs. Reality

#56
post #46
post #44

Earlier quoted context omitted.

.. new stuff that quite obviously won't be able to live up to its hype. Indeed. Or would you argue that NFTs actually did live up to the BS that was ascribed to them in some circles during their hype?

Obviously not. But "some circles" ascribe BS to any new technology.

And some circles hand wave away all criticism of any new thing as luddism.

This article is a bit more balanced, though, and clearly isn't criticising use of AI in programming, but specifically the "Jesus take the wheel" style of vibe coding. It's the same old "if you write code as cleverly as you possibly can, you are not smart enough to debug it", but to the next level, where people are writing code that they aren't even smart enough to read.

Re: “Vibe Coding” vs. Reality

#57
post #4

The more I work with LLMs and try things like "vibe coding" the less worried I am about AI taking my job any time soon. In the right contexts, I find LLMs can speed up my work a lot. But it's nowhere close to being able to replace what I do.

I work at a company relatively well-known in Startup-land and I've replaced a product team which had 9 devs 2 years ago with 2 devs with AI. Devs are just coping so hard around LLMs its hard to watch. OTOH the few engineers who have embraced it are excelling.

I'd take strong opinions for/or against with a grain of salt. It's likely you're suffering a bit from baader meinhof.

I could certainly see a possible reduction in engineering team size, but going from 9 to 2 makes me question how much of that reduction was a result of over-hiring in the first place.

Re: “Vibe Coding” vs. Reality

#58
I'll share a new wrinkle that casts more shade on the coding LLMs.

We have a fair number of offshore resources that are used for dev. They developers are fully integrated into the team, are in all the stand-ups, and substitute for the usual role of junior programmers. They don't get the grunt-work shoveled on them, they get the same work as everyone else, they're just expected to not be as fast.

In 6 months 2 out of 4 of them been sacked, and surprise, not because we could replace their work with LLM output, but because their use of LLMs was so unrestrained and scattershot the pull requests they submitted had become nightmares. One thing mentioned in the article about unit test creation was something we saw as well. Perhaps this is partly due to working an existing code base where the LLM loses some of its advantage, and certainly some of it was cultural in that progress was thought more important than actual manageable code. The two sacked fellows where told, literally, from my own mouth, multiple times, "You cannot just ask Copilot to write you code, paste the entire thing into Visual Studio with no thought of what has changed, with the end goal of just compiling and meeting the single set of acceptance criteria on your story. You're breaking other things and introducing bugs." It went on deaf ears, and now they're gone. They were nice people, I didn't know how to get through to them, but they were convinced the LLMs were the way to go.

I use LLMs to help write code every day, and I wouldn't want to be without it, but I'm fairly surgical about it. Most of the time Copilot gives you a page of say, React code, or EF Core queries, you have to be really careful about anything you didn't explicitly ask for. Honestly, there is a time savings, but there is not a quality increase. The benefit is subverted by the time it takes to figure out how to ask correctly, the time to vet the output, and the time to fix the little tiny insidious bugs it can introduce.

So, don't go vibe coding and lose your job, is something to think about. I have to admit that it has worn me down meeting these interesting people from far-flung locations only to watch them flounder and get let go.

Re: “Vibe Coding” vs. Reality

#59
post #25
post #10

Earlier quoted context omitted.

Speeding up your work does lead to job loss. If some developers can suddenly be 3x as productive than a company doesn't need as many engineers.

The job loss depends on the average speed up, however. If the AI is only effective in 10% of tasks (the basic stuff), then that 3x improvement goes down to 1.3x.

> The job loss depends on the average speed up,

That's such a economical fallacy that I'd expect the HN crowd to have understood this ages ago.

Compare the average productivity of somebody working in a car factory 80 years ago with somebody today. How many person-hours did it take then and how many does it take today to manufacture a car? Did the number of jobs between then and now shrink by that factor? To the contrary. The car industry had an incredible boom.

Efficiency increase does not imply job loss since the market size is not static. If cost is reduced then things are suddenly viable which weren't before and market size can explode. In the end you can end up with more jobs. Not always, obviously, but there are more examples than you can count which show that.

Re: “Vibe Coding” vs. Reality

#60
post #14
post #3

Vibe Coding is a trigger word for devs who insist it's a pointless exercise because it doesn't do 100% of the job. Devs don't seem to realize that's not the point - the point is you can hire less devs if you're only worried about the remaining 20%. Also this article is immensely distracting.

Currently, AIs emulate a less skilled, junior developer. They can certainly get you up and running, but adding junior developers doesn’t speed up a lot of projects. What we are seeing is people falling into the “mythical man month” trap, where they believe that adding another coding entity will reduce the amount of work humans do, but that isn’t how most projects come out. To put it simply, it doesn’t matter if AI do…

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 fix it yourself. But it's still usually faster than doing everything manually.

This post feels like complaining about cruise control because it isn't level 5 autonomy. Nobody should use it because it doesn't do everything perfectly!

Post reply on HN