越来越多的开源项目正明确禁止由人工智能生成的贡献，以保护其代码库的完整性和可维护性。这一转变是由“氛围编码”提交的激增驱动的——这类代码看起来功能正常且美观，但缺乏生产软件所需的严格测试、安全审计和深层的架构理解。
“氛围编码”垃圾的兴起
项目 'osssaysno.com' 突显了一个趋势，即维护者正在拒绝那些看起来是由大语言模型（LLMs）生成的贡献。一位以 koalalorenzo 为名的评论者将这些描述为“氛围编码”项目，其重点在于“外观”和“感觉”，而安全问题仍未解决，因为“LLM 永远是正确的”。
另一种观点认为，问题不在于 AI 本身，而在于缺乏人类的责任感。Hacker News 上的评论者辩称，真正的问题在于当贡献者未能承担阅读、测试和理解他们提交的代码的责任时，无论代码是由人类还是 AI 编写的。
保护维护者的心理健康
维护者正面临社区互动量（包括 issue 和 pull requests）的显著增加，这面临着让项目管理者倦怠的风险。一位评论者 Arbortheus 指出，难点在于区分那些理解问题领域的贡献者与那些拥有“LLM 诱发的荷兰勇气”的贡献者。
通过禁止 AI 生成的贡献，维护者旨在为“增加价值”建立更高的门槛。一位评论者 Systemerror7A69 认为，在过去，一个可行的解决方案是贡献者思考过程的证据；而有了 LLM，这种思考往往被外包，使得维护者更难识别高质量的输入。
权衡与执行挑战
禁止 AI 的举措并非没有争议。一些评论者认为这些禁令是“懒惰的”，并且可能会赶走潜在的贡献者，特别是对于缺乏资金支持的社区驱动项目。他们建议重点应保持在贡献的质量上，而不是用于创建它的工具。
此外，在执行方面也存在实际担忧。一位评论者 ChrisRR 建议，禁止 AI 代码可能会导致贡献者谎称他们没有使用 AI。他们提出了一种折中方案：允许使用 AI，但人类贡献者必须对最终输出承担全部责任。
此外，一些人认为，为了寻找漏洞而避免使用 AI 可能会使软件变得更脆弱。一位评论者 jonathanstrange 警告说，由于攻击者将使用 AI 来寻找漏洞，仅由人类编写的代码最终可能被认为安全性较低。
AI 集成的细微差别
并非所有项目都采取全面禁令。一些维护者区分“外部”AI 贡献（即机器人或非专家提交代码）与“人类引导的智能体编码”。一位评论者 jdzikowski 指出，如果 AI 代码由深入了解项目架构的人签署，项目可能会更信任这些 AI 代码。
讨论还揭示了一些项目正在寻找中间路径。例如，一位评论者指出，虽然一个项目可能不接受 LLM 生成的拉取请求，但它仍可能在内部使用 AI 智能体来进行共同作者提交或执行特定任务。