Mentorship Under the AI Flood
Open source maintainers are facing a new reality. A pull request arrives that looks polished and well-intentioned, but the contributor who submitted it can't explain the reasoning behind their own changes. The code was largely generated — plausible, but not necessarily understood. Forty-five minutes of careful review later, the exchange goes nowhere.
This pattern isn't about bad actors. It's about Eternal September arriving for open source: the cost to create a contribution has plummeted, while the cost to review it has stayed exactly the same. The number of pull requests merged per month rose 23% year-over-year in 2025, according to GitHub's Octoverse report, with developers merging nearly 45 million pull requests monthly. Maintainer hours didn't scale with that volume.
Projects are already reacting. tldraw closed its pull requests altogether. Fastify shut down its HackerOne program once inbound reports became unmanageable. GitHub is working on platform-level changes and has published an RFC for community feedback, but those solutions take time. In the meantime, maintainers need to rethink how they identify who deserves mentorship when the old signals are no longer trustworthy.
Why Mentorship Still Matters
Mentorship is how open source scales. A well-mentored contributor doesn't just add their own output; they learn to mentor others, multiplying the maintainer's reach. Nearly every long-term contributor started because someone took the time to guide them.
| Year | Broadcast (1,000/year) | Mentorship (2 every 6 months, they do the same) |
|---|---|---|
| 1 | 1,000 | 9 |
| 3 | 3,000 | 729 |
| 5 | 5,000 | 59,049 |
The urgency cuts both ways. Long-time maintainers are stepping back, and without mentorship, the multiplier effect dies with them. The solution isn't to mentor everyone who sends a pull request — that path leads to burnout. It's to be strategic about who gets that investment.
A Framework: The 3 Cs
Across projects that are handling the influx well, three filters keep emerging. They can be used to decide where to spend limited mentorship energy.
1. Comprehension
Does the contributor understand the problem well enough to propose this change?
Some projects are front-loading this check. Codex and Gemini CLI both now require contributors to open an issue and get approval before submitting code, putting the comprehension check in the conversation that happens beforehand. In-person code sprints are also thriving because maintainers can gauge both interest and understanding in real time.
Nobody expects a newcomer to understand the whole project. The point is to verify that a contributor isn't committing code that's above their own level of understanding — and to adjust expectations as their grasp of the codebase grows.
2. Context
Does the contributor give the reviewer what's needed to review well?
Comprehension is about the contributor's understanding. Context is about whether you can do your job as a reviewer. Does the pull request link to the issue? Did the contributor explain trade-offs? Did they disclose that AI was used?
Disclosure policies are becoming the norm. ROOST has a simple three-principle AI policy. The Processing Foundation added a disclosure checkbox. Fedora landed a lightweight policy after months of discussion. Knowing a contribution was AI-assisted lets a reviewer calibrate — asking more probing questions about trade-offs rather than just checking whether the code happens to run.
Projects are also using AGENTS.md to instruct AI coding agents directly, much like a robots.txt for Copilot. scikit-learn, Goose, and Processing all use it to push the burden of gathering context onto the contributor, or their tools.
3. Continuity
Does the contributor keep coming back?
This is the actual mentorship filter. Drive-by patches are fine, but deep mentorship is wasted on someone who won't be around long enough to benefit. The approach can scale up incrementally:
- A good first conversation on a pull request → treat the review as a teachable moment.
- They return with more work → offer to pair or suggest harder tasks.
- They keep coming back → invite them to an event; consider commit access.
The Takeaway
Comprehension and Context get your contribution reviewed. Continuity gets it mentored. When all three are lacking, a polished pull request can be closed without guilt.
PR Lands → Follows Guidelines?
NO → Close. Guilt-free.
YES → Review → They Come Back?
YES → Consider Mentorship If someone engages thoughtfully in issues, submits a second pull request, and responds well to feedback, that's when a maintainer's attention is warranted. This rubric also reduces bias: relying on structured signals beats relying on a gut feeling about who looks like a good contributor.
| C | Implementation |
|---|---|
| Comprehension | Require issue before pull request Host an in-person code sprint for live discussions |
| Context | Add AI disclosure or AGENTS.md |
| Continuity | Watch who comes back |
AI tools aren't going anywhere. The question is whether community practices adapt to preserve what makes open source work: human knowledge transfer and the multiplier effect. A single suggested framework — starting with one of the three Cs — is a pragmatic way to start.
This isn't about barring AI-assisted contributions. It's about building guardrails so that human mentorship survives the influx.
