Live data from Hacker News

Breaking the spell of vibe coding

fast.ai

211–220 of 375 posts

Re: Breaking the spell of vibe coding

#211
post #53

Earlier quoted context omitted.

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?

It's hilarious. The whole point of "vibe coding" is that you don't need to learn or know anything. It's like saying if you don't learn to use a smartphone you'll be left behind. Even babies can use it now.

I do think there's value in trying out fully vibe coding some toy projects today (probably nothing real or security sensitive haha).

The AI will get better at compensating, but I think some of it's weaknesses are fundamental, and are going to be showing up in some form or another for a while yet

Ex, the AI doesn't know about what you don't tell it. There's a LOT of context we take for granted while programming (especially in a corporate environment). Recognizing what sort of context is useful to give the AI without distracting it (and under what conditions it should load/forget context), I think is going to be a very valuable skill over the next few years. That's a skill you can start building now

Re: Breaking the spell of vibe coding

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

A good analogy might be synthesized music.

In the early days, the interfaces were so complex and technical, that only engineers could use them.

Some of these early musicians were truly amazing individuals; real renaissance people. They understood the theory, and had true artistic vision. The knew how to ride the tiger, and could develop great music, fairly efficiently.

A lot of others, not so much. They twiddled knobs at random, and spent a lot of effort, panning for gold dust. Sometimes, they would have a hit, but they wasted a lot of energy on dead ends.

Once the UI improved (like the release of the Korg M1 sampler), then real artists could enter the fray, and that’s when the hockey stick bent.

Not exactly sure what AI’s Korg M1 will be, but I don’t think we’re there, yet.

Re: Breaking the spell of vibe coding

#213

I think most of the issues with "vibe coding" is trusting the current level of LLM's with too much, as writing a hacky demo of a specific functionality is 1/10 as difficult as making a fully-fledged, dependable, scalable version of it. Back in 2020, GPT-3 could code functional HTML from a text description, however it's only around now that AI can one-shot functional websites. Likewise, AI can one-shot a functional de…

Of course - and autonomous driving is 1 year away.

As an aside, I wonder if automated driving would be one year away if we did not need to worry about it killing people.

Like if the only possible issues were property damage, I kind of think it would be here. You just insure the edge cases.

Re: Breaking the spell of vibe coding

#214
post #99

Earlier quoted context omitted.

The baseline, out-of-the-box basic tool level will lift, but so will the more obscure esoteric high-level tools that the better programmers will learn to control, further separating themselves in ability from the people who wait for the lowest common denominator to do their job for them.

Maybe. But so far ime most of the esoteric tools in the AI space are esoteric because they're not very good. When something gets good, it's quickly commoditized. Until coding systems are truly at human-replacement level, I think I'd always prefer to hire an engineer with strong manual coding skills than one who specializes in vibe coding. It's far easier to teach AI tools to a good coder than to teach coding discipli…

I wonder if psychology plays a role here. An engineer with strong manual coding skills might be hesitant to admit that a tool has become good enough to warrant less involvement.

Re: Breaking the spell of vibe coding

#216
post #53

Earlier quoted context omitted.

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?

A good analogy might be synthesized music. In the early days, the interfaces were so complex and technical, that only engineers could use them. Some of these early musicians were truly amazing individuals; real renaissance people. They understood the theory, and had true artistic vision. The knew how to ride the tiger, and could develop great music, fairly efficiently. A lot of others, not so much. They twiddled knob…

I think we are. I'm helping somebody who has a non-technical background and taught himself how to vibe code and built a thing. The code is split into two GitHub repos when it should have been one, and one of the repos is named hetzner-something because that's what he's using and he "doesn't really understand tech shit"

Re: Breaking the spell of vibe coding

#217

Earlier quoted context omitted.

A good analogy might be synthesized music. In the early days, the interfaces were so complex and technical, that only engineers could use them. Some of these early musicians were truly amazing individuals; real renaissance people. They understood the theory, and had true artistic vision. The knew how to ride the tiger, and could develop great music, fairly efficiently. A lot of others, not so much. They twiddled knob…

I think we are. I'm helping somebody who has a non-technical background and taught himself how to vibe code and built a thing. The code is split into two GitHub repos when it should have been one, and one of the repos is named hetzner-something because that's what he's using and he "doesn't really understand tech shit"

That sounds a lot like “twiddling knobs at random,” to me.

Re: Breaking the spell of vibe coding

#218

Earlier quoted context omitted.

It's hilarious. The whole point of "vibe coding" is that you don't need to learn or know anything. It's like saying if you don't learn to use a smartphone you'll be left behind. Even babies can use it now.

That's another dumb thing that unfortunately some people can be led to believe. There have been parents who genuinely thought that screen time would make their kids digitally savvy and prepared for the future.

It has worked out quite well for some of them, but there's a lot of devil in the details of the implementation of that screentime that led to eg Mark Zuckerberg vs Markiplier.

Re: Breaking the spell of vibe coding

#220
> However, it is important to ask if you want to stop investing in your own skills because of a speculative prediction made by an AI researcher or tech CEO. Consider the case where you don’t grow your software engineering or problem-solving skills, yet the forecasts of AI coding agents being able to handle ever expanding complexity don’t come to pass. Where does this leave you?

The current Claude Code setup with Opus 4.6 and their Max subscription (the 100 USD one was enough for me, don't need the 200 USD one) was enough for me to do large scale refactoring across 3 codebases in parallel. Maybe not the most innovative or complex tasks in absolute terms, but it successfully did in one day what would have taken regular developers somewhere between 1 and 2 weeks in total.

I hate to be the anecdote guy, but with the current state of things, I have to call bullshit on the METR study, there is no world in which I work slower with AI than without. Maybe with the Cerebras Code subscription where it fucked some code up and I had to go back to it and fix it twice, but that's also because Vue had some component wrapping and SFC/TypeScript bullshit going on which was honestly disgusting to work on, but that's because you really need the SOTA models. The current ones are good enough for me even if they never improved further.

I never want to go back to soul sucking boilerplate or manual refactoring. It works better than I can alone. It works better than my colleagues can. I think I might just suck, maybe I'm cooked because at this point I mostly just guide and check it and sometimes do small code examples for what I want and explore problems instead of writing all of it myself, but honestly a lot of work was done in JetBrains IDEs previously where there's also lots of helpful snippets, autocomplete, code inspections and so on, so who knows - maybe it doesn't matter that I write everything line by line myself.

Post reply on HN