> Not sure what to do now. I really want to help my user, but I don't like this code in my codebase.
If you don’t want to accept the PR, don’t. It’s still your project. Reject it politely. Tell them why you don’t feel comfortable accepting it (too many changes at once; impractical to review; general distrust of LLM code; …) but remind them that “of course, if you want to keep that in your own fork, you’re more than welcome”. I’ve been doing that for years (way before vibe coding was a thing) and was always able to keep good relations with my users.
Be polite and make sure they understand your rejection is not an indictment on their submission, while reassuring them that the effort was not wasted because they can keep it for their own use if they really want it that bad.
> This morning, I received another message from another user who is about to submit one more feature.
When you write the message for the first user, try to also make it generic enough (i.e. about the project, not their specific submission) that you can link to it for other users.
> The person is a long-time user and is very enthusiastic about the app.
Can this person program?
---
I agree with the the other comments. Anyway, which project? language-learning-tool?
Do you like the general idea of the PR? Is it possible to split the PR in a few smaller one? Is it possible to merge one part and keep it disabled by default for most users?
To be honest, I'm not a fan of the PR's general idea.
> Is it possible to merge one part and keep it disabled by default for most users?
This is exactly what I am about to do. To merge a small part of that PR into my repo. That part conducts communication between the web app and the proposed extension, so the author of the PR can use my APIs while keeping most of their code in their fork.
I am actually glad that I created this thread. Thank you for responding to it.
General rule... you have zero obligation to merge any code to your repo, much less bad code, or very large hard-to-review submissions.
I think that it's bad manners for someone to submit a big PR without prior experience with the project. Someone needs to earn trust over time. They might start out with a few small PRs and gradually build up to the point where you might trust them with a larger change. But even so, a 4k-line PR is very unreasonable.
I ususally do, but sometimes I don't. Most of the time I will, but there's always a chance that I just won't allow vibecoded submissions in my program. I think that that's the answer you were looking forward to. Nothing actually matters, y'lnow.
> Someone has submitted a 4k-line PR to one of my projects.
That wouldn’t be reasonable even if it weren’t vibe coded.
> The person is a long-time user and is very enthusiastic about the app.
Be careful. Don’t let yourself be pushed into an XZ-type situation.
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
> Not sure what to do now. I really want to help my user, but I don't like this code in my codebase.
If you don’t want to accept the PR, don’t. It’s still your project. Reject it politely. Tell them why you don’t feel comfortable accepting it (too many changes at once; impractical to review; general distrust of LLM code; …) but remind them that “of course, if you want to keep that in your own fork, you’re more than welcome”. I’ve been doing that for years (way before vibe coding was a thing) and was always able to keep good relations with my users.
Be polite and make sure they understand your rejection is not an indictment on their submission, while reassuring them that the effort was not wasted because they can keep it for their own use if they really want it that bad.
> This morning, I received another message from another user who is about to submit one more feature.
When you write the message for the first user, try to also make it generic enough (i.e. about the project, not their specific submission) that you can link to it for other users.
Thank you so much!
> The person is a long-time user and is very enthusiastic about the app.
Can this person program?
---
I agree with the the other comments. Anyway, which project? language-learning-tool?
Do you like the general idea of the PR? Is it possible to split the PR in a few smaller one? Is it possible to merge one part and keep it disabled by default for most users?
Yes, it's the language-learning-tool.
> Do you like the general idea of the PR?
To be honest, I'm not a fan of the PR's general idea.
> Is it possible to merge one part and keep it disabled by default for most users?
This is exactly what I am about to do. To merge a small part of that PR into my repo. That part conducts communication between the web app and the proposed extension, so the author of the PR can use my APIs while keeping most of their code in their fork.
I am actually glad that I created this thread. Thank you for responding to it.
General rule... you have zero obligation to merge any code to your repo, much less bad code, or very large hard-to-review submissions.
I think that it's bad manners for someone to submit a big PR without prior experience with the project. Someone needs to earn trust over time. They might start out with a few small PRs and gradually build up to the point where you might trust them with a larger change. But even so, a 4k-line PR is very unreasonable.
Vibecoding tools have attracted many non-technical people who are unfamiliar with PR etiquette.
There will likely be way more PRs like the one I described in the future.
I ususally do, but sometimes I don't. Most of the time I will, but there's always a chance that I just won't allow vibecoded submissions in my program. I think that that's the answer you were looking forward to. Nothing actually matters, y'lnow.
I was confused and wanted to get some validation and connection — a human thing. Thank you for sharing your experience.
What if the feature was coded by hand?
Good question. I would've rejected it. This answers my original question.
But it's hard to imagine someone spending so much time coding without coordinating with the maintainer.