Live data from Hacker News

Perverse incentives of vibe coding

fredbenenson.medium.com

81–90 of 239 posts

Re: Perverse incentives of vibe coding

#81
post #29

I wish more had been written about the first assertion that using an LLM to code is like gambling and you're always hoping that just one more prompt will get you what you want. It really captures how little control one has over the process, while simultaneously having the illusion of control. I don't really believe that code is being made verbose to make more profits. There's probably some element of model providers…

Something I caught about Andrej Karpathy’s original tweet, was he said “give into the vibes”, and I wonder if he meant that about outcomes too.

Re: Perverse incentives of vibe coding

#82
post #2

> There was no standardization of parts in the probe. Two widgets intended to do almost the same job could be subtly different or wildly different. Braces and mountings seemed hand carved. The probe was as much a sculpture as a machine. > Blaine read that, shook his head, and called Sally. Presently she joined him in his cabin. > “Yes, I wrote that," she said. "It seems to be true. Every nut and bolt in that probe wa…

That book is very much fun and also I never understood why Larry Niven is so obsessed with techno feudalism and gender roles. I think this is my favourite book but I think his best book is maybe Ringworld.

>I think this is my favourite book but I think his best book is maybe Ringworld.

Ringworld is pretty good, the multiples sequels get kind of out there.

Re: Perverse incentives of vibe coding

#83
post #41

Earlier quoted context omitted.

That book is very much fun and also I never understood why Larry Niven is so obsessed with techno feudalism and gender roles. I think this is my favourite book but I think his best book is maybe Ringworld.

Ringworld is a great book. The later books have great concepts, but could do without so much. . . rishing. Niven plainly inserted his furry porn fetish into those books, for reasons unclear to any human alive.

>for reasons unclear to any human alive

Given how prevalent furries seem to be, especially in nerd adjacent culture, I'd say he was ahead of his time.

Re: Perverse incentives of vibe coding

#84

Earlier quoted context omitted.

That book is very much fun and also I never understood why Larry Niven is so obsessed with techno feudalism and gender roles. I think this is my favourite book but I think his best book is maybe Ringworld.

>I think this is my favourite book but I think his best book is maybe Ringworld. Ringworld is pretty good, the multiples sequels get kind of out there.

I never read any of the sequels just a couple of the short story collections and some of the man kzin wars. What’s wild about them?

Re: Perverse incentives of vibe coding

#85
These perverse incentives run at the heart of almost all Developer Software as a Service tooling. Using someone else's hosted model incentivizes increasing token usage, but it's nothing special about AI.

Consider Database-as-a-service companies: They're not incentivized to optimize on CPU usage, they charge per cpu. They're not incentivized to improve disk compression, they charge for disk-usage. There are several DB vendors who explicitly disable disk compression and happily charge for storage capacity.

When you run the software yourself, or the model yourself, the incentives aligned: use less power, use less memory, use less disk, etc.

Re: Perverse incentives of vibe coding

#86

This article captures a lot of the problem. It’s often frustrating how it tries to work around really simple issues with complex workarounds that don’t work at all. I tell it the secret simple thing it’s missing and it gets it. It always makes me think, god help the vibe coders that can’t read code. I actually feel bad for them.

> I tell it the secret simple thing it’s missing and it gets it. Anthropomorphizing LLMs is not helpful. It doesn't get anything, you just gave it new tokens, ones which are more closely correlated with the correct answer. It also generates responses similar to what a human would say in the same situation. Note i first wrote "it also mimicks what a human would say", then I realized I am anthropomorphizing a statistic…

>Anthropomorphizing LLMs is not helpful

It's a feature of language to describe things in those terms even if they aren't accurate.

>using terms which better describe how it really works is important

Sometimes, especially if you doing something where that matters, but abstracting those details away is also useful when trying to communicate clearly in other contexts.

Re: Perverse incentives of vibe coding

#87
post #31

I can feel how the extreme autocomplete of AI is a drug. Half of my job is fighting the "copy/paste/change one thing" garbage that developers generate. Keeping code DRY. The autocompletes do an amazing job of automating the repeated boilerplate. "Oh you're doing this little snippet for the first and second property? Obviously you want to do that for every property! Let me just expand that out for you!" And I'm like "…

>That kind of code is not fine.

Depends on your definition of fine. Is it less readable because it's doing the straight forward thing several times instead of wrapping it into a loop or a method, or is it more readable because of that.

Is it not fine because it's slower, or does it all just compile down to the same thing anyway?

Or is it not fine because you actually should be doing different things for the different properties but assumed you don't because you let the AI do the thinking for you?

Re: Perverse incentives of vibe coding

#89
I feel like "vibe coding" as a "no look" sort of way to produce anything is bad and will probably remain bad for some time.

However... "vibe architecting" is likely going to be the way forward. I have had success with generating/tuning an architecture plan with AI, having it create stub files/functions then filling them out individually. I can get pretty much the whole way without typing code, but it does require a fair bit more architectural thinking than usual and a good bit of reading code (then telling the AI to "do better").

I think of it like the analogy of blind men describing an elephant when they can only feel a single part. AI is decent at high level architecture and decent at low level production but you need a human to understand the big picture and how the pieces fit (and which ones are missing).

Post reply on HN