Live data from Hacker News

“Vibe Coding” vs. Reality

cendyne.dev

291–300 of 312 posts

Re: “Vibe Coding” vs. Reality

#291

Is it just me, or has anyone else noticed that: 1) Cursor has been crashing several times an hour for me recently. 2) Cursor seems to ignore .cursorrules files. I'm using the json format that's supposed to let you filter on file name patterns (although how that works for cross-cutting agent stuff I don't know). 3) Cursor is obsessed with making sketchy iffy defensive code checking for the most recent symptom and tryi…

(3) Cursor does not do the coding, it delegates that task to whatever model you have picked. In more recent versions, it does pick the model automatically, which is not necessarily what I would prefer. Some of the models it delegates to may have been trained the way you suggested here, others are more sophisticated. The fact that none of the models is controlled by the Cursor crew quite naturally means that it will have quirks talking to newer models.

Re: “Vibe Coding” vs. Reality

#292

Earlier quoted context omitted.

I wouldn't bet against it. Self-driving tech benefits directly from the outputs of sudden and continued growth of R&D in AI, fueled by hype-driven investments.

Maybe just like with self-driving cars, trying to hook mechanical precision up to messy human society is going to be fraught and lead to blowback. Meaning that once planes start falling out of the sky from vibe coding Boeing contractors there will be PR and regulatory panics that soften the hype somewhat. Or, the next time Equifax gets mass leaked and they blame their security setup on generative AI. You can’t vibe c…

Maybe, but the same thing could be said about JavaScript and webshit and the world is still there. We can just continue to not use YOLO technologies and culture in safety-critical applications.

Re: “Vibe Coding” vs. Reality

#293

Earlier quoted context omitted.

That assumes a static demand for development services, which has, more or less, never happened since computing became a thing. Python, and other high level languages made a lot of development much faster, but it never lead to reduced engineering needs. Cloud made deploying services massively easier, and as a result we actually have a lot more people working in infrastructure. Faster development mostly leads to expand…

Jevon's Paradox: https://en.wikipedia.org/wiki/Jevons_paradox "In 1865, the English economist William Stanley Jevons observed that technological improvements that increased the efficiency of coal use led to the increased consumption of coal in a wide range of industries. He argued that, contrary to common intuition, technological progress could not be relied upon to reduce fuel consumption."

It's the same reason widening the road doesn't lead to less traffic.

Re: “Vibe Coding” vs. Reality

#294

Earlier quoted context omitted.

Now, now, not with this mindset. You have to ask the Ai to fix the mess, and if it doesn't, try again!

As if the person struggling with the mess will have the requisite skill levels to even recognise a mess!

Recognizing a mess is much easier and takes less skill than fixing it.

Re: “Vibe Coding” vs. Reality

#295
post #197

Earlier quoted context omitted.

As a counter to this, I had grok build an entire set of micro services and all I had to clean up was some format strings. It blew me away. Did in an hour what should have taken a week.

i'm not sure if you can compare run of the mill micro services with "uncommented academic modeling code from Matlab".

Exactly. "uncommented academic modeling code from Matlab" is something very few people ever do, and the importance of that work is negligible in isolation. Meanwhile, "run of the mill micro services" are like most of what the software industry is doing these days; in aggregate, it's also how the industry delivers most of its value and how it makes most of its money.

It's the CRUD thing all over again.

Re: “Vibe Coding” vs. Reality

#296
post #288

Earlier quoted context omitted.

> if a large part of our job is purely mechanical, then there is a bigger problem with our engineering processes and AI can't fix that. It is! And AI is fixing precisely that. What businesses actually care about (well, 99% of them where code is written) is shipping fast and solving the immediate problem, NOT code quality and craft. It goes against what I want to believe as an engineer. Most problems are not new, they…

> And AI is fixing precisely that. I don't think AI is really fixing business problems, though. I think it's only fixing developer problems. And unfortunately nobody really cares about that except for developers. I just find it sad that instead of focusing on improving how we build things and reducing the need for so much mindless, tedious, repetious, mechanical work, we're content to just build bad things faster wit…

> I just find it sad that instead of focusing on improving how we build things and reducing the need for so much mindless, tedious, repetious, mechanical work, we're content to just build bad things faster with AI and call it a win.

The AI is doing precisely that: reducing the mindless, tedious, repetitious, mechanical work. And what "vibe coding" wants you to embrace is treating high-level code as if it were compiled assembly: an implementation detail you never want to look at or care about if you can help it.

Yes, in some sense AI isn't fixing anything, because all that "mindless, tedious, repetitious, mechanical" code still exists, it's just autogenerated. I too wish we could've first eliminated the need for that entirely. But we didn't, because most programmers and the industry at large still don't understand where the problem is in the first place. They can't see we've long reached Pareto frontier in our programming languages, that we're being limited by the default paradigm of working directly on plaintext codebase that's a single source of truth.

So yeah, in this sense, LLMs aren't fixing anything - they're just an abstraction layer on top of our exhausted coding paradigm.

Re: “Vibe Coding” vs. Reality

#297

Earlier quoted context omitted.

> if there's a bug and it can't be trivially solved, trash that bit of the code and write it again When I was in undergrad, I knew a few guys who approached every problem by pasting in snippets from Stack Overflow and tutorial sites until the code “worked”. Did not end well…

That was then, and this is now. Look, I understand the sentiment. I too want the code to be done properly , well-engineered and thought through. But recall, this is not our job . We are Professionals , and by modern definition, a Professional does whatever is best for the business. And the business doesn't care about the product - it cares about the product's ability to earn them money. If generating shit code, then…

[deleted]

Re: “Vibe Coding” vs. Reality

#298

Earlier quoted context omitted.

> if a large part of our job is purely mechanical, then there is a bigger problem with our engineering processes and AI can't fix that. It is! And AI is fixing precisely that. What businesses actually care about (well, 99% of them where code is written) is shipping fast and solving the immediate problem, NOT code quality and craft. It goes against what I want to believe as an engineer. Most problems are not new, they…

> shipping fast and solving the immediate problem, NOT code quality and craft This is also what puts many companies out of business and create huge security issues. If AI is not fixing this but making it worse, then that's not improving software engineering.

> This is also what puts many companies out of business

Those companies you mention just overdid it. Like with everything else on the market, there's a limit to how much value/quality you can optimize away before the end result stops being fit for purpose. However, existence of this limit doesn't stop companies from racing to the very edge of it.

> and create huge security issues.

Security is mostly a solved problem.

Yes, it truly is - at least from the business point of view.

Nobody except attackers and infosec people cares about the mathematical and technical details, or whether your stack or coding practice is secure enough. Not the customers, as they neither understand any of this, nor could do anything about it even if they did. Not the companies, since they manage it at a higher level of abstraction. Whatever holes and vulnerabilities the AI coding introduces, the industry will account for it. Some headlines will be made, some stocks will move, and nothing will change.

FWIW, I don't like either of these things. I'm an engineer in my heart, so it pains me to be constantly reminded that our work is merely means to an end, and matters only to the extent it can't be substituted by some alternative.

Re: “Vibe Coding” vs. Reality

#299
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…

> 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).

