Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking the spell of vibe coding

fast.ai

Post reply on HN
Print view View original

361–370 of 375 posts

Re: Breaking the spell of vibe coding

#361

Post by shaky-carrousel »

mprast wrote: post #53
daxfohl wrote: 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?

It's like some companies with huge interests are spreading FOMO, isn't it?

Re: Breaking the spell of vibe coding

#362

Post by ozozozd »

nkmnz wrote: post #183
jph00 wrote: post #68

Earlier quoted context omitted.

> I don’t know how to trust the author if stuff like this is wrong. She's not wrong. A good way to do this calculation is with the log-ratio, a centered measure of proportional difference. It's symmetric, and widely used in economics and statistics for exactly this reason. I.e: ln⁡(1.2/0.81) = ln⁡(1.2)-ln⁡(0.81) ≈ 0.393 That's nearly 40%, as the post says.

so if the numbers were “99% slower than without AI but they thought they would be 99% fast”, you’d call that “they were 529% slower”, even though it doesn’t make sense to be more than 100% slower? And you’d not only expect everyone to understand that, but you really think it’s more likely a random person on the internet used a logarithmic scale than they just did bad math?

Well, this random person we are referring to happens to have a PhD in math from Duke.

I find that satisfying.

Re: Breaking the spell of vibe coding

#363

Post by ithkuil »

imiric wrote: post #54
ithkuil wrote: 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

> 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 not entirely possible today, doesn't mean that it won't be tomorrow. > [..] > I'm of the opinion that this goal is unachievable with the current tech generatiom > [..] > In the meantime, your own skills will continue to atrophy the more you rely on this tech [..]

Here I don't quite follow.

I agree that if this tech is ready to completely replace you, you won't need to use your brain. But provided it is not there yet (like, at all), your intellect is needed quite a lot to get out of it anything more than toys.

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?

This is a legit question.

My point is: in order to anwswer this question I cannot base my intuition only on some vague first principles on what this tech stack ought to be able to do, or what other people say it's able to do, or what I suspect it will never be able to do: I need to touch it, to learn how to use it, just like every other tool. That's the only way I can truly get a sensible answer. And like any other skill, I'm fully aware that I can't devote just a few minutes trying it out and then reaching any conclusion.

EDIT: I do share a general concern about how new generations are going to achieve the full-picture understanding if they get exposed to these tools as the main approach towards software production. I come to this after a long career in system programming, so I don't personally see this as a threat to atrophy my own skills; but I do share a quite undefined sense of concern about where this is going

Re: Breaking the spell of vibe coding

#364

Post by manmal »

failingforward wrote: post #291
manmal wrote: post #283

Earlier quoted context omitted.

> A hallucinated edge case in a tax calculation doesn't throw an error. Would double entry book keeping not catch this?

Not necessarily. Double entry bookkeeping catches errors in cases where an amount posted to one account does not have an equally offsetting post in another account or accounts (i.e., it catches errors when the books do not balance). It would not on its own catch errors where the original posted amount is incorrect due to a mistaken assumption, or if the offset balances but is allocated incorrectly.

Well the other ledgers are usually based off other data sources, so there is cross checking no?

Re: Breaking the spell of vibe coding

#365

Post by michaelcampbell »

Fellshard wrote: post #257
michaelcampbell wrote: post #242

Earlier quoted context omitted.

> With handwritten code, the humans know what they don’t know. I find this often not to be the case at all.

Let's put it this way: the human author is capable of doing so. The LLM is not. You can cultivate the human to learn to think in this way. You can for a brief period coerce an LLM to do so.

True, but IMO irrelevant. "What could have been" (capabilities) is just another "if only..."

Re: Breaking the spell of vibe coding

#366

Post by fnordpiglet »

ncruces wrote: post #59
fnordpiglet wrote: post #9

Earlier quoted context omitted.

Fascinating - I find the opposite is true. I think of edge cases more and direct the exploration of them. I’ve found my 35 years experience tells me where the gaps will be and I’m usually right. I’ve been able to build much more complex software than before not because I didn’t know how but because as one person I couldn’t possibly do it. The process isn’t any easier just faster. I’ve found also AI assisted stuff is…

