Live data from Hacker News

Breaking the spell of vibe coding

fast.ai

371–375 of 375 posts

Re: Breaking the spell of vibe coding

#371

Earlier quoted context omitted.

I uncharitably snarked that AI lets the 0.05X programmers become 0.2X ones, but reading this stuff makes me feel like I was too charitable. I've never had problems with any of those things after I learned what a code editor was.

Yep, it may be an issue in notepad, which does not have helper like syntax highlighting, auto indent, and line numbers. But I started with IDLE which has all those things. So my next editor was notepad++ and codeblock.

emacs + adhd. the squiggly lines and autocomplete stuff were more distracting than linter/compile errors. rock and a hard place, and ai solved it.

Re: Breaking the spell of vibe coding

#372
post #54

Earlier quoted context omitted.

> knowing how to use ai coding assistants productively is a skill like any other No, it's different from other skills in several ways. For one, the difficulty of this skill is largely overstated. All it requires is basic natural language reading and writing, the ability to organize work and issue clear instructions, and some relatively simple technical knowledge about managing context effectively, knowing which tool…

> The fact that millions of people are now using them, with varying degrees of success for various reasons, is a testament of this. I do agree with you that by design this new tool lowers the bar to entry etc. But I just want to state the obvious: billions of kids are playing with a ball; it's not that hard. Yet far less people are good soccer players. > The goal is to replace all cognitive work. Just because this is…

> billions of kids are playing with a ball; it's not that hard. Yet far less people are good soccer players.

I agree, but I don't see how that negates what I said.

Following your analogy, what's currently happening is that kids playing with a ball are now allowed to play in the major leagues. Good soccer players still exist, and their performance has arguably improved as well, but kids are now entering spaces that were previously inaccessible to them. This can be seen as both a good or a bad thing, but I would argue that it will mostly have bad consequences for everyone involved, including the kids.

> The question is: do you benefit from using it or not? can you build faster or better by applying these tools in the appropriate way or should you just ignore it and keep doing things the way things used to be done up until a few months ago?

That's a false dichotomy. I would say that the answer is somewhere in the middle.

These new tools can assist with many tasks, but I'm still undecided whether they're a net long-term benefit. On one hand, sure, they enable me to get to the end result quicker. On the other, I have less understanding of the end result, hence I can't troubleshoot any issues, fix any bugs, or implement new features without also relying on the tool for this work. This ultimately leads to an atrophy of my skills, and a reliance on tools that are out of my control. Even worse: since the tools are far from reliable yet, they provide a false sense of security.

But I also don't think it's wise to completely ignore this technology, and continue working as it didn't exist.

So at this point, the smartest approach to me is conservative adoption. Use vibe coding for things that you don't care about, that won't be published, and will only be used by yourself. Use assisted coding in projects that might be published and have other users, but take time and effort to guide the tool, and understand and review the generated code. Use classical programming for projects you care about, critical software, or when you want to actually learn and improve your skills.

I doubt this approach will be adopted by many, and that's the concerning part, since the software they produce will inevitably be forced on the rest of us.

What's really surprising to me is how many experienced programmers are singing the praises of this new way of working. How what they really enjoy is "building", but find the classical process of "building" tedious. This goes against most of the reasons I got into and enjoy working in this industry to begin with. Delivering working software is, of course, the end goal. But the process itself, pushing electrons to arrange bits in a useful configuration, in a way that is interesting, performant, elegant, or even poetic, learning new ways of doing that and collaborating with like-minded people... all of that is why I enjoy doing this. A tool that replaces that with natural language interactions, that produces the end result by regurgitating stolen data patterns in configurations that are sometimes useful, and that robs me from the process of learning, is far removed from what I enjoy doing.

Re: Breaking the spell of vibe coding

#373
post #370

Earlier quoted context omitted.

Actually the opposite is the case. UI design was best when designers were systematic in their approach, employing concepts from human psychology and rigorously testing and timing how long it took to perform actions on the computer, optimizing for efficiency, discoverability, and ease of use. Today's UI designers copy from designs they've seen before, often poorly, and when they do apply data and metrics it's to bulls…

I'm talking the sort of tools you open where its like a giant anime cat lady on a background and a couple buttons to just run some functions or other scripts behind the scenes. Where the venn diagram of the person writing the software, understanding the problem, and understanding how people expected it to be solved overlapped perfectly. Tools for tool users by fellow tool users. Like all those little bespoke self mad…

I get it now. The king of this school of thought:

https://m.youtube.com/watch?v=Ra25c8-3I6w

It's a bit unusual to describe a disk utility's UI as absolute kino, but it fits for X-Copy. To understand X-Copy is to understand the Amiga.

Re: Breaking the spell of vibe coding

#374
50 years writing software. I use AI heavily — it collapsed my build cost by 40-60x and I run 56 microservices as a solo founder. But I read every line. I design every boundary. AI is the best junior engineer I've ever worked with, and like every junior engineer, it needs supervision. The problem isn't the tool — it's people skipping the decades of judgment that tell you when the tool is wrong.

Re: Breaking the spell of vibe coding

#375
Great discussion. I've been building in this space and think the truth is somewhere in the middle.

The real value isn't in "vibe coding" everything from scratch - it's in having the right architecture and patterns that AI can work within. That's why I built VCSK (Vibe Coding Starter Kit) - it gives you a solid NextJS foundation with proven patterns, then you can vibe code features on top of that foundation.

The difference is architectural discipline. When you start with proper auth, DB setup, deployment pipeline, and component structure, AI becomes incredibly productive for building features. When you ask AI to architect everything from scratch, you get the dead-end architectures you mentioned.

I still write the critical business logic by hand, still review every PR, and still understand the codebase deeply. But for UI components, API endpoints that follow established patterns, and data transformations? AI is genuinely faster than manual coding now.

The key insight: "vibe coding" isn't a replacement for engineering judgment - it's a force multiplier when you have the foundation right.

Post reply on HN