依赖中不使用 LLM 代码

原文 ↗ Hacker News 讨论 ↗

LLM 生成代码的检测

  • 有些人希望工具使用启发式方法标记 LLM 生成的提交：带有大量注释的大块代码、每小时异常高的代码行数，以及基于 LLM 时代之前仓库训练出来的提交风格。
  • 也有人认为“AI 检测”本质上不可靠，类似测谎仪，并警告会有很高的误报率。
  • 还有一种更温和的观点：检测不需要完美——只要足以把“明显”的案例挑出来供人工复核即可。
  • 像检查提交共同作者标签这样简单的启发式方法，被认为是触手可及的低垂果实。

不依赖 LLM 的可行性

  • 一方认为拒绝带有 LLM 痕迹的依赖项是一种有原则但可能不切实际的立场，尤其是在它会阻止关键工具和语言的新版本时。
  • 另一些人则认为这是防御“AI 垃圾”的合理方式，即使这意味着更多工作、冻结依赖，或减少依赖数量。
  • 也有人意识到，从长远看这可能会变得不可持续，并可能迫使人们在纯粹性与获取语言/工具改进之间做出权衡。

OSS 治理与贡献政策

  • 有人建议：完全不接受外部贡献、对 PR 收费以资助额外审查，或迁移到“AI-free”托管。
  • 也有人认为，开源可以在保持开放的同时 פשוט拒绝 LLM 生成的补丁；不同意的用户可以选择 fork。
  • 一个反复出现的担忧是，低质量 AI PR 会让维护者精疲力竭，而志愿项目可能会因审查负担而“崩掉”。
  • 还有几条评论强调，指导年轻的人类开发者（他们可以成长为维护者）与审查 LLM 输出之间有质的区别，因为后者不会给社区带来长期收益。

LLM 代码与人类代码的质量

  • 一派声称 LLM 类似中低水平开发者，只要使用得当就会有用；问题在于草率的使用者，而不是工具本身。
  • 批评者则说 LLM 比普通开发者更差，缺乏理解能力，并且会以超人的速度制造细微而大规模的混乱。
  • 人们担心未来会充斥着不透明、变动频繁的“slopcode”，从而降低可理解性和可靠性。

安全、伦理，以及公司与 OSS 的态度差异

  • 有人主张将 LLM 视为未来规模安全审计的必需品；另一些人则回应说，分析和代码生成是两个不同的问题。
  • “被迫”在就业市场中使用 LLM 的压力，与这种情况依然很糟的看法之间存在张力。
  • 几条评论强调了训练数据和代码复用周围未解决的版权/许可问题。
  • 文章对比了理想主义、受到公众审视的开源项目，与在内部低调使用 LLM、较少关心来源的公司。