| I don’t know the details of this exact instance, but saying that there are reliability issues is a valid feedback if reliability plummets. As far as I know, nobody with data claims that vibe coding doesn’t affect reliability negatively. People will connect these two things. Many times, when reliability doesn’t plummet really. For example, there were huge negative news about a Samsung phone a few years back, that it easily causes fires. Sales were affected by this. Interestingly, next year, they released basically the same thing under different name, and complains were never that loud again. And as far as I know, when they were loud, there was nothing special about that particular model regarding this. So it’s possible that outrage is not validated at all. They will also connect these, when reliability plummets, but it’s not because of vibe coding. And they will connect, when it is the real culprit in general, but their problems are not affected by vibe coding. And of course also when vibe coding really causes their problems. In any case, the original statements will be true. Do we really want to make a product less reliable to implement features and bugs which we deemed not that important before? Especially with a stable product? Of course, these on the maintainers, but it’s interesting that forcing AI and their consequences on us - like how Microsoft, Google, etc do - is the default, and not the other way around according to many in this thread and others. |
And the maintainer can then choose to use that feedback to incorporate it into the workflow, on their own time. If they so choose (which I'm sure they will, unless they get burnt by the community right now).
I think we agree.