[flagged]
> Architecture decisions and domain knowledge are still entirely on you. The typing is faster though.
Also, it prevents repetitive strain injury. At least, it does for me.
Breaking the spell of vibe coding
181–190 of 375 posts
Re: Breaking the spell of vibe coding
#182Earlier 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 do think that there's some meta-skills involved here that are useful, in the same way that some people have good "Google-fu". Some of it is portable, some of it isn't. I think if you orient your experimentation right you can think of some good tactics that are helpful even when you're not using AI assistance. "Making this easier for the robot" can often align with "making this easier for the humans" as well. It's a…
> in the same way that some people have good "Google-fu"
or, perhaps, in the same way that google-fu over time became devalued as a skill as Google became less useful for power users in order to cater to the needs of the unskilled, it will not really be a portable skill at all, because it is in the end a transitory or perhaps easily attainable skill once the technology is evenly distributed.
Re: Breaking the spell of vibe coding
#183> 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.
> 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?
Re: Breaking the spell of vibe coding
#184Twice 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.
Your wording painted the picture of a drug high in my mind, probably an upper. Requiem for Dream style, amazing “Summer”, followed the brutal come down that is “Winter.”
Thank you for not using an LLM.
Re: Breaking the spell of vibe coding
#185Earlier quoted context omitted.
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…
> 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 acti…
I've had reasonable results from using AI to analyse code ("convert this code into a method call graph in graphml format" or similar). Apart from hallucinating one of the edges, this worked reasonably well to throw this into yED and give me a view on the code.
An alternative that occurred to me the other day is, could a PR be broken down into separate changes? As in, break it into a) a commit renaming a variable b) another commit making the functional change c) ...
Feel like there are PR analysis tools out there already for this :)
Re: Breaking the spell of vibe coding
#186Earlier 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
The addictive nature of the technology persists though. So even if we say certain skills are required to use it, then also it must come with a warning label and avoided by people with addictive personalities/substance abuse issues etc.
It's addictive because of a hypothesis I have about addiction. I have no data to back it up other than knowing a lot of addicted people and I have studied neuroscience, yet I still think there's something to it. It's definitely not fully true though.
Addiction occurs because as humans we bond with people but we also bond with things. It could be an activity, a subject, anything. We get addicted because we're bonded to it. Usually this happens because we're not in fertile grounds to bond with what we need to bond with (usually a good group of friends).
When I look at addicted people a lot of them bond with people that have not so great values (big house, fast cars, designer clothing, etc.), adopt those values themselves and get addicted to drugs. This drugs is usually supplied by the people they bond with. However, they bond with those people in the first place because of being aimless and receiving little guidance in their upbringing.
I'm just saying all that to make it more concrete with what I mean about "good people".
Back to LLMs. A lot of us are bonding with it, even if we still perceive it as an AI. We're bonding with it because when it comes to certain emotional needs, they're not being fulfilled. Enter a computer that will listen endlessly to you and is intellectually smarter than most humans, albeit it makes very very dumb mistakes at times (like ordering +1000 drinks when you ask for a few).
That's where we're at right now.
I've noticed I'm bonded with it.
Oh, and to some who feel this opinion is a bit strong, it is. But consider that we used to joke that "Google is your best friend" when it just came out and long thereafter. I think there's something to this take but it's not fully in the right direction I think.
Re: Breaking the spell of vibe coding
#187I 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?
[deleted]
Re: Breaking the spell of vibe coding
#188Just because you’re a good programmer / software engineer doesn’t mean you’re a good architect, or a good UI designer, or a good product manager. Yet in my experience, using LLMs to successfully produce software really works those architect, designer, and manager muscles, and thus requires them to be strong.
You're doing architect/designer/manager work while being treated, and paid, like a code monkey. This is by design.
It’s also much faster that way. We cut so many corners and make wise bets in what to test a lot and what not to bother with compared to spec-driven development with an LLM.
Re: Breaking the spell of vibe coding
#189Earlier quoted context omitted.
I think it's like the California gold rush. Anybody and their brother can go out and dig, but the real money is in selling the shovels.
More like they’re leasing away deeply discounted steam shovels at below market rates and somehow expecting to turn a profit doing so. The real profits are the companies selling them chips, fiber, and power.
A handful of start ups will find genuine use cases for these models with real business demand. It just won’t be another AI travel agent chat bot.
Re: Breaking the spell of vibe coding
#190tl;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.
It can facilitate that, certainly. Idk about the background of that stakeholder, but AI can help drafting communication with the right tone to show the necessity. It can help to write a guide on how to properly test the specific feature. It can write e2e tests that the stakeholder could execute from their environment.
Of course, all of that can be done by humans, too. But this discussion is about average speed of a developer, and there’s a reason many companies employ product owners for the stakeholder communication.