The distinction that matters is whether the contributor can defend their work in review, not what tool produced it.

I maintain a 300-commit fork built with heavy AI assistance. The AI writes a lot of the code. I review every line and can explain every choice. The test: can they respond to feedback, explain why they chose this approach over the simpler one, iterate on edge cases? That works regardless of how the code was produced.

Debian's problem isn't AI. It's distinguishing "used a tool well" from "dumped output." Code review already does this. Tighter process for new contributors (smaller patches, demonstrated understanding through review conversation) filters on engagement quality, not tool choice.