> 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.
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.
> 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.
Honestly I reached a point where I was getting pull-requests which were best characterized as "AI spam", I just archived all of them.
Every single one of my public github repositories is archived and no longer updated.
I have projects I work on, but I keep them to myself. I've just lost interest in wasting time on issues and submissions from people - which is a depressing position to be in, because most of the time people mean well, and over the years I've definitely benefited from contributions of many interested and skilled people.
I created this thread thinking that AI is definitely going to shake the open-source world, and I wanted to know how people deal with AI-slop PRs.
Thank you for sharing your experience. I am not an open-source rockstar, and I have only had to reject PRs a few times in my life. All the times I felt terrible for people who put in some effort to build something around my code and got rejected.
Even if you reject their changes remember they have their own fork, and they can keep using it locally. Sure they have to keep updating their local work if you don't include it in your repository, but that's a small price to pay. After all if you hadn't made your code available in the first place nobody would be using it, modified, or unmodified.
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.