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

141–150 of 375 posts

Re: Breaking the spell of vibe coding

#141

Post by energy123 »

wavemode wrote: post #67
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…

> I think it all boils down to, which is higher risk, using AI too much, or using AI too little? This framing is exactly how lots of people in the industry are thinking about AI right now, but I think it's wrong. The way to adopt new science, new technology, new anything really, has always been that you validate it for small use cases, then expand usage from there. Test on mice, test in clinical trials, then go to ma…

We should separate doing science from adopting science.

Testing medical drugs is doing science. They test on mice because it's dangerous to test on humans, not to restrict scope to small increments. In doing science, you don't always want to be extremely cautious and incremental.

Trying to build a browser with 100 parallel agents is, in my view, doing science, more than adopting science. If they figure out that it can be done, then people will adopt it.

Trying to become a more productive engineer is adopting science, and your advice seems pretty solid here.

Re: Breaking the spell of vibe coding

#142

Post by Sateeshm »

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

Re: Breaking the spell of vibe coding

#143

Post by shinryuu »

maplethorpe wrote: post #84

I think tech journalism needs to reframe its view of slot machines if it's to have a productive conversation about AI. Not everyone who plays slot machines is worse off — some people hit the jackpot, and it changes their life. Also, the people who make the slot machines benefit greatly.

At the expense of other people. Slot machines is a negative sum game.

Re: Breaking the spell of vibe coding

#144

Post by JSR_FDED »

Twice I’ve used Claude Code for something important and complex. Stunning initial speed and time savings, all given back eventually as it became apparent that some fatally flawed assumptions were baked into the code right from the beginning.

The initial speed is exactly what the article describes, a Loss Disguised as a Win.

Re: Breaking the spell of vibe coding

#145

Post by CoinFlipSquire »

wittlesus wrote: post #126

[dead]

My gripe with "developer accepts bad code without reading it" is two fold.

1. It's turning the Engineering work into the worst form of QA. It's that quote about how I want AI to do my laundry and fold my clothes so I have time to practice art. In this scenario the LLM is doing all the art and all that's left is the doing laundry and folding it. No doubt at a severely reduced salary for all involved.

2. Where exactly is the skill to know good code from bad code supposed to come from? I hear this take a lot I don't know any serious engineer that can honestly say that they can recognize good code from bad code without spending time actually writing code. It's makes the people asking for this look like that meme comic about the dog demanding you play fetch but not take the ball away. "No code! Only review!" You don't get one without the other.

Re: Breaking the spell of vibe coding

#146

Post by CoinFlipSquire »

tjr wrote: post #12

I see AI coding as something like project management. You could delegate all of the tasks to an LLM, or you could assign some to yourself. If you keep some for yourself, there’s a possibility that you might not churn out as much code as quickly as someone delegating all programming to AI. But maybe shipping 45,000 lines a day instead of 50,000 isn’t that bad.

I can't believe we're back to using LoC as a metric for being productive again.

Re: Breaking the spell of vibe coding

#147

Post by vidarh »

AstroBen wrote: post #107
mgraczyk wrote: post #45

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

> you have to account for the fact that AI will get better rapidly that's nowhere near guaranteed

Even if the models stopped getting better today, we'd still see many years of improvements from improving harnesses and understanding of how to use them. Most people just talk to their agent, and don't e.g. use sub-agents to make the agent iterate and cross-check outcomes for example. Most people who use AI would see a drastic improvement in outcomes just by experimenting with the "/agents" command in Claude Code (and equivalent elsewhere). Much more so with a well thought out agent framework.

A simple plan -> task breakdown + test plan -> execute -> review -> revise (w/optional loops) pipeline of agents will drastically cut down on the amount of manual intervention needed, but most people jump straight to the execute step, and do that step manually, task by task while babysitting their agent.

Re: Breaking the spell of vibe coding

#148

Post by h05sz487b »

danielrhodes wrote: post #102

Articles like this amount to a straw man. People seem to think that just because it produces a bunch of code you therefore don’t need to read it or be responsible for the output. Sure you can do that, but then you are also justifying throwing away all the process and thinking that has gone into productive and safe software engineering over the last 50 years. Have tests, do code reviews, get better at spec’ing so the…

Of course people think that, because that is exactly how those agents are being sold. If you tell management that this speeds up the easy part, typing the code, they are convinced you are using it wrong. They want to save 90% of software development cost and you are telling them that’s not possible.

Re: Breaking the spell of vibe coding

#149

Post by h05sz487b »

nkmnz wrote: post #38

tl;dr - author cites a study from early 2025 which measured developer speed of “experienced open source developers” to be ~20% slower when supported by AI, while they’ve estimated to be ~20% faster. Note: the study used sonnet-3.5 and sonnet-3.7; there weren’t any agents, deep research or similar tools available. I’d like to see this study done again with: 1. juniors ans mid-level engineers 2. opus-4.6 high and codex…

> which can be facilitated by AI

I’d be thrilled if that AI could finally make one of our most annoying stakeholders test the changes they were so eager to fast track, but hey, I might be surprised.

Re: Breaking the spell of vibe coding

#150

Post by danny_codes »

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?

Exactly. If it’s so easy (which is the point) then there’s no risk at all. Just pick it up if/when it’s definitely useful.
Post reply on HN