The Problem
Your open-source dependencies are maintained by volunteers who now spend 12 times longer reviewing AI-generated pull requests than it takes to generate them. That's not a productivity gain. That's a crisis.
The debate isn't whether AI can help with code contributions. It's whether the current flood of low-quality, AI-generated submissions is destroying the open-source ecosystem faster than it's adding value. With 96% of commercial codebases containing open source and 60% of maintainers working unpaid, this question has real consequences for your security posture.
AI-Assisted Contributions: A Balanced Approach
AI code generation tools can help contributors. A developer using GitHub Copilot to write a bug fix still reviews, tests, and owns that code. The AI accelerates the work, but human judgment remains central.
Some valid use cases exist. Documentation updates, routine refactoring, and standardization tasks benefit from AI assistance. A contributor might use an LLM to generate initial boilerplate for a feature request, then spend hours refining it to match the project's architecture and coding standards. The AI serves as a starting point, not the endpoint.
Platform tools are improving detection. GitHub recently introduced features to flag likely AI-generated content, giving maintainers visibility into submission patterns. If you're a project lead, you can now set contributor guidelines that explicitly address AI usage, requiring disclosure or limiting AI-generated submissions to specific contexts.
The open-source model has always absorbed noise. Projects receive low-quality human contributions too. Maintainers already triage issues, close duplicate bug reports, and reject incomplete pull requests. AI-generated slop might just be the latest category of noise to filter.
The Case for Restricting AI Submissions
The math doesn't work. When reviewing a pull request takes 12 times longer than generating it, you've created an asymmetric attack on maintainer time. A single person with an LLM can overwhelm a project with dozens of plausible-looking but fundamentally broken submissions. The Python Software Foundation's chairperson has described exactly this scenario playing out in real projects.
Quality isn't the only issue. Security is. AI-generated code can introduce subtle vulnerabilities that pass automated tests but fail under adversarial conditions. Your security review process assumes contributors understand the code they're submitting. When someone pastes LLM output without comprehension, that assumption breaks. You're now reviewing code nobody actually understands.
The burden falls on volunteers. Remember that 60% of maintainers are unpaid. They're already stretched thin. Adding hours of AI slop review to their workload doesn't just slow development. It burns people out and drives them away from projects entirely. When a critical library loses its maintainer because they're tired of reviewing garbage, your supply chain risk just increased.
AI submissions undermine trust. Open source works because contributors build reputations over time. You learn who writes clean code, who tests thoroughly, and who understands the project's architecture. AI-generated contributions bypass this reputation system. Every submission requires full scrutiny because you can't trust the submitter's judgment.
Finding Common Ground
Most security engineers aren't opposed to AI tools. They're opposed to AI replacing human judgment in security-critical decisions.
The practical middle ground looks like this: AI as an assistant, not a contributor. If you're using Copilot to write code faster, that's fine. But you review it, test it, and put your name on it. The contribution is yours, not the AI's.
Some projects are adopting explicit policies. They require contributors to disclose AI usage and certify they've reviewed and understood any AI-generated code. This shifts accountability back where it belongs while allowing AI as a productivity tool.
Platform-level solutions matter too. GitHub's AI detection features help, but they need teeth. Projects need the ability to automatically reject submissions that match AI-generated patterns, or to require additional review steps for flagged content. The platform should make it easier to maintain quality, not harder.
Our Recommendation
Ban AI-only submissions. Allow AI-assisted contributions.
The distinction matters. If you used an LLM to draft a function but then spent an hour refining it, testing edge cases, and ensuring it fits the project's architecture, you've created value. If you pasted ChatGPT output and submitted it without understanding what it does, you've created risk.
For security engineers managing open-source dependencies, this means updating your contribution policies now. If you maintain internal forks or contribute to upstream projects, add clear language about AI usage. Require disclosure. Require comprehension. Make contributors certify they understand and have tested their submissions.
For compliance teams, this affects your supply chain risk assessments. When evaluating open-source dependencies, look at maintainer health. Are they drowning in low-quality submissions? Are they losing contributors to burnout? A well-maintained project with strict contribution standards is more secure than one accepting everything that comes through the door.
The open-source model depends on trust and shared understanding. AI slop erodes both. You don't have to oppose AI tools to recognize that flooding volunteer maintainers with machine-generated code they didn't ask for is unsustainable.
Set the boundary now. AI assists. Humans contribute.
