Live data from Hacker News

“Vibe Coding” vs. Reality

cendyne.dev

211–220 of 312 posts

Re: “Vibe Coding” vs. Reality

#211

Earlier quoted context omitted.

> Most of webdev has been done 1000000x before Not according to your very specific stakeholder demands / environment/naming/data tables/data protection requirements, otherwise you would just use a library. Those might seem like trivial differences but plenty of things go wrong there, plenty enough that you can't just use a library instead of a programmer, and then they are plenty enough of such errors that vibe codin…

I think the point being made is that even though the specific set of requirements may be unique in a stakeholder basis, all the components already exist, and have been combined in many ways. 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.

> 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 print the right program is as much or more than to do it yourself.". That seems to be true for all but trivial programs. Here trivial means you can download a git repo and change some variables to get that result.

Re: “Vibe Coding” vs. Reality

#212
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?

I think probably people will also use LLMs to debug. At this point, I think you can consider vibe-coding with an LLM to be pretty equivalent to using a fairly junior developer with access to stack overflow. It's going to make a lot of mistakes, it's going to make a lot of questionable decisions. Sometimes it will be able to fix its mistakes, sometimes it will spin its wheels and never fix it. It may make a big ball o…

> I think probably people will also use LLMs to debug.

I don’t have a link handy, but someone has already set up a service that’s “JS time travel debugger + LLM that knows how to use it”

Pretty sure it was a Show HN recently.

Re: “Vibe Coding” vs. Reality

#214
post #205
post #66

Earlier quoted context omitted.

Alternatively: if LLMs make devs 3x productive that means companies can get 3x the value out of an engineering hire, so they should hire more. (Unless that company somehow has no substantial engineering backlog, which I've yet to encounter anywhere I've ever worked.)

This definitely feels true for tech companies where the prospect of more more productive engineers improves their bottom line. The same sort of companies that have a near infinite appetite for talented engineers. But there's a lot of coders in industries whose core business isn't technology. Knapheide for example, a truck outfitting company where my brother codes. I'd imagine in those companies, being able to do the…

I actually think we may see the opposite happen with those kinds of companies too.

At the moment, a truck outfitting company building a customer CRM optimized for their workflow is an absurd idea: they would need a team of a dozen developers working for a year before they could even get a feel for if it was a feasible project or not.

Add LLM assistance and maybe a team of three developers could get to an initial working version in three months.

At that point, companies that had previously ruled out custom software development entirely may find that it makes sense for them - growing the demand for software engineers as a whole.

Re: “Vibe Coding” vs. Reality

#215

Earlier quoted context omitted.

Are you a developer yourself? Product people love the idea of being able to fire their dev teams, but I'm not sure they understand the implications (some of wich may not become clear for years).

Yes, I'm a developer. LLMs allow engineers to become product people themselves.

> 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-technical", it's clear that (a) you're at such an early stage in your learning and understanding of tech, as a developer, that it's relatively easy to experience bigs gains, and (b) you can't actually have much of an objective measure on this, because you are in fact quite new to the field.

I read a lot of your other comments. To me, even before I had confirmation that you were actually "somewhat non-technical", and fairly new to the field — effectively a junior developer by any real measure — this was already quite apparent to me.

Based upon having been a developer for some decades myself already: I can generally spot those that talk-the-talk — and similarly: I can generally spot those who have non-trivial / deeper experience with various fields of tech.

Powering-up with AI tooling doesn't remedy that. Even if it might seem otherwise from your "somewhat non-technical"-but-newly-empowered position.

Good luck with your coding endeavours though, and with your evangelism.

I have no doubts at all that the world is changing — including how software is developed. But I see your posts for what they are.

[1] https://news.ycombinator.com/item?id=42423573

Re: “Vibe Coding” vs. Reality

#216

Earlier quoted context omitted.

I think the point being made is that even though the specific set of requirements may be unique in a stakeholder basis, all the components already exist, and have been combined in many ways. 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.

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

It's a switch of focus. Instead of being occupied by the grunge work of integrating libraries and code logic from the outset, now focus can remain on the larger picture for longer, with a need to jump into raw code only for the really tricky/unique problems, if there are any. That can be a lot of overheat avoided, if done well.

Re: “Vibe Coding” vs. Reality

#217

Earlier quoted context omitted.

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…

Remember 2016/17 when we all thought we would have self-driving cars by now? People were modelling intersections without traffic lights, and talking about not needing parking space because the cars would just drive around when you weren’t in them. So much technology these days seems to be “get it to 80% so we can demo and cash out” but 80% isn’t just an arbitrary number - it seems to be the point and which the remain…

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

Re: “Vibe Coding” vs. Reality

#218

Earlier quoted context omitted.

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…

Remember 2016/17 when we all thought we would have self-driving cars by now? People were modelling intersections without traffic lights, and talking about not needing parking space because the cars would just drive around when you weren’t in them. So much technology these days seems to be “get it to 80% so we can demo and cash out” but 80% isn’t just an arbitrary number - it seems to be the point and which the remain…

[flagged]

Re: “Vibe Coding” vs. Reality

#219
post #113

Earlier quoted context omitted.

I think it’s partially there: For creating website (not apps) it absolutely is there. This is just the first rung on the ladder though. It’s not doing Linux kernel development yet, but that time will come eventually. In between are all the other rungs. AI will climb them one by one.

For me it is very much hit or miss. I use claude sonnet with Cline. Sometimes I'm blown away that it can create a new page with CRUD functionality, nice UI etc. in one go. Another time it struggles to create a simple web page. Yesterday I needed a very simple landing page. My prompt was something along `Very dark grainy background with centered "name of the page" text.`. It couldn't get neither the background, nor th…

[flagged]

Re: “Vibe Coding” vs. Reality

#220
post #197

Over the last week I tried to use a combination of Claude and OpenAI o3-mini to do a direct conversion of about 500 lines of uncommented academic modeling code from Matlab to Python. I can’t stress enough how badly these models performed. Nearly every consequential line had some variety of off by one or logic error, often very subtle. I didn’t try cursor or the more agentic systems, but I would be astounded if they p…

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.

Can you share the code it produced?
Post reply on HN