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

201–210 of 375 posts

Re: Breaking the spell of vibe coding

#201

Post by svantana »

retsibsi wrote: post #158
mprast wrote: 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?

I think the AI-coding skill that is likely to remain useful is the ability (and discipline) to review and genuinely understand the code produced by the AI before committing it. I don't have that skill; I find that if I'm using AI, I'm strongly drawn toward the lazy approach. At the moment, the only way for me to actually understand the code I'm producing is to write it all myself. (That puts my brain into an active c…

Don't you think automated evaluation and testing of code is likely to improve at an equally breakneck pace? It doesn't seem very far-fetched to soon have a simulated human that understands software from a user perspective.

Re: Breaking the spell of vibe coding

#202

Post by wedog6 »

mgraczyk wrote: post #63
daxfohl wrote: post #62

Earlier quoted context omitted.

But as it gets better, it'll also get easier, be built into existing products you already use, etc. So I wouldn't worry too much about that aspect. If you enjoy tinkering, or really want to dive deep into fundamentals, that's one thing, but I wouldn't worry too much about "learning to use some tool", as fast as things are changing.

I don't think so. That's a good point but the capability has been outpacing people's ability to use it for a while and that will continue. Put another way, the ability to use AI became an important factor in overall software engineering ability this year, and as the year goes on the gap between the best and worst users or AI will widen faster because the models will outpace the harnesses

I mean if the capacity has outpaced people's ability to use it, to me that's a good sign that a lot of the future improvements will be making it easier to use.

Re: Breaking the spell of vibe coding

#203

Post by svantana »

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…

There is also opportunity cost. Most people ignore most things because there are simply not enough hours in a day.

Re: Breaking the spell of vibe coding

#204

Post by mdavid626 »

atleastoptimal wrote: post #50

I think most of the issues with "vibe coding" is trusting the current level of LLM's with too much, as writing a hacky demo of a specific functionality is 1/10 as difficult as making a fully-fledged, dependable, scalable version of it. Back in 2020, GPT-3 could code functional HTML from a text description, however it's only around now that AI can one-shot functional websites. Likewise, AI can one-shot a functional de…

Of course - and autonomous driving is 1 year away.

Re: Breaking the spell of vibe coding

#205

Post by charcircuit »

karmakurtisaani wrote: post #192
charcircuit wrote: post #109

Earlier quoted context omitted.

Every company should have hired over the pandemic due to there being a higher EV than not hiring. It's like if someone offered an opportunity to pay $1000 for a 50% chance to make $8000, where the outcome is the same between everyone taking the offer. If you are maximizing for the long term everyone should take the offer even if it does result in a reality where everyone loses $1000.

Where did they get the notion that the EV of overhiring was high by any measure?

There is a reality where the COVID boost tech companies had would persist after COVID is over. The small chance of such a future raised the EV.

Re: Breaking the spell of vibe coding

#206

Post by mdavid626 »

atleastoptimal wrote: post #44

That AI would be writing 90% of the code at Anthropic was not a "failed prediction". If we take Anthropic's word for it, now their agents are writing 100% of the code: https://fortune.com/2026/01/29/100-percent-of-code-at-anthro... Of course you can choose to believe that this is a lie and that Anthropic is hyping their own models, but it's impossible to deny the enormous revenue that the company is generating via th…

Why do they have so many GitHub issues then?

Re: Breaking the spell of vibe coding

#208

Post by slopinthebag »

atleastoptimal wrote: post #165
slopinthebag wrote: post #120

Earlier quoted context omitted.

It's not entirely surprising. You can prompt the AI to write code to pretty much any level of detail. You can tell it exactly what to output and it will copy character for character. Of course at a certain point, you have to wonder if it would be faster to just type it than to type the prompt. Anyways, if this was true in the sense they are trying to imply, why does Boris still have a job? If the agents are already d…

They probably still need to be able to read and distinguish good vs bad code, evaluate agent decisions, data structures, feasibility, architectural plans, etc, all of which require specific software engineering expertise, even if they don't end up touching the code directly.

But that doesn't make sense. They claim that AI is writing 100% of the code, yet if they need to be able to read and distinguish good vs bad code, evaluate agent decisions, data structures, feasibility, architectural plans, etc, that implies they are writing at least some of the code? Or else why would they ever need to do those things?

Re: Breaking the spell of vibe coding

#209

Post by Kiro »

atleastoptimal wrote: post #44

That AI would be writing 90% of the code at Anthropic was not a "failed prediction". If we take Anthropic's word for it, now their agents are writing 100% of the code: https://fortune.com/2026/01/29/100-percent-of-code-at-anthro... Of course you can choose to believe that this is a lie and that Anthropic is hyping their own models, but it's impossible to deny the enormous revenue that the company is generating via th…

Exactly. The fact that people laugh at the prediction like it's a joke when I and many others have been at 90%+ for a long time makes me question a lot of the takes here. Anyone serious about using LLMs would know it's nothing controversial to have it write most of the code.

And people claiming it's a lie are in for a rough awakening. I'm sure we will see a lot of posters on HN simply being too embarrassed to ever post again when they realize how off they were.

Re: Breaking the spell of vibe coding

#210

Post by JanneVee »

My little anecdote of breaking the spell. Really I might not been truly under the spell, but I had to go far in to my project to loose the "magic" of the code. The trick was simply going back to a slower way of using it with a regular chat window. Then really reading the code and interrogation everything that looks odd. In my case I saw a .partial_cmp(a).unwrap() in my rust code and went ahead an asked is there an alternative. The LLM returned .total_cmp(a) as an alternative. I continued on asking why it generated the "ugly" unwrap, LLM returned that it didn't become available later version of rust with only a tiny hint of that it .partial_cmp is more common in the original trainingsets. The final shattering was simply asking it why it used .partial_cmp and got back "A developer like me... ". No it is an LLM, there is somewhere in the system prompt to anthropomorphize the responses and that is the subtle trick beyond "skinner box" of pulling the lever hoping to get useful output. There are a bunch of subtle cues that hijacks the brain of treating the LLM like a human developer. So when going back to the agentic flow in my other projects I try to disabling these tricks in my prompts and the AGENTS file and the results are more useful and I'm more prone to realizing when the output has sometimes has outdated constructs and be more specific on what version of tooling I'm using. Occasionally scraping whole branches when I realize that it is just outdated practices or simply a bad way of doing things that are simply more common in the original training data, restarting with the more correct approaches. Is it a game changer... no but it makes it more like a tool that I use instead of a developer of shifting experience level.
Post reply on HN