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

231–239 of 239 posts

Re: Perverse incentives of vibe coding

#231

Post by motorest »

tauoverpi wrote: post #191
motorest wrote: post #190

Earlier quoted context omitted.

> I've had the same issue every time I've tried it. The code I generally work on is embedded C/C++ with in-house libraries where the tools are less than useful as they try to generate non-existant interfaces and generally generate worse code than I'd write by hand. That's because whatever training the model had, it didn't covered anything remotely similar to the codebase you worked on. We get this issue even with obs…

I'm aware of the _why_ but this is why the tools aren't useful for my case. If they cannot consume the codebase in a reasonable amount of time and provide value from that then they generally aren't useful in areas where I would want to use them (navigating large codebases). If the codebase is relatively small or the problem is known then an LLM is not any better than tab-complete and arguably worse in many cases as t…

> I'm aware of the _why_ but this is why the tools aren't useful for my case. If they cannot consume the codebase in a reasonable amount of time and provide value from that then they generally aren't useful in areas where I would want to use them (navigating large codebases).

I challenge you to explore different perspectives.

You are faced with a service that handles any codebase that's thrown at it with incredible ease, without requiring any tweaking or special prompting.

For some reason, the same system fails to handle your personal codebase.

What's the root cause? Does it lie in the system that works everywhere with anything you throw at it? Or is it in your codebase?

Re: Perverse incentives of vibe coding

#232

Post by jiggawatts »

tptacek wrote: post #227
jiggawatts wrote: post #226

Earlier quoted context omitted.

Indexing that is 75x the original uncompressed data volume? Because then I might accept the cost! Realistically all of these systems use some type of data compression such as Parquet files, so the data on disk is likely smaller than the ingested data.

My point is that you're not really just paying for "storage".

What am I paying for?

I worked out that the markup on CPU, network bandwidth, and storage for the default logging products from the major clouds is on the order of 25x to 500x.

Okay, sure, there's some people that need to be paid, the back-end software may have some licensed components, etc, etc...

But still, comparing this to any other cloud service, the gross profit margin is just ridiculous!

It's the typical IT marketing trick of selling the commodity (VMs) at competitive prices, and then clawing back the profits via the "enterprise add-ons".

Re: Perverse incentives of vibe coding

#233

Post by nicbou »

nativeit wrote: post #150
nico wrote: post #139

Earlier quoted context omitted.

> It really captures how little control one has over the process, while simultaneously having the illusion of control. This is actually a big insight about life, that in some eastern philosophies, you are supposed to arrive to We love the illusion of control, even though we don’t really have it. Life mostly just unfolds as we experience it

This has certainly been my own experience in life. My step-father was a very studious and responsible person. He worked 30-years from the age of 19 with the state as an HVAC service tech until he retired at 49yo with a full state pension, and then went to work for a private company. His plan was to earn as much as he could until he turned 55, and then retire to live/work on the small farm he and my mother had just pu…

I've experienced this for the first time with a close friend, and it really stays on your mind. There was no reason it had to be him. He didn't roll the dice wrong.

It created a sense of urgency in my own life. You have this idea that you will be the same person until you die of old age, and suddenly you realise that the current year is worth much more than another year two decades from now. A bird in the hand is worth two in the bush.

Re: Perverse incentives of vibe coding

#234

Post by andrewstuart »

AlexCoventry wrote: post #134
jazoom wrote: post #56

Earlier quoted context omitted.

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

How do you give it your whole code base, via the web UI?

In a zip file in ai studio

Re: Perverse incentives of vibe coding

#235

Post by guyfhuo »

tptacek wrote: post #230
guyfhuo wrote: post #229

Earlier quoted context omitted.

I’d rather write server telemetry logic than any customer facing ui app, and it sounds like you would too.

I'd rather write a new Device Mapper target than do either of those things, and LLMs have been helpful with that too. Is a Device Mapper target the "CRUD app of the Linux kernel"?

> I'd rather write a new Device Mapper target than do either of those things

Perhaps it’s time for a career change then. Follow your joy and it will come more naturally for you to want to spread it.

