Live data from Hacker News

The problem with "vibe coding"

dylanbeattie.net

91–100 of 154 posts

Re: The problem with "vibe coding"

#91
post #75
post #65

Earlier quoted context omitted.

Hence why software developers are out of job, eventually. The day of only a few people around the factory floor to babysit the robots will come, but lets keep celebrating the day they start unloading them from the delivery trucks for installation.

I don't know whether they will be or they won't be, but 10 years from now all the employed ones will be using LLMs.

Yes, the difference, like on those factories is that instead of the 100 that were on site when the trucks arrived at the factory, there will be 10 of them left.

Re: The problem with "vibe coding"

#92
post #86

Earlier quoted context omitted.

> No, copilot is not endlessly variable. It works best with typed languages and an enterprise mindset. I don't think your assumption is true. The key factor is the corpus used to train it, and the context you fed it. I already experienced Copilot fumbling references to methods of a simple Java class, whereas it pulled off thinks like ARM templates flawlessly. You need to understand that internally LLMs do probability…

Right, but that's exactly what static typing does in most cases - it provides model with more explicit context for what it's doing. For the same reason, they tend to handle XML better than JSON - sure, both are trees, but XML is has redundancy, and that redundancy helps keep the model on the rails, so to speak. I actually wonder if the perfect LLM language would be something a lot more like COBOL - not in a sense of…

> For query languages, at least, they seem to like SQL the most of all the things I've tried, and I strongly suspect that it's the same underlying cause.

The reason they like SQL more than other query languages is primarily that their training data has orders of magnitude more of it than any other query language, and that advantage is so huge that any other possible advantage would probably have comparatively negligible effect.

Re: The problem with "vibe coding"

#93
post #91
post #75

Earlier quoted context omitted.

I don't know whether they will be or they won't be, but 10 years from now all the employed ones will be using LLMs.

Yes, the difference, like on those factories is that instead of the 100 that were on site when the trucks arrived at the factory, there will be 10 of them left.

I have a lot of uncertainty about the number of professional software developers there will be in the long run, but not about whether they'll be using LLMs.

Re: The problem with "vibe coding"

#94
post #93
post #91

Earlier quoted context omitted.

Yes, the difference, like on those factories is that instead of the 100 that were on site when the trucks arrived at the factory, there will be 10 of them left.

I have a lot of uncertainty about the number of professional software developers there will be in the long run, but not about whether they'll be using LLMs.

Yeah, but the number matters to many folks that instead being given the opportunity to use LLMs, will be queueing to get something to work on instead.

Re: The problem with "vibe coding"

#95

Earlier quoted context omitted.

Asking the LLM for something is like doing an "Ask the Audience" in Who Wants to be a Millionaire . You're basically polling the consensus answer to the question you're asking.

> You're basically polling the consensus answer to the question you're asking. That's perfectly fine, because that's what you expect from human work to begin with. From natural text like blog article or tecnical reports to software changes, all output is expected to comply with patterns we are already familiar with. Heck, look at pull requests, where you ask your audience to evaluate your work hoping to reach a conse…

You'd expect that from an average person, but not a genius in the subject. "Genius" is almost by definition a contrarian viewpoint or technique that happens to be better than the consensus or the best-known.

Re: The problem with "vibe coding"

#96
post #51

Earlier quoted context omitted.

Asking the LLM for something is like doing an "Ask the Audience" in Who Wants to be a Millionaire . You're basically polling the consensus answer to the question you're asking.

> You're basically polling the consensus answer to the question you're asking. There is nothing wrong with going with the consensus answer. Sure, you can't invent an O(N) sorting algorithm with the consensus, but LLMs can definitely write good, maintainable code. Michelin star analogy might be an exaggeration, but it can help cook a good homemade meal, possibly even better than most wannabe home cooks.

>There is nothing wrong with going with the consensus answer.

For most things, yes. But you don't hire experts to tell you what everyone else knows. You hire experts to give you the angle.

For example, an LLM trained on all AWS documentation wouldn't be super useful (possibly less useful than traditional full-text search), because what you really want to know is the things that AWS didn't write, the writing "between the lines", all the things that DynamoDB can't do.

Re: The problem with "vibe coding"

#97

One of the genuinely positive things about tools like Copilot and ChatGPT is that they empower people with minimal development experience to create their own programs. Little programs that do useful things - and that’s awesome. More power to the users. I've changed my outlook on vibe coding after seeing the results of this wholesome vibe coding: https://www.youtube.com/watch?v=4pJUXocn7aE . This guy didn't just make…

Why do you not read the article? What you are saying is just total nonsense if you had actually read the article.

>If you gave this project to experienced software developers it would be heavy on process and light on impact, take forever to make, and stupid expensive.

No, it wouldn't. Every single software developer knows how to make programs which "work well enough". This claim is totally ridiculous, it also is not a "product" in any meaningful sense.

What the article is pointing out is that you can not sell software like this. It is not a "product" at all, it is a hobby project. And you can not develop a hobby project like you would develop a commercial product.

Just think for a second what it would take to sell this.

Re: The problem with "vibe coding"

#98
post #65

One of the genuinely positive things about tools like Copilot and ChatGPT is that they empower people with minimal development experience to create their own programs. Little programs that do useful things - and that’s awesome. More power to the users. I've changed my outlook on vibe coding after seeing the results of this wholesome vibe coding: https://www.youtube.com/watch?v=4pJUXocn7aE . This guy didn't just make…

Hence why software developers are out of job, eventually. The day of only a few people around the factory floor to babysit the robots will come, but lets keep celebrating the day they start unloading them from the delivery trucks for installation.

No. Software development is here to stay, they just will not be writing much software.

Even before AI much of software development was managing overseas teams.

Re: The problem with "vibe coding"

#99
post #28

Earlier quoted context omitted.

Yeah, the most important part of that video is where he says: "it works well enough" . I think there's lots of room for this kind of bespoke software that's fundamentally unmaintainable -- and not something anyone could reasonably afford to make with professionals -- but good enough for purpose. This seems like a great, life-changing example, but it's still subject to the same thing the article is talking about. I've…

As you said, I think also the key differences between skilled and unskilled devs in the context of AI tooling are : 1°) Know how to diagnose and fix critical problems by themselves, because there will be bugs in production for which AI won't be any help 2°) Write maintainable code, AI doesn't care at all of maintainability of code while devs should (must imho) consider pasting AI code as a merge/pull request. For 2°)…

I think it's already happening. I've been using Claude a lot since 3.5. For a while, I barely bothered to check what it was doing because the code it generated tended to be fairly straightforward and usually worked on the first try. But in the last few weeks, I've started reading everything line by line again, because now it's not only often incorrect but also written in a goofy, convoluted way. AI-generated code being constantly fed back to it in a feedback loop would explain a lot, I think.

Re: The problem with "vibe coding"

#100

It’s implied that programs are personal but product code goes through peer review, checking the premise of the change as well as the implementation. When someone reviews vibe coded patches and gives feedback, what should the reviewer expect the author to do? Pass the feedback onto their agent and upload the result? That feels silly. How has code review changed in our brave, vibey new world? Are we just reviewing idea…

>When someone reviews vibe coded patches and gives feedback, what should the reviewer expect the author to do?

Quit his job or stop contributing. Nobody is helped by people blindly commiting code they don't understand.

Post reply on HN