A growing number of open-source projects are explicitly banning contributions generated by artificial intelligence to protect the integrity and maintainability of their codebases. This shift is driven by a surge in 'vibe-coded' submissions—code that appears functional and aesthetically correct but lacks the rigorous testing, security auditing, and deep architectural understanding required for production software.
The Rise of 'Vibe-Coded' Slop
The project 'osssaysno.com' highlights a trend where maintainers are rejecting contributions that appear to be generated by large language models (LLMs). One commenter, writing as koalalorenzo, described these as 'vibe-coded' projects where the focus is on 'looks' and 'feels' while security issues remain unaddressed because 'an LLM is always right.'
Another perspective suggests that the issue is not the AI itself, but the lack of human accountability. Commenters on Hacker News argued that the real problem is when contributors fail to take responsibility for reading, testing, and understanding the code they submit, regardless of whether a human or an AI wrote it.
Protecting Maintainer Sanity
Maintainers are facing a significant uptick in the volume of community interactions, including issues and pull requests, which risks burning out those who manage the projects. A commenter, Arbortheus, noted that the difficulty lies in distinguishing between a contributor who understands the problem domain and one with 'LLM-induced Dutch courage.'
By banning AI-generated contributions, maintainers aim to create a higher threshold for 'adding value.' One commenter, Systemerror7A69, argued that in the past, a functioning solution was evidence of a contributor's thought process; with LLMs, that thinking is often outsourced, making it harder for maintainers to identify high-quality input.
Trade-offs and Enforcement Challenges
The move to ban AI is not without controversy. Some commenters argued that these bans are 'lazy' and could drive away potential contributors, especially for community-driven projects that lack funding. They suggested that the focus should remain on the quality of the contribution rather than the tool used to create it.
There is also a practical concern regarding enforcement. One commenter, ChrisRR, suggested that banning AI code might lead to contributors lying about their usage. They proposed a middle ground where AI may be used, but the human contributor must hold full responsibility for the final output.
Furthermore, some argue that avoiding AI for bug hunting could make software more vulnerable. A commenter, jonathanstrange, warned that since attackers will use AI to find exploits, human-only code might eventually be considered less safe.
Nuance in AI Integration
Not all projects are adopting a blanket ban. Some maintainers distinguish between 'external' AI contributions—where a bot or a non-expert submits code—and 'human-guided agentic coding.' A commenter, jdzikowski, noted that projects may trust AI code more if it is signed off by someone who deeply understands the project's architecture.
The discussion also revealed that some projects are finding middle paths. For example, one commenter pointed out that while a project might not accept LLM-generated pull requests, it may still use AI agents internally for co-authored commits or specific tasks.