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

221–230 of 239 posts

Re: Perverse incentives of vibe coding

#221

Post by Suppafly »

mnky9800n wrote: post #84
Suppafly wrote: post #82

Earlier quoted context omitted.

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

It's been a long time since I read them, but I recall the sequels being less focused plot-wise and also having a lot more of the human + alien/furry relations. I think I read 5 or 6 of them and mostly enjoyed them, but eventually moved on to other authors. Might be time to revisit them now that I've mostly forgotten them enough that it'll feel fresh again.

Re: Perverse incentives of vibe coding

#222

Post by tptacek »

jiggawatts wrote: post #200
tptacek wrote: post #130

Earlier quoted context omitted.

Companies that ingest logs generally rip their customers faces off with their pricing. At least oTel spans can be tail-sampled.

I worked out that it's cheaper to write logs to high-end Samsung SSDs and then throw them away every month than to retain them in the log analytics systems of some cloud services for the same period of time. Wait, no, sorry... that doesn't quite "paint the right picture". The "single use" SSDs are 75 times cheaper than storing the data in the cloud.

As someone who works at a platform company that operates several (very) large log ingestion systems, if you're not indexing the logs usefully, having stored them on SSDs isn't doing much for you. It's just a weird comparison to make, is all I'm saying.

Re: Perverse incentives of vibe coding

#225

Post by tptacek »

guyfhuo wrote: post #184
tptacek wrote: post #154

Earlier quoted context omitted.

Large scale server telemetry and fiddly OAuth2/Macaroon token management.

This seems a self servingly literal interpretation of the op’s original comment. Clearly something like “server telemetry” is the datacenter’s “CRUD app” analogue. It’s a solved problem that largely requires rtfm and rote execution of well worn patterns in code structure. Please stick to the comment guidelines: > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's ea…

I'm laughing at the idea of server telemetry being "the data center equivalent of a CRUD app". I'll just pull out my Telemetry On Rails framework and run some generators...

Re: Perverse incentives of vibe coding

#226

Post by jiggawatts »

tptacek wrote: post #222
jiggawatts wrote: post #200

Earlier quoted context omitted.

I worked out that it's cheaper to write logs to high-end Samsung SSDs and then throw them away every month than to retain them in the log analytics systems of some cloud services for the same period of time. Wait, no, sorry... that doesn't quite "paint the right picture". The "single use" SSDs are 75 times cheaper than storing the data in the cloud.

As someone who works at a platform company that operates several (very) large log ingestion systems, if you're not indexing the logs usefully, having stored them on SSDs isn't doing much for you. It's just a weird comparison to make, is all I'm saying.

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.

Re: Perverse incentives of vibe coding

#227

Post by tptacek »

jiggawatts wrote: post #226
tptacek wrote: post #222

Earlier quoted context omitted.

As someone who works at a platform company that operates several (very) large log ingestion systems, if you're not indexing the logs usefully, having stored them on SSDs isn't doing much for you. It's just a weird comparison to make, is all I'm saying.

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

Re: Perverse incentives of vibe coding

#228

Post by AlexCoventry »

jazoom wrote: post #205
AlexCoventry wrote: post #134

Earlier quoted context omitted.

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

I created a script to pack it into a markdown file. Later I found this which does a better job, so I use it now. https://github.com/yamadashy/repomix

Sweet, thanks! Glad I asked.

Re: Perverse incentives of vibe coding

#229

Post by guyfhuo »

tptacek wrote: post #225
guyfhuo wrote: post #184

Earlier quoted context omitted.

This seems a self servingly literal interpretation of the op’s original comment. Clearly something like “server telemetry” is the datacenter’s “CRUD app” analogue. It’s a solved problem that largely requires rtfm and rote execution of well worn patterns in code structure. Please stick to the comment guidelines: > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's ea…

I'm laughing at the idea of server telemetry being "the data center equivalent of a CRUD app". I'll just pull out my Telemetry On Rails framework and run some generators...

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

Re: Perverse incentives of vibe coding

#230

Post by tptacek »

guyfhuo wrote: post #229
tptacek wrote: post #225

Earlier quoted context omitted.

I'm laughing at the idea of server telemetry being "the data center equivalent of a CRUD app". I'll just pull out my Telemetry On Rails framework and run some generators...

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"?
Post reply on HN