If you maintain an open source project long enough, you'll meet the drive-by contributor. They open a PR, you leave feedback, and they're gone. Profile says 847 contributions yesterday. You close the PR. Nothing changed except you spent 45 minutes reviewing code that was never going anywhere. This post is about that pattern, why it happens, and how to not be that person.
Someone opens a pull request with no intention of seeing it through. No response to feedback. No follow-up. Just a PR sitting in your queue like a parking ticket you can't do anything about.
The modern version of this is almost always AI farming. The workflow goes: point an LLM at a repo, tell it to find something to fix, submit the output, repeat across 40 repos, collect GitHub contribution squares. The contributor has never run the code. They've never read the tests. Half the time they haven't even read the PR description they submitted.
The tell is usually the GitHub profile. When someone has made 600 contributions in the last two days across repositories they've never interacted with before, the math doesn't add up.
The PRs are easy enough to close. The cost is the time before you close them.
Reading a PR takes effort. Understanding what it's trying to do, whether it's correct, what's missing. When you leave detailed feedback and get nothing back, that effort evaporates. Multiply that by a few drive-by contributors and you've burned a Sunday afternoon on people who weren't paying attention.
There's also the queue problem. Open PRs feel like obligations. A backlog of stale drive-by PRs creates overhead and makes the project look unmaintained to contributors who are actually interested.
Read the contributing guide. This filters out most problems before they start.
Open an issue before writing code on anything non-trivial. Find out whether the maintainer wants the change at all. The worst outcome is a PR that gets closed because it goes against the project direction and you didn't check first.
Only open a PR you're prepared to iterate on. Feedback is not optional. If a maintainer asks you to change something, that's part of the deal.
If you used AI to write the code, read it. Understand it. Be able to explain what it does. AI-assisted PRs are fine. PRs where you are functionally a relay between an LLM and a stranger's repository are not. One PR at a time to the same repo. Opening five simultaneously signals that you're optimizing for volume.
Using AI to help you contribute is fine. The problem is when the AI is doing the contributing and you're just hitting submit. The difference is whether you've actually engaged with the code. Did you run the tests? Do you know why the change works? Can you respond if the maintainer pushes back? If the answer to any of those is no, the PR isn't ready.
Maintainers can usually tell. The code compiles but doesn't fit the patterns in the rest of the codebase. The PR description is fluent but generic. The contributor profile is a wall of green from the last 48 hours. It's not subtle.
Say this explicitly in your contributing guide. "No drive-by PRs" is a complete sentence. Set a response deadline. Close stale PRs without guilt. The contributors worth having will read your guidelines. The ones who won't are exactly the ones this policy is for.
If you made it this far, I'm working on an open source project called AudioTrove. The goal is to make tinkering with Voice AI models easier for everyone. Take a look if that sounds interesting, and a star on the repo would mean a lot :)