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

261–270 of 312 posts

Re: “Vibe Coding” vs. Reality

#261

Post by TeMPOraL »

anon373839 wrote: post #247
TeMPOraL wrote: post #157

Earlier quoted context omitted.

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…

> 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 throwing it away and generating anew at any sign of bug (or spec change) gets cheap enough, this is what the business will want to do. This is what being Professional will mean.

(You can imagine I don't hold "professionalism" in a very high regard.)

See also: basic goods in meatspace. In developed economies, people generally don't repair clothes anymore, and increasingly rarely anyone bothers with repairing appliances. It's cheaper to just throw it away and buy a new one, than to try and repair it. Hell, even construction and remodeling these days involves a lot more of "affix it here permanently; if you need to move it, just smash it and install a new one" approach.

Why wouldn't the same eventually happen with code?

Re: “Vibe Coding” vs. Reality

#262

Post by DonHopkins »

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 trying to guess and shart its way out of it instead of addressing the real problem? And it's extremely hard to talk it out of doing that, I have to keep reminding it and admonishing it to cut it the fuck out, fail instead of mitigate, address the root cause not the symptoms, and stop trying to close the barn door after all the horses have escaped. It's as of it was only trained on Stack Overflow and PHP manual page discussions.

Re: “Vibe Coding” vs. Reality

#263

Post by TeMPOraL »

Jensson wrote: post #184
TeMPOraL wrote: post #157

Earlier quoted context omitted.

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 u…

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

No, you don't.

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

Yes, there is.

At worst, the bug is somewhere in the entire project. But you probably have a more narrow idea where the bug is, or when it was introduced. "In module X", "In feature Y", "In the last N days/weeks". Not to mention, for most bugs, `git bisect` is enough to precisely narrow down the problematic change, and doing that doesn't actually require understanding anything about the code.

It all boils down to costs. Even if it takes AI a whole day and 1000 attempts to do what would be a relatively simple fix for an experienced developer, if those 1000 attempts cost less than the developer's work-hours, the business will soon learn to prefer AI over people. If and when we get to that point, is mostly just a function of LLM performance and cost. If they get cheap enough, it'll make as much sense to have human developers fix bugs in code, as it makes sense for you to mend holes in your socks instead of buying them in bulk on-line.

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

This really depends on the kind of system you're doing, and the kind of data you're storing.

Re: “Vibe Coding” vs. Reality

#264

Post by TeMPOraL »

Panzer04 wrote: post #242
TeMPOraL wrote: post #157

Earlier quoted context omitted.

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…

Ever heard of chesterton's fence? If you don't understand what the code is doing, removing it sounds like a recipe for disaster.

Have you ever heard of shirts?

In the past, if you'd tear your shirt, you'd spend time mending it, or pay someone to do it for you. Today, you just throw it in the trash and buy a new one, as it's much cheaper and faster.

Think of any other goods we don't repair anymore. Regardless of their internal complexity and beauty of engineering, and no matter how small the defect is, if it's cheaper to replace it wholesale than to repair it, people end up replacing it.

There's no reason to believe the same won't happen to code.

Re: “Vibe Coding” vs. Reality

#265

Post by TeMPOraL »

Apocryphon wrote: post #238
jryle70 wrote: post #222

Earlier quoted context omitted.

How do you know it won't be maintainable? based on your current knowledge?

Generating tons of throwaway code that is swapped out every time a bug occurs does not sound like engineering for the long-term.

Since when does any business care about "engineering for the long-term"?

We, the software engineers, care. The business doesn't. In fact, the industry has systematically been trying to beat the care out of engineers - it's unprofessional to care about the work beyond the point it stops making money for the business.

I'm not saying this is right or wrong - but this is how companies roll; if they can fix product issues by having AI throw chunks of code away and do it again, if that's reliably cheaper than having engineers do actual engineering, then that's what businesses will do.

Re: “Vibe Coding” vs. Reality

#266

Post by TeMPOraL »

raydev wrote: post #237
jryle70 wrote: post #217

Earlier quoted context omitted.

We do have self car driving by now. No drivers. Easy to find in SF and many other cities. It's not yet available everywhere, but as the Amara's Law describes, "we tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run".

> It's not yet available everywhere It's not available most anywhere. I don't know what exactly what the threshold should be, but it should be usable by most people in first world countries to make the claim "we have it". We don't have it.

Self-driving has been long proven to be a workable idea. Yes, there's the other 90% of the work making it work reliably and safely enough in diverse environments, but we know this can be done, it's just a matter of throwing money at it.

And it's not like there isn't a possible alternative either - we could be adapting roads to be much easier on self-driving cars. It's just that cooperation and coordination between humans is a way harder problem than self-driving, so it's easier to have a bunch of vendors solve the problems in tech the hard way, rather than to rely on the world to maintain roads properly.

My belief is that, if full self-driving isn't becoming widely available in first world countries in 5 years, it's not going to be because of engineering problems, but rather because of legal and process issue around deploying it.

Re: “Vibe Coding” vs. Reality

#267

Post by acdha »

TeMPOraL wrote: post #258
acdha wrote: post #189

Earlier quoted context omitted.

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 develo…

> 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. That's a fair take. I do wonder though, how much will those "analytical and social parts of the job" be paying - I imagine you might no longer get six figures…

Yeah, I’m really not sure either with the general backdrop of looming American disinvestment and the entire world reconsidering reliance on American companies. I don’t think reversing the trend of consolidation is going to be enough to balance it out.

Re: “Vibe Coding” vs. Reality

#269

Post by TeMPOraL »

Nextgrid wrote: post #62
CharlesW wrote: post #54

Earlier quoted context omitted.

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

The market can stay irrational for longer than you can stay solvent. This is not to say outsourcing can't ever work, but the situations where it does work are much rarer than what every outsourcing vendor would like you to believe. I bet a previous client's attempt at outsourcing (well into the 6 figures now) is included in that number... yet the expensive onshore devs outsourcing was supposed to replace are still th…

FWIW, if you believe that long-term, the market is a good optimizing engine (I think it's a very reasonable and well-proven belief), then this is just a matter of time before things sort themselves out.

The need for companies to get more value out of less spend won't disappear, nor will the comparative advantage of companies in lower CoL areas of the globe. That's two fundamental incentives on both sides that are aligned, driving the market to find the lowest-energy path from here to there. It'll get there, even if it ends up looking strange (like, idk., maybe cutting out management intermediaries but involving a middleman acting as insurance).

That is, if LLMs won't leapfrog it all and end software dev outsourcing before it started to work well.

Re: “Vibe Coding” vs. Reality

#270

Post by axegon_ »

dragonelite wrote: post #155
axegon_ wrote: post #34

I hate how what is effectively a stupid meme phrase became an actual term in a few days. > "Vibe Coding" might get you 80% the way to a functioning concept. But to produce something reliable, secure, and worth spending money on, you’ll need experienced humans to do the hard work not possible with today’s models. The problem is that 80% of the job is a proof of concept at best. 80% is effectively a QA walking into a b…

80% mark means you just finished the happy flow and written 30% of the code bases. Now you need to handle the unhappy parts and need to write extra test code for covering all those edge cases.

Precisely, now you need to finish off the remaining 70%, which is where most of the work that is required truly lies, with or without all the AI bollocks. Whether it takes 2 or 8 days of work to get those 30% done, it's not much of a difference if you need several months(or in some cases years) to get a project to a tolerable "production" state. I'd much rather spend 8, as opposed to an AI-generated codebase which will shoot itself in the head because someone scrolled over it and thought "lgtm".
Post reply on HN