Live data from Hacker News

Breaking the spell of vibe coding

fast.ai

21–30 of 375 posts

Re: Breaking the spell of vibe coding

#21
post #16
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…

Very reasonable take. The fact that this is being downvoted really shows how poor HN's collective critical thinking has become. Silicon Valley is cannibalizing itself and it's pretty funny to watch from the outside with a clear head.

I think it's like the California gold rush. Anybody and their brother can go out and dig, but the real money is in selling the shovels.

Re: Breaking the spell of vibe coding

#22
post #11
post #8

Earlier quoted context omitted.

I personally found out that knowing how to use ai coding assistants productively is a skill like any other and a) it requires a significant investment of time b) can be quite rewarding to learn just as any other skill c) might be useful now or in the future and d) doesn't negate the usefulness of any other skills acquired on the past nor diminishes the usefulness of learning new skills in the future

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 they'll shrug at all the implicit things much more than humans do. So you'll see more flip-flopped things you did not specify, and if you nail everything down hard, the specs get unwieldy - large and overly detailed.

Re: Breaking the spell of vibe coding

#23

"they don’t produce useful layers of abstraction nor meaningful modularization. They don’t value conciseness or improving organization in a large code base. We have automated coding, but not software engineering" Which frankly describes pretty much all real world commercial software projects I've been on, too. Software engineering hasn't happened yet. Agents produce big balls of mud because we do, too.

which is why the most famous book in the world of software development pointed out that the long term success of a software project is not defined by man hours or lines of code written but by documentation, clear interfaces and the capacity to manage the complexity of a project.

Maybe they need to start handing out copies of the mythical man month again because people seem to be oblivious to insights we already had a few decades ago

Re: Breaking the spell of vibe coding

#25
post #3

> 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. I don't think these are exclusive. Almost a year ago, I wrote a blog post about this [0]. I spent the time since then both learning better software design and learning to vibe code. I've worked through Domain-Driven Design Distilled , Domain-Driven Design , Imple…

As someone with 20 years experience, DDD is a stupid idea, skip it and do yourself a favour. You'll probably be forming some counter-arguments in your head. Skip them, throw the DDD books in the bin, and do your co-workers a favour.

Agreed. I find most design patterns end up as a mess eventually, at least when followed religiously. DDD being one of the big offenders. They all seem to converge on the same type of "over engineered spaghetti" that LOOKS well factored at a glance, but is incredibly hard to understand or debug in practice.

Re: Breaking the spell of vibe coding

#27
i used to lose hours each day to typos, linting issues, bracket-instead-of-curly-bracket, 'was it the first parameter or the second parameter', looking up accumulator/anonymous function callback syntax AGAIN...

idk what ya'll are doing with AI, and i dont really care. i can finally - fiiinally - stay focused on the problem im trying to solve for more than 5 minutes.

Re: Breaking the spell of vibe coding

#28
The addiction aspect of this is real. I was skeptical at first, but this past week I built three apps and experienced issues with stepping away or getting enough sleep. Eventually my discipline kicked in to make this a more healthy habit, but I was surprised by how compelling it is to turn ideas into working prototypes instantly. Ironically, the rate limits on my Claude and Codex subscriptions helped me to pace myself.

Re: Breaking the spell of vibe coding

#29

i used to lose hours each day to typos, linting issues, bracket-instead-of-curly-bracket, 'was it the first parameter or the second parameter', looking up accumulator/anonymous function callback syntax AGAIN... idk what ya'll are doing with AI, and i dont really care. i can finally - fiiinally - stay focused on the problem im trying to solve for more than 5 minutes.

idk what you’re doing but proper IDE was doing that for me for past 15 years or more.

Like I don’t remember syntax or linting or typos being a problem since I was in high school doing Turbo Pascal or Visual Basic.

Re: Breaking the spell of vibe coding

#30
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 within AI coding how people use this varies wildly from one people trying to one shot apps to people being barely above tab completers.

When people talk about this stuff they usually mean very different techniques. And last months way of doing it goes away in favor of a new technique.

I think the best you can do now is try lots of different new ways of working keep an open mind

Post reply on HN