You seemed to have missed the part of the article that clearly lays out the recent progression of AI coding. You’re also refuting the arguments the article makes against the future of vibe coding, but the article doesn’t make any arguments about the future of vibe coding!

We all just end up talking past each other if no one is actually talking about the same thing.

Re: “Vibe Coding” vs. Reality

#300

Earlier quoted context omitted.

> if there's a bug and it can't be trivially solved, trash that bit of the code and write it again When I was in undergrad, I knew a few guys who approached every problem by pasting in snippets from Stack Overflow and tutorial sites until the code “worked”. Did not end well…

That was then, and this is now. Look, I understand the sentiment. I too want the code to be done properly , well-engineered and thought through. But recall, this is not our job . We are Professionals , and by modern definition, a Professional does whatever is best for the business. And the business doesn't care about the product - it cares about the product's ability to earn them money. If generating shit code, then…

This is an interesting thought experiment, but I don’t think it’s realistic. Software that “works” doesn’t necessarily work. And software that doesn’t work can cost catastrophic financial losses. Worse yet, those losses are going to be felt more painfully when they are incurred recklessly.

There is a reason that humans developed analytical problem solving as an alternative to trial and error: when you can do it, it’s more effective, and safer.

That’s not to say that disposable code doesn’t have some interesting implications! One of them is that experimentation becomes a lot cheaper, so it’s faster to navigate the search space of possible solutions to a problem. But just taking a “solution” directly from an LLM without validating its correctness is fundamentally unserious and will be punished by reality sooner or later.

Post reply on HN