Earlier quoted context omitted.
Isn't the study a year old by now? Things have evolved very quickly in the last few months.
Yes. No agents, no deep research, no tools, and just Sonnet-3.5 and 3.7 - I’d love to see the same study today with Opus-4.6 and Codex-5.3
Breaking the spell of vibe coding
121–130 of 375 posts
Re: Breaking the spell of vibe coding
#122I 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?
Re: Breaking the spell of vibe coding
#123i used to lose hours each day to typos, linting issues, bracket-instead-of-curly-bracket, 'was it the first parameter or the second parameter', looking up accumulator/anonymous function callback syntax AGAIN... idk what ya'll are doing with AI, and i dont really care. i can finally - fiiinally - stay focused on the problem im trying to solve for more than 5 minutes.
Re: Breaking the spell of vibe coding
#124Earlier 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
Re: Breaking the spell of vibe coding
#125I 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?
Until then, I keep up and add my voice to the growing number who oppose this clear threat on worker rights. And when the bubble pops or when work mandates it, I can catch up in a week or two easy peasy. This shit is not hard, it is literally designed to be easy. In fact, everything I learn the old way between now and then will only add to the things I can leverage when I find myself using these things in the future.
Re: Breaking the spell of vibe coding
#126Re: Breaking the spell of vibe coding
#127I use AI for the mundane parts, for brainstorming bugs. It is actually more consistent than me in covering corner cases, making sure guard conditions exist etc. So I now focus more on design/architecture and what to build and not minutea.
Re: Breaking the spell of vibe coding
#128It's astonishing to me that real software developers have considered it a good idea to generate code... and not even look at the code . I would have thought sanity checking the output to be the most elementary next step.
A lot of the time the issue isn't actually the code itself but larger architectural patterns. But realizing this takes a lot of mental work. Checking out and just accepting what exists, is a lot easier but misses subtleties that are important.
Re: Breaking the spell of vibe coding
#129Everyone seems to have different ways to deal with AI for coding and have different experiences. But Armin's comment quoted in the article is spot on. I have seen a friend do exactly the same thing, vibe coded an entire product hooked to Cursor over three months. Filled with features no one uses, feeling very good about everything he built. Ultimately it's his time and money, but I would never want this in my company…
Re: Breaking the spell of vibe coding
#130> A study from METR found that when developers used AI tools, they estimated that they were working 20% faster, yet in reality they worked 19% slower. That is nearly a 40% difference between perceived and actual times! It’s not. It’s either 33% slower than perceived or perception overestimates speed by 50%. I don’t know how to trust the author if stuff like this is wrong.
Isn't the study a year old by now? Things have evolved very quickly in the last few months.
Still an interesting observation. It was also on brown field open source projects which imo explains a bit why people building new stuff have vastly different experiences than this.