Live data from Hacker News

Breaking the spell of vibe coding

fast.ai

231–240 of 375 posts

Re: Breaking the spell of vibe coding

#231
I don't know this feels extremely wrong I've put out more things (including open source for the first time in a long time) that I still feel proud of since at the end of the way I manually review everything and fix whatever I don't like.

But I think this only works is because I have a decade of experience in basically every field in the programming space and I had to learn it all without AI. I know exactly what I want from AI where opus 4.6 and codex 5.3 understands that and executes on it faster than I could ever write.

Re: Breaking the spell of vibe coding

#232

[flagged]

> 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…

>>How is that different from handwritten code ?

I think the point he is trying to make is that you can't outsource your thinking to a automated process and also trust it to make the right decisions at the same time.

In places where a number, fraction, or a non binary outcome is involved there is an aspect of growing the code base with time and human knowledge/failure.

You could argue that speed of writing code isn't everything, many times being correct and stable likely is more important. For eg- A banking app, doesn't have be written and shipped fast. But it has to be done right. ECG machines, money, meat space safety automation all come under this.

Re: Breaking the spell of vibe coding

#233

Earlier quoted context omitted.

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

> Sometimes, they would have a hit, but they wasted a lot of energy on dead ends. We'll see which one it is in a few months.

Common sense.

If you can use an imperfect tool, perfectly, you’ll beat people using them imperfectly. As long as the tool is imperfect, you won’t have much competition.

That’s where we are, right now. Good engineers are learning how to use klunky LLMs. They will beat out the Dunning-Kruger crew.

Once the tool becomes perfect, then that allows less-technical users into the tent, which means a much larger pool of creativity.

Re: Breaking the spell of vibe coding

#234

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

> If you're not using it now you may end up lacking preparation when it becomes more valuable How's that? If it ever gets good, it seems rather implausible that today's tool-of-the-month will turn out to be the winner.

It won’t, the state of the art is changing so quickly it is near impossible to stay on top of. Right now claude code is doing stuff for our team that was impossible with ai coding six month ago. Probably a year from now it will be something else. I think that if you are not staying on top of things though, you will discover that you should have stayed more on top of things the day you get fired.

Re: Breaking the spell of vibe coding

#235

[flagged]

> 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…

With handwritten code, the humans know what they don’t know. If you want some constants or some formula, you don’t invent or guess it, you ask the domain expert.

Re: Breaking the spell of vibe coding

#238

Earlier quoted context omitted.

> If you're not using it now you may end up lacking preparation when it becomes more valuable How's that? If it ever gets good, it seems rather implausible that today's tool-of-the-month will turn out to be the winner.

It won’t, the state of the art is changing so quickly it is near impossible to stay on top of. Right now claude code is doing stuff for our team that was impossible with ai coding six month ago. Probably a year from now it will be something else. I think that if you are not staying on top of things though, you will discover that you should have stayed more on top of things the day you get fired.

We’ll see.

I have noticed a troubling skill atrophy in some people who heavily use LLMs (this is particularly concerning because it renders them incompetent to review ‘their own’ PRs prior to submission). I’m… not keen to sign up for that for no reason, tbh.

Re: Breaking the spell of vibe coding

#239
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 have been a lead engineer for a few decades now, responsible for training teams and architecting projects. And I've been working heavily with AI.

I know how to get Claude multi-agent mode to write 2,500 lines of deeply gnarly code in 40 minutes, and I know how to get that code solid. But doing this absolutely pulls on decades on engineering skill. I read all the core code. I design key architectural constraints. I invest heavily in getting Claude to build extensive automated verification.

If I left Claude to its own devices, it would still build stuff! But with me actively in the loop, I can diagnose bad trends. I can force strategic investments in the right places at the right times. I can update policy for the agents.

If we're going to have "software factories", let's at least remember all the lessons from Toyota about continual process improvement, about quality, about andon cords and poke-yoke devices, and all the rest.

Could I build faster if I stopped reading code? Probably, for a while. But I would lose the ability to fight entropy, and entropy is the death of software. And Claude doesn't fight entropy especially well yet, not all by itself.

Re: Breaking the spell of vibe coding

#240
post #172

Earlier quoted context omitted.

Good on you! Writing assembly is a good way to understand how computers work, which can help you further up the stack.

Assembly will not help you further up the stack which is working with agents, not writing code (obsolete skill). Apparently my /s was needed

I got your poor attempt at sarcasm. I just don't think it's a good argument.

The person who understands how lower levels of abstraction work, will always run circles technically around those who don't. Besides, "AI" tools are not a higher level of abstraction, and can't be compared to compilers. Their goal is to replace all cognitive work done by humans. If you think programming is obsolete, the same will eventually happen to whatever work you're doing today with agents. In the meantime, programmers will be in demand to fix issues caused by vibe coders.

Post reply on HN