Live data from Hacker News

Breaking the spell of vibe coding

fast.ai

81–90 of 375 posts

Re: Breaking the spell of vibe coding

#81
post #7

I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astound…

> I think it all boils down to, which is higher risk, using AI too much, or using AI too little?

It's both. It's using the AI too much to code, and too little to write detailed plans of what you're going to code. The planning stage is by far the easiest to fix if the AI goes off track (it's just writing some notes in plain English) so there is a slot-machine-like intermittent reinforcement to it ("will it get everything right with one shot?") but it's quite benign by comparison with trying to audit and fix slop code.

Re: Breaking the spell of vibe coding

#82
post #7

I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astound…

Even if you believe that many are too far on one side now, you have to account for the fact that AI will get better rapidly. If you're not using it now you may end up lacking preparation when it becomes more valuable

Why should I worry about lacking preparation in the future? Why can't I just learn this as any other skill at any other time?

Re: Breaking the spell of vibe coding

#83
post #62

Earlier quoted context omitted.

But as it gets better, it'll also get easier, be built into existing products you already use, etc. So I wouldn't worry too much about that aspect. If you enjoy tinkering, or really want to dive deep into fundamentals, that's one thing, but I wouldn't worry too much about "learning to use some tool", as fast as things are changing.

I don't think so. That's a good point but the capability has been outpacing people's ability to use it for a while and that will continue. Put another way, the ability to use AI became an important factor in overall software engineering ability this year, and as the year goes on the gap between the best and worst users or AI will widen faster because the models will outpace the harnesses

I mean, right now "bleeding edge" is an autonomous agents system that spends a million dollars making an unbelievably bad browser prototype in a week. Very high effort and the results are jibberish. By the time these sorts of things are actually reliable, they'll be productized single-click installer apps on your network server, with a simple web interface to manage them.

If you just mean, "hey you should learn to use the latest version of Claude Code", sure.

Re: Breaking the spell of vibe coding

#84
I think tech journalism needs to reframe its view of slot machines if it's to have a productive conversation about AI.

Not everyone who plays slot machines is worse off — some people hit the jackpot, and it changes their life. Also, the people who make the slot machines benefit greatly.

Re: Breaking the spell of vibe coding

#85
post #53
post #7

I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astound…

It's very interesting to me how many people presume that if you don't learn how to vibecode now you'll never ever be able to catch up. If the models are constantly getting better, won't these tools be easier to use a year from now? Will model improvements not obviate all the byzantine prompting strategies we have to use today?

FOMO is hell of a drug.

Re: Breaking the spell of vibe coding

#86
post #82

Earlier quoted context omitted.

Even if you believe that many are too far on one side now, you have to account for the fact that AI will get better rapidly. If you're not using it now you may end up lacking preparation when it becomes more valuable

Why should I worry about lacking preparation in the future? Why can't I just learn this as any other skill at any other time?

You'll be behind by a few months at least, and that could be anywhere from slightly harmful to devasting to your career

Re: Breaking the spell of vibe coding

#87

[flagged]

> LLMs are good at writing individual functions but terrible at deciding which functions should exist.

Have you tried explicitly asking them about the latter? If you just tell them to code, they aren't going to work on figuring out the software engineering part: it's not part of the goal that was directly reinforced by the prompt. They aren't really all that smart.

Re: Breaking the spell of vibe coding

#88
post #83

Earlier quoted context omitted.

I don't think so. That's a good point but the capability has been outpacing people's ability to use it for a while and that will continue. Put another way, the ability to use AI became an important factor in overall software engineering ability this year, and as the year goes on the gap between the best and worst users or AI will widen faster because the models will outpace the harnesses

I mean, right now "bleeding edge" is an autonomous agents system that spends a million dollars making an unbelievably bad browser prototype in a week. Very high effort and the results are jibberish. By the time these sorts of things are actually reliable, they'll be productized single-click installer apps on your network server, with a simple web interface to manage them. If you just mean, "hey you should learn to us…

I mean that you should stay up to date and practiced on how to get the most out of models. Using harnesses like Claude code sure, but also knowing their strengths and weaknesses so you can learn when and how to delegate and take on more scope

Re: Breaking the spell of vibe coding

#89
post #7

I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astound…

> I think it all boils down to, which is higher risk, using AI too much, or using AI too little? This framing is exactly how lots of people in the industry are thinking about AI right now, but I think it's wrong. The way to adopt new science, new technology, new anything really, has always been that you validate it for small use cases, then expand usage from there. Test on mice, test in clinical trials, then go to ma…

> Test on mice, test in clinical trials, then go to market.

You're neglecting the cost of testing and validation. This is the part that's quite famous for being extremely expensive and a major barrier to developing new therapies.

Re: Breaking the spell of vibe coding

#90
post #22
post #11

Earlier quoted context omitted.

On the using AI assistants I find that everything is moving so fast that I feel constantly like "I'm doing this wrong". Is the answer simply "dedicate time to experimenting? I keep hearing "spec driven design" or "Ralph" maybe I should learn those? Genuine thoughts and questions btw.

More specifically regarding spec-driven development: There's a good reason that most successful examples of those tools like openspec are to-do apps etc. As soon as the project grows to 'relevant' size of complexity, maintaining specs is just as hard as whatever other methodology offers. Also from my brief attempts - similar to human based coding, we actually do quite well with incomplete specs. So do agents, but the…

> if you nail everything down hard, the specs get unwieldy - large and overly detailed

That's a rather short-sighted way of putting it. There's no way that the spec is anywhere as unwieldly as the actual code, and the more details, the better. If it gets too large, work on splitting a self-contained subset of it to a separate document.

Post reply on HN