Why code still needs a mentor
AI tools have made code cheap to write, and the people who review it are drowning. We propose protecting maintainers' attention with explicit review budgets, and pairing newcomers with mentors so they learn to understand the code they submit.
Code-drafting tools now produce working code in seconds, and volunteer maintainers, who review changes and catch security flaws, are buried under automated submissions. A study of newcomers in Google Summer of Code found that when drafting becomes cheap, contributors submit plausible-looking proposals that many of them can't explain or debug.1
Review is also where newcomers used to learn the craft. If it collapses under volume, projects lose both their quality checks and their next generation of maintainers. On recognising that work, see Who gets credit for upkeep?
The invisible work of review
To see why automated drafts create such a burden, it helps to understand what a code review actually does. On the surface, reviewing code looks like proofreading. You check that the spelling is right, that the tests pass, and that the computer does not crash.
In practice, review is teaching. When an experienced maintainer comments on a proposed change, they are passing along years of hard-won institutional memory. They explain why a tempting shortcut caused an outage three years ago. They point out how a subtle choice might slow down someone with an older computer or a slow internet connection. Most importantly, they ask the contributor why they chose one path over another.
That question forces a beginner to pause, think, and understand their own work. It turns an eager newcomer into someone who can eventually guide others.
What breaks when the rehearsal room closes
When automated code submissions multiply, maintainers face hard choices. They no longer have the luxury of sitting down with a junior contributor to explain a design flaw. Instead, they spend spare evenings skimming synthetic diffs, searching for elusive bugs wrapped in confident explanations.
Eventually, maintainers tire out and step away.2 Meanwhile, newcomers rely entirely on automated tools. They never build the diagnostic intuition needed to fix broken systems. When the generator fails, they cannot diagnose why.
Over time, the entire project turns into an unreadable black box. Thousands of people and businesses rely on the software every day. Yet nobody understands its internal structure well enough to maintain it safely.
The protected workshop
Protecting open software does not mean banning helpful tools. It means treating volunteer human attention as a shared, finite commons that must be safeguarded.
First, communities are establishing contributor verification rules. Before requesting review, contributors must show they ran the program and checked edge cases. They must be able to explain every line in their own words. Putting the burden of explanation back on the author keeps careless vanity submissions out of the queue.
Second, foundations are carving out protected mentorship hours. Instead of evaluating pull requests through detached comment threads, senior maintainers pair directly with junior apprentices on small, focused tasks. The goal is not merely to merge a feature. The goal is to nurture a craftsman.
Finally, we need to remember that code is a social craft. A computer program is only as durable as the trust, care, and patience shared by the people who look after it.
- Ruizhe Xing, Zixuan Feng, Mary Radomile, Stephanie Taylor, Sophia Vargas and Anita Sarma, "Mentorship, Interrupted: How GenAI Disrupts the GSoC Pipeline and Why Mentors Matter More," arXiv preprint arXiv:2610.38167 (2026), https://arxiv.org/abs/2610.38167.
- Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software, Stripe Press (2020); see also ACM Digital Government research on maintainer burnout and cognitive load, https://doi.org/10.1145/3674805.3686667.
