Lots of infected programs provide value. It has nothing to do with being or not being infected.
If a project was vibecoded in a weekend - there are less chances that it will still be maintained in a, say, year or two.
I'm definitely not going to jump in on a vibe-coded project. I'd much rather start from scratch if I found the use-case to be relevant.
Not to say vibe-coded projects can't be alright. If the engineer behind it knows their stuff, it's fine to me. But we don't know that. So to get a general idea, I think it's fair to ask how this was done.
These concerns were great valid even before vibecoding becoming a thing, but now the estimated probabilities of malicious code's presence have changed, simply because nowadays the cost/effort of writing software plummeted.
So, permissions are always going to be more general than what a program actually needs and, therefore, exploitable.
Producing incorrect information is an insidious example of this. We can't simply restrict the program's permissions so that it only yields correct outputs -- we'd need to understand the outputs themselves to make that work. But, then, we're in a situation where we're basing our choices on potentially incorrect and unverified outputs from the program.