大型开源项目的维护者正遭受AI生成低质代码（AI slop）的严重冲击。Linux基金会针对234名开源贡献者和维护者的调查显示，在管理拥有超过50名贡献者的项目中，近三分之一的代码变更请求被评估为质量低下或由AI生成。目前，维护者对职业倦怠的担忧已超越代码质量本身。
在所有受访项目中，这一比例约为四分之一。每一份“拉取请求”（pull request）均需人工审查后方可合并或拒绝，而队列中的大量低质代码严重挤占了维护者维持项目正常运行的精力。
项目规模越大，负担越重
尽管大型项目拥有更多潜在审查者，但其报告的低质代码数量最多、提交增长速率最快，关于审查流程拖沓的投诉也最为集中。大多数维护者表示，自生成式AI兴起以来，收到的贡献显著增加。小型项目仍主要担忧代码质量，而在大型项目中，职业倦怠已跃升为首要问题。
治理规范普遍缺失
仅约三分之一的项目制定了允许AI辅助贡献的正式政策，十分之一的项目明确禁止此类行为，其余项目要么缺乏书面规定，要么尚在制定中。现有政策大多要求贡献者披露AI使用情况，并对代码质量负责。
在缺乏规则的情况下，维护者多依赖传统方式：信任熟悉贡献者或亲自阅读代码，约四分之一的项目甚至完全没有审查机制。与此同时，四分之三的维护者选择“以火攻火”，利用AI工具协助筛选传入内容，用于总结变更或查找逻辑漏洞。
贡献者自查严谨，但披露不足
开发者端的表现优于预期。六成贡献者表示，提交前会逐行检查AI生成的代码并进行全面测试，承认未加检查即提交者寥寥无几。然而，在披露AI参与度方面一致性较差，约五分之一的人从未提及。作为参考，Linux内核已要求在提交信息中添加“Assisted-by:”字段，注明所用AI工具和模型。
效率提升有限，社区信任受损
用户称AI大致将编码时间减半，审查时间减少40%以上，但随着任务复杂度增加，效率增益递减。在最复杂的任务中，约五分之一的开发者表示AI反而拖慢了进度。
社区层面也付出代价。多数维护者认为AI降低了新人参与门槛，但超过半数表示AI并未改善社区内部信任度。更多人指出，新贡献者需要额外指导，这进一步加重了本就不堪重负的维护者的负担。
cURL项目提供了解决问题的范例。2025年，项目负责人Daniel Stenberg曾描述该项目被AI生成的低质漏洞报告淹没。至2026年4月，他表示项目已“不再收到AI低质安全报告”，转而收到“越来越多真正优质的安全报告，几乎全部是在AI帮助下完成的。”