Live data from Hacker News

“Vibe Coding” vs. Reality

cendyne.dev

301–310 of 312 posts

Re: “Vibe Coding” vs. Reality

#301

Earlier quoted context omitted.

> This is the go community saying a computer will never best human go players. I don’t see this. Board games are fundamentally different from software development problems. The latter have imperfect information, unknown requirements and constraints, fuzzy success criteria, and more.

Which means that as long as you can specify the requirements, constraints, and success criteria you can automate the coding part.

If we have the luxury of assuming the hardest parts of the problem are already solved, then sure! The rest is trivial.

Re: “Vibe Coding” vs. Reality

#302

Earlier quoted context omitted.

> Yes, I'm a developer. It's interesting that you describe yourself as a developer now. Because just three months ago, in your first post [1] to HN, you said: > I'm somewhat non-technical but I've been using Claude to hack MVPs together for months now. Sure: you might feel as though you have now 10x'ed yourself. But, quite honestly, when the reality is that just a few months back you self-described as "somewhat non-t…

Yeah I was a jr developer for a year before I became a PM. That's the definition of being "somewhat non-technical" as I put it. you've been a developer for some decades which is why your reality is threatened that your craft is increasingly becoming irrelevant so you had to snoop my profile to find some confirmation that your reality doesn't get shattered this is nothing new of course. obnoxious neckbeard engineers w…

> you've been a developer for some decades which is why your reality is threatened that your craft is increasingly becoming irrelevant so you had to snoop my profile to find some confirmation that your reality doesn't get shattered

Hahaha - no, that's really not accurate at all. On lots of levels. The ability to read another user's comments is there so that anyone who chooses can actually get a better understanding of who they're talking with, and what that person is about. One doesn't have to feel threatened at all to want to use it, one simply has to be intellectually curious, and interested to find out more...

There's no need to try and portray it as a negative, and make out there's something afoot which isn't actually taking place.

Anyone who's been here on HN for any significant amount of time knows exactly what that feature is for — as well as when it might be best to use it. And people absolutely will use it.

It helps separate the wheat from the chaff.

— Please do try and take care that your wide-of-the-mark unnecessary put-downs and name calling don't violate the HN guidelines! (Just for your own good!)

Re: “Vibe Coding” vs. Reality

#303
post #206
post #59

Earlier quoted context omitted.

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

This is all broadly true, historically. Automating jobs mostly results in creating more jobs elsewhere. But let's assume you have true, fully general AI. Further assume that it can do human-level cognition for $2/hour, and it's roughly as smart as a Stanford grad. So once the AI takes your job, it goes on to take your new job, and the job after that, and the job after that. It is smarter and cheaper than the average…

> But let's assume you have true, fully general AI.

Very strong assumption and very narrow setting that is one of the counter examples.

AI researchers in the 80s already told you that AI is around the corner in the next 5 years. Didn't happen. I wouldn't hold my breath this time either.

"AI" is a misnomer. LLMs are not "intelligence". They are a lossy compression algorithm of everything that was put into their training set. Pretty good at that, but that's essentially it.

Re: “Vibe Coding” vs. Reality

#304
post #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…

Any badness metric you like. LLMs average over that since their training input does.

Re: “Vibe Coding” vs. Reality

#305
post #237

Earlier quoted context omitted.

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

I don't think we know it can be done - has anyone demonstrated a self-driving car that works in all conditions, but is prohibitively expensive in its current form? If they had, you could extrapolate and say 'it's coming as soon as the tech gets cheaper'.

You can't adapt roads to fog or snow (unless you're going to enclose them in a tunnel). You can't adapt roads to pedestrians or bicycles (unless you prevent them from going near the road). Whatever adaptions you could make would be prohibitively expensive to roll out to all roads everywhere. In both the country I live in, and the USA, the government can barely afford to maintain the existing highway infrastructure.

