Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perverse incentives of vibe coding

fredbenenson.medium.com

Post reply on HN
Print view View original

51–60 of 239 posts

Re: Perverse incentives of vibe coding

#51

Post by YossarianFrPrez »

There are two sets of perverse incentives at play. The main one the author focuses on is that LLM companies are incentivized to produce verbose answers, so that when you task an LLM on extending an already verbose project, the tokens used and therefore cost increases.

The second one is more intra/interpersonal: under pressure to produce, it's very easy to rely on LLMs to get one 80% of the way there and polish the remaining 20%. I'm in a new domain that requires learning a new language. So something I've started doing is asking ChatGPT to come up with exercises / coding etudes / homework for me based on past interactions.

Re: Perverse incentives of vibe coding

#52

Post by ben_w »

martin-t wrote: post #40
tippytippytango wrote: post #7

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…

Given that LLMs are trained on humans, who don't respond well to being dehumanised, I expect anthropomorphising them to be better than the opposite of that.

https://www.microsoft.com/en-us/worklab/why-using-a-polite-t...

Re: Perverse incentives of vibe coding

#53

Post by squeaky-clean »

codr7 wrote: post #48
mystified5016 wrote: post #44

Earlier quoted context omitted.

I run genAI models on my own hardware for free. How does that fit into your argument?

The fact that you can get your drugs for free doesn't exactly make you less of an addict.

It does literally make it not gambling though, which is what's betting discussed.

It also kind of breaks the whole argument that they're designed to be addictive in order to make you spend more on tokens.

Re: Perverse incentives of vibe coding

#54

Post by codr7 »

Ancapistani wrote: post #32
biker142541 wrote: post #18

Can we please stop using 'vibe coding' to mean 'ai assisted coding'?? (best breakdown, imo: https://simonwillison.net/2025/Mar/19/vibe-coding/ ) Is it really vibe coding if you are building a detailed coding plan, conducting "git-based experimentation with ruthless pruning", and essentially reviewing the code incrementally for correctness and conciseness? Sure, it's a process dependent on AI, but it's very far from n…

There should be a distinction, but I don't think it's really clear where it is yet. In my own usage, I tend to alternate between tiny, well-defined tasks and larger-scale, planned architectural changes or new features. Things in between those levels are hit and miss. It also depends on what I'm building and why. If it's a quick-and-dirty script for my own use, I'll often write up - or speak - a prompt and let it do i…

It's still gambling, you're trading learning/reinforcing for efficiency, which in the long run means losing skills.

Re: Perverse incentives of vibe coding

#55

Post by latentsea »

codr7 wrote: post #48
mystified5016 wrote: post #44

Earlier quoted context omitted.

I run genAI models on my own hardware for free. How does that fit into your argument?

The fact that you can get your drugs for free doesn't exactly make you less of an addict.

I used to run GenAI image generators on my own hardware, and I 200% agree with your stance. Literally wound up selling my RTX 4090 to get the dealer to move out of the house. I'm better off now, but can't ever really own a GPU again without opening myself back up to that. Sigh...

Re: Perverse incentives of vibe coding

#56

Post by jazoom »

martin-t wrote: post #43
andrewstuart wrote: post #35

Claude was last week. The author should try Gemini it’s much better.

Honestly can't tell if satire or not.

It's not satire. Gemini is much better for coding, at least for me.

Just to illustrate, I asked both about a browser automation script this morning. Claude used Selenium. Gemini used Playwright.

I think the main reasons Gemini is much better are:

1. It gets my whole code base as context. Claude can't take that many tokens. I also include documentation for newer versions of libraries (e.g. Svelte 5) that the LLM is not so familiar with.

2. Gemini has a more recent knowledge cutoff.

3. Gemini 2.5 Pro is a thinking model.

4. It's free to use through the web UI.

Re: Perverse incentives of vibe coding

#57

Post by didgetmaster »

iotku wrote: post #13
tippytippytango wrote: post #7

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.

There's a pretty big gap between "make it work" and "make it good". I've found with LLMs I can usually convince them to get me at least something that mostly works, but each step compounds with excessive amounts of extra code, extraneous comments ("This loop goes through each..."), and redundant functions. In the short term it feels good to achieve something 'quickly', but there's a lot of debt associated with runnin…

In my opinion, the difference between good code and code that simply works (sometimes barely); is that good code will still work (or error out gracefully) when the state and the inputs are not as expected.

Good programs are written by people who anticipate what might go wrong. If the document says 'don't do X'; they know a tester is likely to try X because a user will eventually do it.

Re: Perverse incentives of vibe coding

#59

Post by NegativeLatency »

NathanKP wrote: post #49
dingnuts wrote: post #17

Earlier quoted context omitted.

it's not like gambling, it is gambling. you exchange dollars for chips (tokens -- some casinos even call the chips tokens) and insert it into the machine in exchange for the chance of a prize. if it doesn't work the first time you pull the lever, it might the second time, and it might not. Either way, the house wins. It should be regulated as gambling, because it is. There's no metaphor, the only difference from a sl…

This only makes sense if you have an all or nothing concept of the value of output from AI. Every prompt and answer is contributing value toward your progress toward the final solution, even if that value is just narrowing the latent space of potential outputs by keeping track of failed paths in the context window, so that it can avoid that path in a future answer after you provide followup feedback. The vast majorit…

> Every prompt and answer is contributing value toward your progress toward the final solution

This has not been my experience, maybe sometimes, but certainly not always.

As an example: asking chatgpt/gemini about how to accomplish some sql data transformation set me back in finding the right answer because the answer it did give me was so plausible but also super duper not correct in the end. Would've been better off not using it in that case.

Brings to mind "You can't build a ladder to the moon"

Re: Perverse incentives of vibe coding

#60

Post by mystified5016 »

andy99 wrote: post #36
samtp wrote: post #20

I've pretty clearly seen the critical thinking ability of coworkers who depend on AI too much sharply decline over the past year. Instead of taking 30 seconds to break down the problem and work through assumptions, they immediately copy/paste into an LLM and spit back what it tells them. This has lead to their abilities stalling while their output seemingly goes up. But when you look at the quality of their output, a…

I think lack of critical thinking is the root cause, not a symptom. I think pretty much everyone uses LLMs these days, but you can tell who sees the output and considers it "done" vs who uses LLM output as an input to their own process.

I mean, I can tell that I'm having this problem and my critical thinking skills are otherwise typically quite sharp.

At work I've inherited a Kotlin project and I've never touched Kotlin or android before, though I'm an experienced programmer in other domains. ChatGPT has been guiding me through what needs to be done. The problem I'm having is that it's just too damn easy to follow its advice without checking. I might save a few minutes over reading the docs myself, but I don't get the context the docs would have given me.

I'm a 'Real Programmer' and I can tell that the code is logically sound and self-consistent. The code works and it's usually rewritten so much as to be distinctly my code and style. But still it's largely magical. If I'm doing things the less-correct way, I wouldn't really know because this whole process has led me to some pretty lazy thinking.

On the other hand, I very much do not care about this project. I'm very sure that it will be used just a few times and never see the light of day again. I don't expect to ever do android development again after this, either. I think lazy thinking and farming the involved thinking out to ChatGPT is acceptable here, but it's clear how easily this could become a very bad habit.

I am making a modest effort to understand what I'm doing. I'm also completely rewriting or ignoring the code the AI gives me, it's more of an API reference and example. I can definitely see how a less-seasoned programmer might get suckered into blindly accepting AI code and iterating prompts until the code works. It's pretty scary to think about how the coming generations of programmers are going to experience and conceptualize programming.

Post reply on HN