Again,

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

From my reading the “strongest possible interpretation” of the original “CRUD app” line was “it’s a solved problem that largely requires rtfm and rote execution of well worn patterns in code structure” making it similarly situated as “server telemetry” to make llms appear superintelligent to people new to programming within those paradigms.

I’m unfamiliar with “device mapping”, so perhaps someone else can confirm if it is “the crud app of Linux kernel dev” in that vein.

Just listing topics in software development is hardly evidence of either your own ability to work on them, or of their inherent complexity.

Since this seems to have hurt your feelings, perhaps a more effective way to communicate your needs would be to explain why you find “server telemetry” to be more difficult/complex/w/e to warrant needing an llm for you to be able to do it.

Re: Perverse incentives of vibe coding

#236

Post by nkrisc »

Suppafly wrote: post #74
nkrisc wrote: post #70

Earlier quoted context omitted.

None of those are a games of chance, except the first.

>None of those are a games of chance, except the first. Neither is GenAI, the grandparent comment is dumb.

I see the resemblance, though. Money goes into mystery machine, thing you were hoping for maybe comes out. If it didn't, put more money in until you get the prize you want.

Re: Perverse incentives of vibe coding

#237

Post by tptacek »

jiggawatts wrote: post #232
tptacek wrote: post #227

Earlier quoted context omitted.

My point is that you're not really just paying for "storage".

What am I paying for? I worked out that the markup on CPU, network bandwidth, and storage for the default logging products from the major clouds is on the order of 25x to 500x. Okay, sure, there's some people that need to be paid, the back-end software may have some licensed components, etc, etc... But still , comparing this to any other cloud service, the gross profit margin is just ridiculous! It's the typical IT m…

I mean: we faced the same buy/build issue, and we went "build", and while I wouldn't say it was our worst decision, it was not one of our best either. Certainly the problem doesn't simply boil down to NVME gigabyte costs!

That said: we both agree, log ingestion services are extremely expensive.

Re: Perverse incentives of vibe coding

#238

Post by tptacek »

guyfhuo wrote: post #235
tptacek wrote: post #230

Earlier quoted context omitted.

I'd rather write a new Device Mapper target than do either of those things, and LLMs have been helpful with that too. Is a Device Mapper target the "CRUD app of the Linux kernel"?

> I'd rather write a new Device Mapper target than do either of those things Perhaps it’s time for a career change then. Follow your joy and it will come more naturally for you to want to spread it. Again, > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. From my reading the “strongest possible interpretation” of the origin…

I think you're off on your own little thing here and I wish you the best of luck with it, but I don't think I can be helpful for you.

Re: Perverse incentives of vibe coding

#239

Post by tauoverpi »

motorest wrote: post #231
tauoverpi wrote: post #191

Earlier quoted context omitted.

I'm aware of the _why_ but this is why the tools aren't useful for my case. If they cannot consume the codebase in a reasonable amount of time and provide value from that then they generally aren't useful in areas where I would want to use them (navigating large codebases). If the codebase is relatively small or the problem is known then an LLM is not any better than tab-complete and arguably worse in many cases as t…

> I'm aware of the _why_ but this is why the tools aren't useful for my case. If they cannot consume the codebase in a reasonable amount of time and provide value from that then they generally aren't useful in areas where I would want to use them (navigating large codebases). I challenge you to explore different perspectives. You are faced with a service that handles any codebase that's thrown at it with incredible e…

Well, what would I have to do to please the LLM? Writing code isn't for LLMs to consume but rather to communicate intent for people and for machines to run which provides value for the user at the end of the day. If an LLM fails at being useful within a codebase when it's supposed to be a "works anywhere" tool then the tool is less than useful.

Note that language servers, static analysis tooling, and so on still work without issue.

The cause (which is my assumption) is that there aren't enough good examples in the training set for anything useful to be the most likely continuation thus leading to a suboptimal result given the domain. Thus the tool doesn't work "everywhere" for cases where there's less use of a language or less code in general dealing with a particular problem.

Post reply on HN