系统研究强调效率和性能。过去十年，我一直致力于超低延迟系统：Demikernel 及其相关纳秒级系统（如 Cornflakes、Capybara）的目标是用更少的周期完成更多工作。AI 编程将同样的效率带入了系统构建，让更少的程序员编写更多代码。然而，这也使开发速度与软件的重要性脱钩，导致故障更频繁且具有 「广泛影响范围」。除非我们找到一种方法，让 慢速软件 为我们最重要的系统强制执行深思熟虑的设计和开发，否则这些问题只会变得更糟。

背景：自然慢速的系统

直到现在，系统构建一直耗时。首先，低级系统开发通常与硬件绑定，而硬件必须物理构建和部署。其次，系统软件的部署可能很慢；它通常需要将软件物理交付并安装，或者对整个系统进行重启或更换。最后，使用基本工具（通常是汇编或 C）构建大型系统意味着实现复杂度限制了开发速度。

这些障碍在系统开发速度与重要性之间施加了粗略的相关性。软件依赖的系统越多，实现和更新所需的努力就越大。同样，系统故障的影响范围越大，自然花费在构建系统并确保其不会失败的时间就越多。

在过去 20 年中，这些障碍已被系统性地移除。超大规模提供商正在以前所未有的速度构建数据中心，并持续部署新硬件。大多数软件运行在集中式云上，支持每周甚至更频繁的更新。AI 虽然并不完美，但已大大加快了在不使用基本工具的情况下编写系统代码的速度。随着时间的推移，软件的重要性已与开发时间完全脱钩。

这种脱钩让人们像对待其他软件一样对待系统软件。使用 AI 的同样推动力被平等地应用于测试基础设施、网络路由、数据中心管理和操作系统。近期工作 已强调如何使用 AI 在不理解整个系统甚至不实现优化的情况下提高系统性能。程序员在不理解系统或我们用于推理底层基础设施的保证的情况下快速进行更改。

虽然这种方法对很多软件有效，但它对系统构建有影响。作为具体例子，分布式系统依赖于底层存储层提供的一致性保证。然而，当今的存储系统通常具有复杂的弱一致性模型，这些模型文档不完善，且 AI 模型可能无法正确理解，除非将存储系统的整个代码库添加到训练上下文中（这可能不可用或本身在不断变化）。因此，AI 模型可能会更改某些违反一致性假设的代码，而程序员很容易忽视这些假设。

这种态度导致了可预见的副作用。不可避免地会出现问题（因为人类和 AI 都不完美）。只有到那时，差异才会显现，因为广泛的影响范围会使依赖于单个故障系统的许多其他服务瘫痪。作为类比，我们都使用快速且廉价制造的现实世界产品（如加工食品、宜家），但也想要一些不是这样制造的东西（如水果和蔬菜、道路和桥梁）。我们不一定有很好的方法来区分两者，直到出现问题（如健康问题出现、桥梁倒塌），因此重要的是我们要学会将重要的基础设施服务与其他不太关键的软件区分开来。

慢速软件运动

这促使我们重新建立软件系统重要性与开发时间之间的耦合。人们需要时间来考虑他们的设计决策，迫使他们更慢地行动可以施加这种时间。因此，我提出 慢速软件运动，类似于慢食运动，该运动敦促我们对所吃的东西更加深思熟虑和体贴。同样，目标不是减缓所有软件开发，而是识别重要的基础设施软件，在那里，较慢的开发速度是一种特性，而不是缺陷。

更具体地说，软件的依赖越多，在开发中投入的努力就越多。故障的影响越大，在避免故障中投入的努力就越多。经验丰富的程序员可以做出这种区分：Mark Russ 最近谈到 他如何知道需要阅读哪些代码和不需要阅读哪些代码，并主张建立导师制计划将同样的经验传授给他人。然而，我认为这种直觉不需要完全从经验中学习，我们可以在开发环境中构建一些东西来帮助。

不仅新程序员需要花时间思考这些事情并学习，经验丰富的程序员也应该如此。所有人都应该清楚哪些软件需要更多思考，哪些不需要。在自然阻抗缺失的情况下，我们或许可以引入人工障碍，促使程序员在决定实现重要功能时有更多「皮肤在游戏中」，这样说吧。他们最终需要投入时间维护软件，提前快速编写只意味着以后出现问题时会带来更多痛苦，尤其是对年轻程序员而言。

请注意，我并不是说我们不应该使用 AI 编写代码。它显然对快速原型设计或编写繁琐或重复的代码很有用。如果我正在构建一个新系统，我不应该需要整个工程师团队来构建编译脚本、测试基础设施或评估框架。如果我想尝试不同的缓存算法，我不应该必须手动实现所有算法。然而，这些代码在失败时的影响范围很小，因此应该更快地开发。另一方面，更快的系统构建有成本，这些成本在编写代码时就应该显现出来，而不仅仅是在以后修复时。

系统研究机会

这对系统研究意味着什么？思考我们构建的任何系统的动机一直很重要。在过去，原型设计一个想法很昂贵，所以几乎任何值得构建的想法都值得发表（例如，参见第一个 SOSP 程序）。现在这个障碍已被移除，因为实现原型变得极其廉价，因此，我们的会议正被考虑不周的投稿淹没。学生和研究人员不是在实现之前认真思考想法是否好，而是简单地实现并提交，把思考想法是否会有用贡献的艰巨工作留给审稿人。

不幸的是，这就像试图猜测建筑模型是否能在不太理想的天气条件下站立或持续数十年。已经构建和维护系统数十年的经验丰富的审稿人通常可以做出判断，但这将研究中最困难的部分从学生转移到审稿人身上，并将迅速耗尽经验丰富的审稿人。我们需要某种节流功能——以前由原型设计的难度施加——来强化系统研究需要以更慢、更深思熟虑的速度进行的必要性。

我们不应该指责或忽视过去十年加速系统研究步伐的因素，但我们也不应该过度依赖它。相反，我们需要专注于研究以重新建立系统开发的最佳实践。我们应该积极尝试找出如何判断系统的实用性和可维护性，以及性能和通用性，并迫使论文作者在这些轴线上证明他们的决策。虽然我没有所有答案，但系统社区过去已经适应，我相信他们会再次做到。