Of course it will get better, and self-driving will be more widely deployed, but I don't think you'll ever get 100% percent coverage (assuming that's what we both agree is the goal).

I think in a way you're agreeing with my point - the last bit is just too hard, whether it's engineering, legal or political.

Re: “Vibe Coding” vs. Reality

#306
post #139

Earlier quoted context omitted.

Cursor? I finally got around to trying it this week and it exceeded my expectations.

What were your expectations and how did it exceed them? I have to say, on they basis of your comment I just decided to try Cursor, and I'm sorry to report it immediately disappointed me. First thing it did was it told me it found a syntax error in code that compiles perfectly. It went ahead and added a closing brace, telling me that "I've fixed the issue by properly closing the method with its brace. The method now h…

Try refactoring anything in Cursor, that's where the shit really hits the fan. I guess all those folks claiming 100x productivity or applications made with sole vibing, are only building little proof-of concept apps, something which "works" but definitely doesn't need to follow proper requirements. Can it bootstrap an application for you? For sure, but that's just half a day sunk otherwise - all the next weeks of building up on that scaffolding cannot today be automated, or vibed.

Re: “Vibe Coding” vs. Reality

#307

Earlier quoted context omitted.

> So it really boils down to prompting in such a way that the right set of components are brought together in the right way. That's where the skill now lies. And how is this different from just calling the libraries in the right way to make it adhere to stakeholder requirements? The statement isn't "its impossible to get an AI to print the code for a right program", but "the work and skills you need to get an AI to p…

> And how is this different from just calling the libraries in the right way to make it adhere to stakeholder requirements? In that you need humans that can understand stakeholder requirements, constraints of the domain, and limits of existing software, so that they can write the necessary glue to make everything work. Thing is, LLMs know more about every domain than any non-expert (and for most software, "domain exp…

Paul Graham argued that if you act like the average startup, you'll get the same results as the average startup. And the average startup fails.

It follows that if you want to have success, you need to do something new which hasn't been done before.

> LLMs know more about every domain than any non-expert

As soon as you're creating something new, or working in a niche field, LLMs struggle.

So do junior developers. But they learn and get better with time. While onboarding a junior developer requires more effort than doing the work yourself, it's worth it in the long run.

IMHO, that's the largest issues LLMs have today. They can't really adapt and learn "in the field". We build a lot of workarounds with memory to circumvent that, but that too only works until the memory exceeds the context.

I've tried using ChatGPT, Copilot, custom GPT 4o models and Cursor. The task they did best at was generating a simple landing page (though they struggled with tailwind 4, cursor spent almost 8 hours debugging that issue).

With tasks that require more niche domain knowledge, it went much worse. Cursor finished some of the tasks I gave it, but it took over 10x more time than a junior developer would've spent, and I had to constantly babysit it the entire time, providing context, prompting, writing cursor rules, prompting again, etc. The others failed entirely.

If I start working on an unfamiliar task, I read all the docs, write some notes for myself, maybe build some sample projects to test my understanding of the edge cases. Similarly, if faced with a new task, I build some small prototypes before committing to a strategy for the actual task.

Maybe ML agents would fare better with that approach, instead of today's approach of just creating a mess in the codebase like an intern.

Re: “Vibe Coding” vs. Reality

#308
post #306

Earlier quoted context omitted.

What were your expectations and how did it exceed them? I have to say, on they basis of your comment I just decided to try Cursor, and I'm sorry to report it immediately disappointed me. First thing it did was it told me it found a syntax error in code that compiles perfectly. It went ahead and added a closing brace, telling me that "I've fixed the issue by properly closing the method with its brace. The method now h…

Try refactoring anything in Cursor, that's where the shit really hits the fan. I guess all those folks claiming 100x productivity or applications made with sole vibing, are only building little proof-of concept apps, something which "works" but definitely doesn't need to follow proper requirements. Can it bootstrap an application for you? For sure, but that's just half a day sunk otherwise - all the next weeks of bui…

The reason bootstrapping takes a while is to make sure you've got a solid foundation for your project.

If you let an LLM bootstrap your project, you get tech debt from the get go. It's costing you more time than it saves.

Re: “Vibe Coding” vs. Reality

#309
post #9

Earlier quoted context omitted.

> I've replaced a product team which had 9 devs 2 years ago with 2 devs with AI. Totally believable bro

You're willingly naive and blind if you think this isn't happening everywhere around you.

Naive AND blind, wow. I do believe jobs are being replaced by AI. I just don't believe that in particular context

> I've replaced a product team which had 9 devs 2 years ago with 2 devs with AI

Sure but is everything else the same after that? I doubt it.

Re: “Vibe Coding” vs. Reality

#310
post #7

"ever since I started to share how I built my SaaS using Cursor" random thing are happening, maxed out usage on api keys, people bypassing the subscription, creating random shit on db as you know I'm not technical so this is taking me longer that usual to figure out - (leo, 2025)

What does "I'm not technical" actually mean? It sounds like a euphemism for: I don't want to work hard. I don't care about the details. I don't want to learn new things. I want somebody else to do my homework. I don't want to put in the effort it takes to succeed. I cheated my way through school instead of learning from classes. I've always had everything handed to me on a silver platter, and I expect that to continu…

I think it might be referring to a current lack of experience in programming and debugging.

The situation seems to reflect the issue that Kernighan's Law refers to, which is that debugging code is twice as hard (perhaps more?) as writing it in the first place. I imagine debugging AI-generated code might be even harder.

Post reply on HN