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

Please Do Not Vibe Fuck Up This Software

github.com

Post reply on HN
Print view View original

371–380 of 534 posts

Re: Please Do Not Vibe Fuck Up This Software

#371

Post by soerxpso »

eudamoniac wrote: post #310
themgt wrote: post #196

Earlier quoted context omitted.

Opening an issue consisting only of some twitter clone screenshot with some "literally who" who found a bug called "Please Do Not Vibe Fuck Up This Software" ain't it. That's not a way to tell a maintainer that you disagree with the direction they're taking. This issue is entirely useless. A "fucked up vibe coded" bug report would have been better. This nailed it. None of the bug reports even attempt to document the…

They're not mad about the bug, they're mad about the cause of the bug. This is like city council starts flinging stones with a trebuchet into streets, and you're expected to calmly file pothole reports instead of complaining about the trebuchet.

Bugs exist in human code too. The AI derangement crowd pounces on any small bug as evidence that AI is a trebuchet, and thinks that if only we didn't use AI there would never be any bugs (like five years ago when all software was perfect, was not being enshittified, and had 0 bugs).

Re: Please Do Not Vibe Fuck Up This Software

#372

Post by akerl_ »

dragontamer wrote: post #370
akerl_ wrote: post #361

Earlier quoted context omitted.

This is not a professional setting. This is an open source project that somebody published to the internet. Using it does not make you a customer, and it doesn’t matter if it “struck a nerve” with users.

Well in my professional setting, I deal with non-paying customers all the time. They're still customers and I'm still expected to listen to them. It was better when a dedicated PM was shielding me from this crap but here we are. Deciding who and who not to listen to is just part of project management.

Sure. But an open source project is not a professional setting.

Re: Please Do Not Vibe Fuck Up This Software

#373

Post by soerxpso »

hashmap wrote: post #296
daishi55 wrote: post #286

This anti-AI hysteria is just such a classic moral panic. It’s just 1) identify something as AI-produced 2) attack and ostracize anyone who might be involved in that production And as with all moral panics, whether (1) is factual is totally beside the point. The point is the almost sexual release you get from (2). I know in this case there is AI-produced code in rsync (as there is with most useful software by now), b…

it's dangerous to refuse to understand whats happening broadly, and what's taking place in this thread, and to signal that it's ok to keep refusing to understand it. the anger that's showing up around ai isn't a matter of the masses being misinformed, or the messaging around it, it's a matter of physics. you have this one thing that is being used as an excuse to lay people off en masse, you have tech ceos near daily…

If you think you're owed a salary to do something that a simple machine can do, I have a field for you to plow by hand.

Re: Please Do Not Vibe Fuck Up This Software

#374

Post by Nasrudith »

christkv wrote: post #74

Can GitHub add a tag to repositories that says "probably vibe coded" or "ai code detected"

Requesting an AI code detector is peak cognitive dissonance. "AI automation is bad and I can always tell. That is why I need to have a tool to discriminate its presence so I can exclude it!" Split-brain patients have less post-hoc rationalization.

Re: Please Do Not Vibe Fuck Up This Software

#375

Post by customguy »

cinntaile wrote: post #266
kdjkskdndn wrote: post #83

Earlier quoted context omitted.

Claude sonnet 4 (this time last year) did do this. It once made simulation if a test script passing. Literally a script that just echoed test names and then said pass.

Change happens fast, a year old model is pretty outdated. I'm sure it can happen, hence why I said to keep an eye out. Its main mode of operation is not to cook the tests however.

> Change happens fast, a year old model is pretty outdated.

What change? That you should not fake the results of a test because that defeats the whole purpose of a test has been known before there were computers.

Re: Please Do Not Vibe Fuck Up This Software

#376

Post by sarlalian »

123ahsg6 wrote: post #281
thevinter wrote: post #116

This whole brigading is bizzarre and some people are behaving like irrational animals. I potentially understand the motivations that might bring one to want to "win" this battle but this really isn't it - it just makes you sound like a fanatic. It takes 5 minutes to search for "regression" on the issue page and go through the 17 results. There are potentially even more on the tracker used prior to github. I think thi…

The way it is done with meme pictures is bizarre. The language used is the same that Tridgell knows from the LKML, so that is not the primary concern. How are maintainers supposed to know that users don't trust AI if no one voices that concern? rsync was very stable. Should people silently move to Openrsync and never say anything?

How are the maintainers supposed to know that the users don’t trust VS Code if no one voices their concerns like a rabid mob? Seriously why should the maintainer care what users think about how they produce code?

Bugs happen, regressions happen regardless of whether it’s human or AI written. The only valid criticism is that he’s moving too fast for quality code review by others. That said, I bet if you search through the issues you’ll find multiple places where users have complained about their bug staying open for too long without being addressed.

Re: Please Do Not Vibe Fuck Up This Software

#377

Post by dragontamer »

akerl_ wrote: post #346
lukaslalinsky wrote: post #343

Earlier quoted context omitted.

Look, it's not that long time ago when we had the xz malware. The pattern is always the same. Maintainer of the project is doing X, people start to pressure them to do something else, maintainer gives up and opens the project up to other maintainers, and then many things can happen. If there is any lesson from the incident, open source maintainers should never allow the pressure to happen, ignore it if it's too stron…

If I were the rsync maintainer I’d probably set the repo to only allow issues and PRs from prior contributors until people learn to behave.

Yes. That's called firing the customer in my line of work.

This doesn't seem egregious enough to fire the customer.

Re: Please Do Not Vibe Fuck Up This Software

#378

Post by tpm »

pishpash wrote: post #340
krcz wrote: post #272

Earlier quoted context omitted.

Or no one is to blame, if the mechanism of the regression is complex and non-obvious based just on the patch itself.

Or they are to blame because they misplaced responsibility in a tool's universality to not introduce regressions, even complex and non-obvious ones.

or they are not to blame because they accepted the possibility of a regression when fixing 6 CVEs

Re: Please Do Not Vibe Fuck Up This Software

#379

Post by sarlalian »

koehler wrote: post #36

I truly don't get it You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes. Why do we need AI here? And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched.…

Because all software has bugs, because the system underlying that software changes and you need to keep up, because for some people it’s just missing that one feature or doesn’t work quite right in that one edge case. I’d bet that there are issues in the backlog with people’s complaining that their issue isn’t being addressed quick enough.

Is AI the problem, or that it had a regression? Is the regression actually caused by AI?

Re: Please Do Not Vibe Fuck Up This Software

#380

Post by akerl_ »

dragontamer wrote: post #377
akerl_ wrote: post #346

Earlier quoted context omitted.

If I were the rsync maintainer I’d probably set the repo to only allow issues and PRs from prior contributors until people learn to behave.

Yes. That's called firing the customer in my line of work. This doesn't seem egregious enough to fire the customer.

Again, this is not work and they are not customers.

This is somebody spending their free time on code they enjoy and then putting the result online.

The reason businesses are careful about which customers they fire is because they want to keep having customers. Open source maintainers have no reason to deal with that shit.

Post reply on HN