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

131–140 of 375 posts

Re: Breaking the spell of vibe coding

#131

Post by throwaway7783 »

fragmede wrote: post #129
throwaway7783 wrote: post #127

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

What disaster befell your friend after those three months?

Several, but I can't quite say it here. And I meant it for the codebase, not the person themselves

Re: Breaking the spell of vibe coding

#132

Post by fragmede »

holoduke wrote: post #124
AstroBen wrote: post #107

Earlier quoted context omitted.

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

Nothing gets worse in computers. Name me one thing. And if the current output quality of LLM stays the same but speed goes up 1000, quality of the generated code can be higher.

Hot keys. Used to be, you could drive a program from the keyboard with hotkeys and macros. No mouse. The function keys did functions. You could drive the interface blindfolded, once you learned it. Speed is another one. Why does VSCode take so long to open? and use so much memory and CPU? it's got a lot of features for a text editor, but it's worse than vim/emacs in a lot of ways.

Boot time.

Understandability. A Z80 processor was a lot more understandable than today's modern CPUs. That's worse.

Complexity. It's great that I can run python on a microcontroller and all, but boring old c was a lot easier to reason about.

Wtf is a typescript. CSS is the fucking worst. Native GUI libraries are so much better but we decided those aren't cool anymore.

Touchscreens. I want physical buttons that my muscle memory can take over and get ingrained in and on. Like an old stick shift car that you have mechanical empathy with. Smartphones are convenient as all hell, but I can't drive mine after a decade like you can a car you know and feel, that has physical levers and knobs and buttons.

Jabber/Pidgin/XMPP. There was a brief moment around 2010? when you didn't have to care what platform someone else was using, you could just text with them on one app. Now I've got a dozen different apps I need to use to talk to all of my friends. Beeper gets it, but they're hamstrung. This is a thing that got worse with computers!

Ever hear of wirths law? https://en.wikipedia.org/wiki/Wirth%27s_law

Computers are stupid fast these days! why does it take so long to do everything on my laptop? my mac's spotlight index is broken, so it takes it roughly 4 seconds to query the SQLite database or whatever just so I can open preview.app. I can open a terminal and open it myself in that time!

And yes, these are personal problems, but I have these problems. How did the software get into such a state that it's possible for me to have this problem?

Re: Breaking the spell of vibe coding

#133

Post by p1esk »

daxfohl wrote: post #51
softwaredoug wrote: post #30

Earlier quoted context omitted.

Even within AI coding how people use this varies wildly from one people trying to one shot apps to people being barely above tab completers. When people talk about this stuff they usually mean very different techniques. And last months way of doing it goes away in favor of a new technique. I think the best you can do now is try lots of different new ways of working keep an open mind

Or just wait for things to settle. As fast as the field is moving, staying ahead of the game is probably high investment with little return, as the things you spend a ton of time honing today may be obsolete tomorrow, or simply built into existing products with much lower learning cost. Note, if staying on the bleeding edge is what excites you, by all means do. I'm just saying for people who don't feel that urge, the…

Interesting - what makes you think things will slow down?

Re: Breaking the spell of vibe coding

#134

Post by raincole »

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?

The image generation side of the story is the prophecy.

I can confidently say that being able to prompt and train LoRAs for Stable Diffusion makes zero difference for your ability to prompt Nano Banana.

Re: Breaking the spell of vibe coding

#135

Post by aeon_ai »

raincole wrote: post #134
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?

The image generation side of the story is the prophecy. I can confidently say that being able to prompt and train LoRAs for Stable Diffusion makes zero difference for your ability to prompt Nano Banana.

And most artists using the tools are still training LoRAs for Flux, Qwen, ZIT/ZIB, etc. Nano Banana is a useful tool, but not for the best work.

Re: Breaking the spell of vibe coding

#136

Post by wokwokwok »

aeon_ai wrote: post #135
raincole wrote: post #134

Earlier quoted context omitted.

The image generation side of the story is the prophecy. I can confidently say that being able to prompt and train LoRAs for Stable Diffusion makes zero difference for your ability to prompt Nano Banana.

And most artists using the tools are still training LoRAs for Flux, Qwen, ZIT/ZIB, etc. Nano Banana is a useful tool, but not for the best work.

This is irrelevant to the point.

Using nano banana does not require arcane prompt engineering.

People who have not learnt image prompt engineering probably didn't miss anything.

The irony of prompt engineering is that models are good at generating prompts.

Future tools will almost certainly simply “improve” you naive prompt before passing it to the model.

Claude already does this for code. Id be amazed if nano banana doesnt.

People who invested in learning prompt engineering probably picked up useful skills for building ai tools but not for using next gen ai tools other people make.

Its not wasted effort; its just increasingly irrelevant to people doing day-to-day BAU work.

If the api prevents you from passing a raw prompt to the model, prompt engineering at that level isnt just unnecessary; its irrelevant. Your prompt will be transformed into an unknown internal prompt before hitting the model.

Re: Breaking the spell of vibe coding

#137

Post by otabdeveloper4 »

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…

> you may be less productive than optimal

There is zero evidence that LLM's improve software developer productivity.

Any data-driven attempts to measure this give ambivalent results at best.

Re: Breaking the spell of vibe coding

#139

Post by raincole »

wokwokwok wrote: post #136
aeon_ai wrote: post #135

Earlier quoted context omitted.

And most artists using the tools are still training LoRAs for Flux, Qwen, ZIT/ZIB, etc. Nano Banana is a useful tool, but not for the best work.

This is irrelevant to the point. Using nano banana does not require arcane prompt engineering. People who have not learnt image prompt engineering probably didn't miss anything. The irony of prompt engineering is that models are good at generating prompts. Future tools will almost certainly simply “improve” you naive prompt before passing it to the model. Claude already does this for code. Id be amazed if nano banana…

> Claude already does this for code. Id be amazed if nano banana doesnt.

Nano Banana is actually a reasoning model so yeah it kinda does, but not in the way one might assume. If you use the api you can dump the text part and it's usually huge (and therefore expensive, which is one drawback of it. It can even have "imagery thinking" process...!)

Re: Breaking the spell of vibe coding

#140

Post by bitwize »

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.

You're doing architect/designer/manager work while being treated, and paid, like a code monkey. This is by design.
Post reply on HN