> I’ve found also AI assisted stuff is remarkable for algorithmically complex things to implement. AI is really good to rubber duck through a problem. The LLM has heard of everything … but learned nothing. It also doesn't really care about your problem. So, you can definitely learn from it. But the moment it creates something you don't understand, you've lost control. You had one job.

If you’ve worked on a code base built by more than you, you don’t understand and you don’t have control. Part of being an experienced engineer is understanding how to deal with that effectively at scale.

Re: Breaking the spell of vibe coding

#367

Post by wmeredith »

ryan_n wrote: post #244
rafaelmn wrote: post #221

Earlier quoted context omitted.

> Vibe coding would be catastrophic here. Not because the AI can't write the code - it usually can - but because the failure mode is invisible. A hallucinated edge case in a tax calculation doesn't throw an error. It just produces a slightly wrong number that gets posted to a real accounting platform and nobody notices until the accountant does their review. How is that different from handwritten code ? Sounds like s…

It’s shocking to me that people even ask this type of question. How do you not see the difference between a machine that will hallucinate something random if it doesn’t know the answer vs a human that will logic through things and find the correct answer.

> How do you not see the difference between a machine that will hallucinate something random if it doesn’t know the answer vs a human that will logic through things and find the correct answer.

I see this argument over and over agin when it comes to LLMs and vibe coding. I find it a laughable one having worked in software for 20 years. I am 100% certain the humans are just as capable if not better than LLMs at generating spaghetti code, bugs, and nonsensical errors.

Re: Breaking the spell of vibe coding

#368

Post by linsomniac »

kaffekaka wrote: post #342
linsomniac wrote: post #325

Earlier quoted context omitted.

>What is there to learn, honestly? With all due respect, that answer shows that you don't know enough about agentic coding to form an opinion on this. Things to learn: - What agent are you going to use? - What skills are you going to use? - What MCPs are you going to use? - What artifacts are you going to provide beyond the prompt? - How are you going to structure it so the tooling can succeed without human interacti…

To me it seems you and many others are lost in the weeds of constantly evolving tooling and strategies. A pretty basic Claude Code or Codex setup and being mindful of context handling goes a long way. Definitely long enough to be able to use AI productively while not spending much time on configuring the setup. Staying on top of all details is not necessary but in fact counter productive, trust me.

I don't need to trust you, I've done my own testing and using newer tooling features is dramatically better than not. One of the things about the AI tooling is that it's very inexpensive to run experiments (this week I've had it build a particular tool in Python, Go, Rust, and Zig, for example).

Using skills, multiple models, MCPs and agent teams is significantly improving the results I'm seeing in real world problems.

You haven't really given me any reason why I should trust you, but I'll tell you it's going to be hard for me to trust advice that contradicts my test results.

Re: Breaking the spell of vibe coding

#369

Post by heromal »

fragmede wrote: post #132
holoduke wrote: post #124

Earlier quoted context omitted.

Nothing gets worse in computers. Name me one thing. And if the current output quality of LLM stays the same but speed goes up 1000, quality of the generated code can be higher.

Hot keys. Used to be, you could drive a program from the keyboard with hotkeys and macros. No mouse. The function keys did functions. You could drive the interface blindfolded, once you learned it. Speed is another one. Why does VSCode take so long to open? and use so much memory and CPU? it's got a lot of features for a text editor, but it's worse than vim/emacs in a lot of ways. Boot time. Understandability. A Z80…

Native GUI libs look like shit out of the box, and are terrible to work with when you want to make something that doesn't look like out of the box tkinter/swing/qt/winforms Windows 95 looking crap.

Re: Breaking the spell of vibe coding

#370

Post by asdff »

bitwize wrote: post #360
asdff wrote: post #340

Earlier quoted context omitted.

The irony considering "good" ui to a ui designer is completely at odds with users. We got better ui when it was people who had no clue what they were doing just trying to make some sense out of it, vs the cult of dogmatic ui design we see today where everything follows the same crappy patterns and everyone is afraid to step out of line.

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 made gizmos in my grandpa's old toolboxes.
Post reply on HN