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

351–360 of 375 posts

Re: Breaking the spell of vibe coding

#351

Post by ozozozd »

CoinFlipSquire wrote: post #146
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.

Sounds like something who can’t even churn out a measly 10k per day would say. /s

Re: Breaking the spell of vibe coding

#352

Post by claudeomusic »

skydhash wrote: post #57
claudeomusic wrote: post #48

I think a big part of this discussion lost for a lot is a lot of people are trying to copy/paste how we’ve been developing software over the past twenty years into this new world which simply doesn’t work effectively. The differences are subtle but those of us who are fully bought in (like myself) are working and thinking in a new way to develop effectively with LLMs. Is it perfect? Of course not - but is it dramatic…

What are such new ways? You’re being very vague about them.

To be a little less vague - I think the biggest difference I’ve seen is where time is spent. In the past since I know what I’m doing I’d go straight into dev mode pretty quickly .

Going straight into dev mode with an LLM pretty much always goes wrong - a lot more time is spent in planning and in setting up constraints for how an agent can operate before letting it loose so that once you set it free it can run.

Re: Breaking the spell of vibe coding

#353

Post by claudeomusic »

skydhash wrote: post #57
claudeomusic wrote: post #48

I think a big part of this discussion lost for a lot is a lot of people are trying to copy/paste how we’ve been developing software over the past twenty years into this new world which simply doesn’t work effectively. The differences are subtle but those of us who are fully bought in (like myself) are working and thinking in a new way to develop effectively with LLMs. Is it perfect? Of course not - but is it dramatic…

What are such new ways? You’re being very vague about them.

It’s a crude comparison but it’s a lot more similar to what I’ve done in my management roles than what I’ve done as a dev.

Re: Breaking the spell of vibe coding

#354

Post by rtpg »

bryanrasmussen wrote: post #182
rtpg wrote: post #160

Earlier quoted context omitted.

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.

Perhaps, but in Google's case that's, what, 10 years of value I got out of knowing how to write good searches? Probably more honestly.

Everything is temporary to some extent.

Re: Breaking the spell of vibe coding

#355

Post by rtpg »

croes wrote: post #228
rtpg wrote: post #160

Earlier quoted context omitted.

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…

Are the early tricks for LLMs still useful today?

I mean the high level stuff is still there right? Be straightforward, leave the right kind of pointers into the thing, say the right kind of things.

But... I guess nowadays you can be vague and it'll get the gist of it.

Re: Breaking the spell of vibe coding

#356

Post by rafaelmn »

kamaal wrote: post #232
rafaelmn wrote: post #221

Earlier quoted context omitted.

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

Replace LLM with employee in your argument - what changes ? Unless everyone at your workplace owns the system they are working on - this is a very high bar and maybe 50% of devs I've worked with are capable of owning a piece of non trivial code, especially if they didn't write it.

Realiy is you don't solve these problems by to relying on everyone to be perfect - everyone slips up - to achieve results consistently you need process/systems to assure quality.

Safety critical system should be even better equipped to adopt this because they already have the systems to promote correct outputs.

The problem is those systems weren't built for LLMs specifically so the unexpected failure cases and the volume might not be a perfect fit - but then you work on adapting the quality control system.

Re: Breaking the spell of vibe coding

#357

Post by kamaal »

rafaelmn wrote: post #356
kamaal wrote: post #232

Earlier quoted context omitted.

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

Replace LLM with employee in your argument - what changes ? Unless everyone at your workplace owns the system they are working on - this is a very high bar and maybe 50% of devs I've worked with are capable of owning a piece of non trivial code, especially if they didn't write it. Realiy is you don't solve these problems by to relying on everyone to be perfect - everyone slips up - to achieve results consistently you…

>>replace LLM with employee in your argument - what changes ?

I mentioned this part in my comment. You cannot trust an automated process to a thing, and expect the same process to verify if it did it right. This is with regards to any automated process, not just code.

This is not the same as manufacturing, as in manufacturing you make the same part thousands of times. In code the automated process makes a specific customised thing only once, and it has to be right.

>>The problem is those systems weren't built for LLMs specifically so the unexpected failure cases ...

We are not talking of failures. There is a space between success and failure where the LLM can go into easily.

Re: Breaking the spell of vibe coding

#358

Post by daxfohl »

rainmaking wrote: post #119
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…

> my best ideas often happen when knee deep in some codebase I notice that I get into this automatically during AI-assisted coding sessions if I don't lower my standards for the code. Eventually, I need to interact very closely with both the AI and the code, which feels similar to what you describe when coding manually. I also notice I'm fresher because I'm not using many brainscycles to do legwork- so maybe I'm actu…

Yeah, I get this too. Still, I think sometimes being forced to grind on something will spur the "oh wait" moment that leads to new ways of thinking about things. Whereas when the LLM is doing the grinding, you don't see it. You just get a final PR with only the answer to the problem at hand, and you miss the bigger opportunity.

That said, maybe it's not a big deal. Kind of like way back when I moved from C++ to GC code, I remember I missed memory leaks, because having it all automatically taken care of for free felt like giving up control and encouraging of lazy practices and loose ends. Turns out it wasn't really a big deal at all.

Re: Breaking the spell of vibe coding

#359

Post by EagnaIonat »

JSR_FDED wrote: post #144

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.

I've found Claude works so much better if you build a CLAUDE.md and tell it that you want it to be an interactive design process.

It helps formalise your plan, then creates some code, you review, talk about what you believe to be wrong or asking it why it took that approach, or even telling it to take the approach that you want.

The end result a world of difference, and I feel I have a better grasp of what is going on in the whole application.

Re: Breaking the spell of vibe coding

#360

Post by bitwize »

asdff wrote: post #340
theYipster wrote: post #5

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

The irony considering "good" ui to a ui designer is completely at odds with users. We got better ui when it was people who had no clue what they were doing just trying to make some sense out of it, vs the cult of dogmatic ui design we see today where everything follows the same crappy patterns and everyone is afraid to step out of line.

Actually the opposite is the case. UI design was best when designers were systematic in their approach, employing concepts from human psychology and rigorously testing and timing how long it took to perform actions on the computer, optimizing for efficiency, discoverability, and ease of use. Today's UI designers copy from designs they've seen before, often poorly, and when they do apply data and metrics it's to bullshit KPIs like "engagement".
Post reply on HN