在AI时代保持对编程的热爱

# 在AI时代保持对编程的热爱 来源：https://blog.nlnetlabs.nl/maintaining-the-love-for-coding-in-the-time-of-ai/ *作者：Alex Band* 过去一年，我们目睹了大语言模型（LLMs）对我们NLnet Labs开源软件工作的深远影响。这些影响主要集中在两个方面：社区贡献和安全报告。在深入探讨这个话题之前，请允许我先介绍一些背景和历史——关于我们过去25年来是如何开发软件的。 ## NLnet Labs的软件开发模式 我想退一步来解释，我们是如何维护那些旨在关键基础设施中运行的开源项目的。因为当人们想到开源时，几乎都会默认这是一个由个体开发者组成的社区协作项目。 然而，我们开发的是DNS、BGP和RPKI等互联网标准相关的软件，这些都属于相对小众的领域。再加上我们使用C和Rust语言构建软件，可以说我们是在小众领域中的小众领域工作。因此，我们以小规模、专注的团队形式运作，几乎像商业公司一样，有路线图、项目规划和定期发布。所以，尽管我们做的一切都是开源且采用宽松许可证，但在过去25年里，除了小型的bug修复和拼写修正外，我们在Unbound、NSD和Routinator等项目上并没有收到很多外部贡献。 我们七年前为20周年纪念制作的贴纸。曾有几次，例如我们的DNS解析器Unbound收到了重要的拉取请求。这些贡献大多来自为特定用例定制了Unbound的组织，希望将他们的修改合并到上游。原因通常关乎可维护性：通过让他们的特殊修改成为由NLnet Labs维护的主分支的一部分，他们不再需要在Unbound新发布的版本中应用自定义补丁。 在理想情况下，这种动态对每个人都有益。我们的项目获得了惠及更广泛社区的额外功能，而贡献代码的组织现在拥有了所需的功能，并保证由核心开发团队进行长期维护。双赢！ 当然，现实情况要复杂一些。我们的团队精心维护着项目的架构、长期可维护性和代码风格。这就是为什么像Unbound这样的项目能够持续演进近20年，而无需完全重写就能满足当今互联网DNS解析器运营商的需求。 🤝 当我们收到一个重要的拉取请求时，我们的开发团队希望仔细审查设计选择，确保贡献符合项目的整体架构，没有错误，并且足够健壮以抵御攻击。我们喜欢与作者一起探讨这些选择，以便更好地理解他们的决定，有时在合并到主项目之前会要求进行修改。 事实上，我们团队内部也应用这种严格的审查流程。当一个开发者设计和构建新功能时，团队成员会逐行仔细审查他们的工作，以便理解并能够维护新功能。代码通常要经过几个审查周期才能最终合并和发布。 还需要考虑社交动态。即使功能设计出于最好的意图，开发者也可能对代码风格甚至行宽特别挑剔。你们知道自己是谁😉。但有时也需要勇气告诉作者，你真的认为他们那笨拙的XML schema不是正确的选择。 对于外部贡献，有些情况下我们的结论是最好让NLnet Labs的核心团队完全从头重写该功能。我们在过去曾多次同意这种做法，例如Unbound中的Serve Stale功能，我们是按约定费用实现的。其他情况下，双方可能都认为该贡献更适合放在`/contrib`文件夹中，那里存放的功能不是官方发行版的一部分，但可能对某些人有帮助。 ## 贡献：下一代 随着前沿AI模型的发布，这种贡献动态在过去的12个月里发生了根本性变化。结果，现在有一批开发者感觉自己获得了AI赋能的超能力。这对许多用例来说没问题，但我们觉得需要谨慎对待这种新现实。 不幸的是，没有人能告诉你DNS是什么。必须说：让你最喜欢的AI代理“在Cascade中实现RFC 9432中定义的Catalog Zones，由NLnet Labs开发。只有在所有测试通过并且RFC中所有规范都被覆盖后才停止。最终结果必须包括手册页、测试和完整的RFC覆盖。” 你可以去喝杯咖啡，等你回来时，就会得到4000行看起来合理、甚至可能在一定程度上工作的代码。为了论证起见，我们暂且忽略所有针对RFC未描述细节所做的设计选择。 你的下一步可能是创建一个拉取请求，感觉自己不仅为NLnet Labs，而且为整个DNS运营商社区做出了有价值贡献。这种对你喜爱的开源项目的贡献，对你来说可能感觉像“啤酒自由”和“言论自由”，但对我们来说，就像被塞了一只“免费小狗”：初衷是好的，但接受它会在未来多年带来重大后果。 🤖 最重要的是，我们仍然认为审查的核心原则仍然适用。我们需要能够与贡献者就其设计选择进行探讨。最终，他们是将代码的维护责任交给我们。我们需要在做出长期承诺之前知道自己要面对什么。可悲的是，几乎在所有情况下，对代码任何问题的回应都是“**我不知道，这就是Claude想出来的**🤷”。这对我们行不通。 但在我深入探讨AI生成和辅助代码贡献的持久影响之前，我想先谈谈最新LLMs带来的另一个结果：借助AI发现的安全报告激增。 ## 安全研究，但变成了雪崩 由于前文解释的原因，我们的工作开源并非为了让它成为联合社区项目，而是为了让我们能够公开透明地展示软件的工作方式。我们开发开源软件的一个重要原因是让每个人都能检查我们的代码，验证正确行为并发现潜在缺陷和漏洞。这使我们的所有项目都成为从博士生到经验丰富的安全专业人士的理想研究目标。结果是一套极其健壮的应用程序，每次发布都变得更安全。 不到一年前，我们社区的开发者还在抱怨AI生成的垃圾信息。我们看着那些完全不合逻辑的bug报告只是笑笑，每月被干扰几次也只是轻微烦恼。因为问题在于：你不能忽视它们，因为万一其中一个是可能带来灾难性后果的漏洞呢？我们*必须*查看报告并回应报告者，无论如何。 快进到今天，AI垃圾信息问题当然已经解决了。Bug报告现在极其准确，并且附带了重现步骤和可能的修复方案。更令人担忧的是，它们一次来了数百个。这真是雪崩。 分类处理这些报告需要大量时间。我们的团队可能一整天都在弄清楚报告的问题到底是什么。虽然确实通常有重现问题的步骤，但问题描述仍然相当模糊。最新一批Routinator LLM bug报告中包含诸如“往返不忠”、“K文件风暴固定验证”和“通过块排序位置的线性扫描燃烧”等术语。 如果你想知道为什么今年年初以来我们的软件没有出现任何重大新功能，那是因为到现在我们几乎所有团队都忙于发布bug修复，有时需要与其他软件供应商密切协调。有时问题流似乎干涸了，我们以为隧道已经到了尽头，然后新的AI模型发布，这个过程又重新开始。 过去几年Unbound的CVE数量。这对我们来说是个复杂的困境。作为经理，我体验到了NLnet Labs的软件开发者的动力源泉：用美丽、优雅的解决方案解决复杂问题。可以说是匠心独运。但几个月来，我们的大多数团队一直在分类处理bug和协调发布。这确实让工作失去了所有乐趣，而且很难预测这条路会通向何方。 ## 我们何去何从？ 就目前而言，我们别无选择，只能发布我们现在制定的LLM政策(https://nlnetlabs.nl/llm-policy/)，要求所有代码和文档贡献必须由人类创作。我们确实接受使用LLMs发现的漏洞报告。有些人可能认为我们不近人情，因为即使借助AI协助，一个人也有可能对其贡献的每一行代码负责。 虽然经验丰富的C或Rust开发者，如果精通DNS或BGP，确实可以在AI协助下进行贡献并完全负责其代码，但遗憾的是，这并不是我们的经验。此外，虽然我在本文中仅围绕实际论点阐述了我们的理由，但伦理和知识产权考虑也在我们的决策中扮演重要角色。 尽管如此，前方的道路充满不确定性。眼前的问题是规模问题。NLnet Labs有十五名员工，其中十二名是软件开发人员。我们的基金会没有财务能力增加额外人手。依靠LLMs来处理分类工作不仅会花费巨资，而且即使我们这样做了，那意味着什么——LLM生成的bug报告由LLM分类、修复、合并和发布？如果这是让我们保持领先的解决方案，我要说这违背了我们所信仰的一切。人类需要发挥作用。 我坚信我们有一个值得骄傲的产品组合，拥有漫长而光明的未来。互联网核心的极大一部分依赖于我们的工具，从DNS解析器到RPKI验证器。我们对新的DNSSEC签名器Cascade以及我们在研的其他项目前景感到兴奋。 我们正处于十字路口，团队的福祉和组织的长期可行性危在旦夕。我们预计，那些主张使用不保证内存安全的编程语言是不负责任的人，或许很快会声称发布未经LLM在开发过程中测试的软件是不负责任的。我们将密切关注为自由、开源软件促进LLM测试的CI/CD工具，同时确保我们忠于自己的价值观并维护基金会的可持续性。 **♥️ 来自NLnet Labs的全体成员。**