作者花费约100小时，确保git-annex的依赖中不含大模型生成代码，并发现了一些质量低劣的依赖。他认为这如同逆水行舟，但仍在坚持工作并支持用户。

在过去一个月里，我投入了约100小时的工作，确保git-annex能够在不包含由大语言模型生成代码的依赖项下构建，至少目前如此。为此，我不得不持续审查整个依赖树，这似乎成了编程的常态。我发现了一些严重问题：大型LLM生成的变更在下一版本中被无故回滚；一个1489行的混乱提交信息伴随着对26000行代码库的10000行修改；还有一份LLM提示从其他项目复制代码，仅因运气才避免了版权侵权。这些经历让我对依赖项的质量有了更多了解，这无疑会影响未来的决策——在我看来，这是这项工作的唯一积极成果。我意识到自己可能是在逆流而上，这似乎是软件自由保护组织放弃努力的原因，而自由软件基金会恐怕也难有作为。随着这些多米诺骨牌倒下，我正在重新考虑是否继续参与这些社区，但我仍会继续工作并支持我的用户。用LLM生成“添加fourmolu配置并重新格式化模块”这样的代码并提交，或许能让你自诩为10倍效率开发者，但请考虑你行为的更广泛影响——在上述案例中，那个项目因此失去了我的进一步合作。

根据评论内容，总结如下：

主要观点与论据：

1. 支持禁止LLM代码的立场（评论4、6）：

   • 认为AI生成代码（"AI slop"）对开源项目构成严重风险，需要高度警惕，可能徒劳无功。
   • 建议开源项目设置PR付费墙（10-100美元/PR）以覆盖审查成本，或减少依赖数量（如限制5个）。
   • 评论6表示支持者"不会被人怀念"。

2. 反对或质疑该立场的观点（评论5、8、12）：

   • 评论5指出，若因此放弃git和ghc等广泛使用的工具，不切实际，用户会等待fork。
   • 评论8认为在当今技术环境下，不借助LLM工具无法保证安全性和开发速度。
   • 评论12质疑：LLM代码与中低级开发者代码难以区分，而后者已被广泛接受，甚至被欢迎。

3. 中立或技术性建议（评论2、3）：

   • 评论2建议开发工具通过启发式方法检测LLM生成代码，而非仅依赖提交信息。
   • 评论3认为新技术探索中难免犯错，不应因单一提交和回滚就全盘否定，应关注依赖模式。

4. 对开源生态的反思（评论4、11）：

   • 评论4怀疑"免费软件"的动机，认为陌生人赠送礼物需警惕，并已自托管代码库。
   • 评论11指出社区对此问题已如美国政治般两极分化。

关键引用（保留中英文）：

• 支持禁止：评论4 "I think OSS projects are at serious risk of implosion due to the vigilance required" / "我认为开源项目因所需警惕而面临崩溃风险"
• 反对禁止：评论5 "If I have to choose between this or git and the latest ghc, I think I'm going to just wait for someone to fork annex" / "如果必须在这（禁止LLM代码）和git、最新ghc之间选择，我会等待有人fork annex"
• 技术建议：评论2 "I think it would be interesting/useful to have a tool that could use some basic heuristics about LLM generated code" / "我认为开发一个工具，利用基本启发式方法检测LLM生成代码会很有趣/有用"
• 反思开源：评论4 "Beware of strangers bearing gifts" / "警惕陌生人赠送礼物"