Skip to content
All articles

Open source · AI · Mentorship

Open source was the way in. AI slop is closing the door.

Maintainers are restricting pull requests to cope with low-quality AI contributions, and newer developers are paying for it. What changed, and how contributors and maintainers can rebuild trust.

If you can't get hired as a developer, someone will tell you to contribute to open source. It has been the standard advice for years, and it's how a lot of people got their first real code review. You found a project, picked up an issue, and a maintainer you'd never met took the time to explain what was wrong with your pull request.

That advice is running into trouble this year. Maintainers are buried in AI-generated pull requests, and some of the ways they're protecting themselves also shut out the people the advice was meant for.

What maintainers are dealing with

In October, Linux Foundation Research published a survey of open-source projects. Maintainers estimated that 25% of incoming pull requests are low-quality AI output, rising to 31% on large projects, and 59% said contribution volume had grown since generative AI took off. The pile grew. The number of reviewers didn't. Read the Linux Foundation survey summary.

Godot's maintainers called the flood "draining and demoralizing" back in February. GitHub summed up the problem in a post the same month: Read The Register's report on Godot.

"The cost to create has dropped but the cost to review has not."

The doors that are closing

GitHub now lets maintainers limit pull requests to collaborators or turn them off entirely, and since June they can cap how many pull requests an outside contributor has open at once. Some projects run bots that close suspected AI pull requests automatically. Each of these is a reasonable response, and with a busy repository I'd probably do the same. Read GitHub's post for maintainers.

GitHub was honest about the cost, though: "Restrictions can disproportionately affect first-time contributors acting in good faith." That's the part that worries me. Entry-level hiring is already thin, and open source was the backup route. If the backup closes too, a newer developer has very few places left to get feedback from someone more experienced. Where newer developers get experience now.

The hiring side has a number on it now. In August, Stanford's Digital Economy Lab reported that employment of 22 to 25 year olds in the most AI-exposed jobs is 19% below where it would be if it had kept pace with less-exposed peers. Experienced workers show no such gap. Read the Stanford paper.

The problem is trust, not AI

Maintainers aren't closing pull requests because someone used AI. Most of them use it too. They're closing pull requests that nobody stands behind. When a maintainer can't tell a learner from a generator, closing the pull request is the cheapest thing they can do.

One finding in the Linux Foundation survey is easy to miss. 46% of maintainers said generative AI increases the need to mentor new contributors, and only 32% said it decreases it. Maintainers aren't asking for fewer newcomers. They want newcomers they can teach.

What contributors can do

  • Read the project's AI policy before you write anything, and ask if there isn't one.
  • Agree on an approach in the issue before you open a pull request.
  • Keep pull requests small enough that you can explain every line with the AI tool closed.
  • Say how you used AI, in one plain sentence.
  • Answer review comments yourself.
  • Stay with one project instead of spreading pull requests across twenty.

I wrote up the details in a new guide. Using AI on an open-source contribution.

What maintainers can do

Turning pull requests off stops the flood. It also stops your next regular contributor. A middle path is to keep the front door narrow and open a side door for a few people you choose: publish an AI policy, write acceptance criteria into a handful of issues, and invite a small number of contributors into that work with a named reviewer. It's less review than an open queue, and every hour of it goes to someone who is actually learning.

Where Devprentice fits

That side door is what we're building. A Devprentice program runs in a public GitHub repository. Before anyone joins, the maintainer sets the milestones, the acceptance criteria, the reviewer, and the AI policy, then decides whom to invite. Review stays human. At the end, the contributor can choose to share a Contribution Record that links the agreed work, the feedback, and how they responded to it. See how it works for maintainers.

We're in a private pilot and looking for open-source projects to join as design partners. If your repository is drowning in pull requests and you'd still like to bring a few people along, start with our guide on shaping a program: Turn your backlog into a contributor program.