Live data from Hacker News

Perverse incentives of vibe coding

fredbenenson.medium.com

211–220 of 239 posts

Re: Perverse incentives of vibe coding

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

I don't believe there are perverse incentives yet, right now it's arms race burn money and operate at a loss days. There is no moat only quality and price per token and the leader moves around too quickly. Also Author should really look into Cursor at $20 with unlimited slow requests, I imagine paying per token hurts when it spits out garbage even when you've thought you provided enough context but it wasn't enough.

Someone needs to make a plugin to count lines of discard code and prompts

Re: Perverse incentives of vibe coding

#212

I don't understand the productivity that people get out of these AI tools. I've tried it and I just can't get anything remotely worthwhile unless it's something very simple or something completely new being built from the ground up. Like sure, I can ask claude to give me the barebones of a web service that does some simple task. Or a webpage with some information on it. But any time I've tried to get AI services to h…

Incredibly useful for 'glue code' or internal apps that are for automating really annoying processes - but where normally the time it would take to develop those tools would add up and take away from the core work.

For instance, dealing with files that don't quite work correctly between two 3D applications because of slightly different implementations. Ask for a python script to patch the files so that they work correctly – done almost instantly just by describing the problem.

Also for prototyping. Before you spend a month crafting a beautiful codebase, just get something standing up so you can evaluate whether it's worth spending time on – like, does the idea have legs?

90% of programming problems get solved with a rubber ducky – and this is another valuable area. Even if the AI isn't correct, often times just talking it through with an LLM will get you to see what the solution is.

Re: Perverse incentives of vibe coding

#214

I don't understand the productivity that people get out of these AI tools. I've tried it and I just can't get anything remotely worthwhile unless it's something very simple or something completely new being built from the ground up. Like sure, I can ask claude to give me the barebones of a web service that does some simple task. Or a webpage with some information on it. But any time I've tried to get AI services to h…

They aren't increasing productivity. In the short term.

They are very handy tools that can help you learn a foreign code/base faster. They can help you when you run into those annoying blockers that usually take hours or days or a second set of eyes to figure out. They give you a sounding board and help you ask questions and think about the code more.

Big IF here. IF you bother to read. The danger is some people just keep clicking and re-prompting until something works, but they have zero clue what it is and how it works. This is going to be the biggest problem with AI code editors. People just letting Jesus take the wheel and during this process, inefficient usage of the tools will lead to slower throughput and a higher bill. AI costs a good chunk of change per token and that's only going up.

I do think it's addictive for sure. I also think the "productivity boost" is a feeling people get, but no one measures. I mean, it's hard to measure. Then again, if you do spend an hour on a problem you get stuck on vs 3 days then sure it helped productivity. In that particular scenario. Averaged out? Who knows.

They are useful tools, they are just also very misunderstood and many people are too lazy to take the time to understand them. They read headlines and unsubstantiated claims and get overwhelmed by hype and FOMO. So here we are. Another tech bubble. A super bubble really. It's not that the tools won't be with us for a long time or that they aren't useful. It's that they are way way overvalued right now.

Re: Perverse incentives of vibe coding

#215

I understand your point. The Vibe approach is IMO only effective when you adopt a software engineering mindset. Here's how it works (at least for me with Copilote agent mode): 1. Develop a Minimum Viable Product (MVP) or prototype that functions. 2. Write tests, either before or after the initial development. 3. Implement coding guidelines, style guides, linter etc. Do code reviews. 4. Continuously adjust, add featur…

I have doubts that testing is going to be the key to make vibe coding work for non-trivial projects. I'd focus on developing great well documented interfaces between components and keeping the scope of your agent under control.

Perhaps I wasn't clear, but I was referring to a small tool or a specific feature that, in my opinion, embodies your approach. Keeping the scope clear and minimizing cognitive load—through practices like code splitting—are essential. Implementing tests, whether unit, component, or integration tests, as part of your testing strategy, helps provide quick feedback on recent changes. As you would do it on a traditional codebase.

Re: Perverse incentives of vibe coding

#216

Earlier quoted context omitted.

The first and most important question to ask here is: are you using a coding agent? A lot of times, people who aren't getting much out of LLM-assisted coding are just asking Claude or GPT for code snippets, and pasting and building them themselves (or, equivalently, they're using LLM-augmented autocomplete in their editor). Almost everybody doing serious work with LLMs is using an agent, which means that the LLM is a…

Funny, I would give the absolute opposite advice. In my experience, the use of agents (mainly Cursor) is a sure-fire way to have a really painful experience with LLM-assisted coding. I much prefer to use AI as a pair programmer, that I talk to and sometimes get to write entire files, but I'm always the one doing the driving, and mostly the one writing the code. If you aren't building up mental models of the problem a…

Cursor is pretty bad in my experience. I don't know why because I find Windsurf better and they both use Claude.

Regardless, Gemini 2.5 Pro is far far better and I use that with open-source free Roo Code. You can use the Gemini 2.5 Pro experimental model for free (rate limited) to get a completely free experience and taste for it.

Cursor was great and started is off, but others took notice and now they're all more or less the same. It comes down to UX and preference, but I think Windsurf and Roo Code just did a better job here than Cursor, personally.

Re: Perverse incentives of vibe coding

#217
post #52

Earlier quoted context omitted.

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

I am not talking about getting it to generate useful output, treating it extra politely or threatening with fines seems to give better results sometimes so why not, I am talking about the phrase "gets it". It does not get anything.

Re: Perverse incentives of vibe coding

#218
> In an effort to impress the user and over-deliver, LLMs end up creating a rat’s nest of ultra-defensive code littered with debugging statementsIn an effort to impress the user and over-deliver, LLMs end up creating a rat’s nest of ultra-defensive code littered with debugging statements

This has been my experience as well. I have to continuously explicitly instruct Claude to be more concise (though that often leads to broken code ...). Gemini is even more verbose.

I'm not sure in the end how much time is saved over simple good auto-completes (for method syntax lookups), other than for rote tasks like "replicate this pattern across X" (and even then it doesn't get it 100% right), and for quick answers to specific questions usually in frameworks I'm not that well versed it that I would have searched SO for ("how do I do X in Qt?", "how do I do the equivalent of Y in Linux on Windows")--but even then I have to verify the answer, whereas if it's a highly voted answer on SO I'll know it works (or there will be helpful comments to the contrary under the reply).

Most of the "it can build X app for you automatically" comments I read remind me of "build a Rails app in 5 lines" (back in the day).

Re: Perverse incentives of vibe coding

#219
post #173
post #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…

> When you run the software yourself, or the model yourself, the incentives aligned: use less power, use less memory, use less disk, etc. But my team's time is soooo valuable. It's sooo sooo sooo valuable. Oh and we can't afford to hire anyone else either. But our time its sooo valuable. We need these tools!

Opens PR with quadruple-nested for-loop running synchronous DB queries.

- Premature optimization is the root of all evil, can't waste expensive dev hours on that..

Re: Perverse incentives of vibe coding

#220
post #13

Earlier quoted context omitted.

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.

I feel like you're talking about programs here rather than code. A program that behaves well is not necessarily built with good code.

I can see an LLM producing a good program with terrible code that's hard to grok and adjust.

Post reply on HN