システム研究は効率と性能を重視する。過去10年間、私は超低遅延システムに取り組んできました。Demikernelとそれに関連するナノ秒規模のシステム（例：Cornflakes、Capybara）の目標は、より少ないサイクルでより多くのことを実現することです。AIコーディングは、システム構築にも同じレベルの効率をもたらし、少人数のプログラマーがより多くのコードを書けるようにしました。しかし、開発速度とソフトウェアの重要性が切り離され、「広範な影響範囲」を持つ障害がより頻発するようになりました。これらの問題は、重要なシステムに対して、遅いソフトウェアが思慮深い設計と開発を強制する方法を見出さない限り、ますます悪化するでしょう。

背景：本来遅いシステム

これまで、システム構築は常に時間を要するものでした。まず、低レベルのシステム開発は一般的にハードウェアと結びついており、ハードウェアは物理的に構築・展開する必要があります。次に、システムソフトウェアの展開は遅くなることがあり、ソフトウェアを物理的に配送・インストールしたり、システム全体を再起動・交換したりする必要がありました。最後に、アセンブリやC言語といった基本的なツールを使って大規模システムを構築する場合、実装の複雑さによって開発速度が制限されていました。

これらの障壁により、システムの開発ペースと重要性の間に大まかな相関が生じていました。ソフトウェアがより多くシステムに依存するほど、実装と更新に多くの労力が必要でした。同様に、システム障害の影響範囲が大きいほど、システムの構築と障害の防止に自然に多くの時間が費やされました。

過去20年間で、これらの障壁は体系的に取り除かれてきました。ハイパースケーラーはこれまで以上に速いペースでデータセンターを構築し、新たなハードウェアを継続的に展開しています。ほとんどのソフトウェアは中央集権的なクラウド上で動作し、週単位またはそれ以上の頻度で更新が可能になりました。AIは完璧ではありませんが、基本的なツールを使わずにシステムコードを書く速度を大幅に向上させました。時間の経過とともに、ソフトウェアの重要性は開発時間から完全に切り離されるようになりました。

この切り離しにより、人々はシステムソフトウェアを他のソフトウェアと同様に扱うようになりました。AIを活用する動きは、テストインフラ、ネットワークルーティング、データセンター管理、オペレーティングシステムに至るまで、あらゆる分野に等しく適用されています。最近の研究では、システム全体を理解したり最適化を実装したりすることなく、AIを使ってシステム性能を向上させる方法が示されています。プログラマーは、システムや基盤となるインフラを推論するための保証を理解せずに、急速に変更を加えています。

このアプローチは多くのソフトウェアではうまく機能しますが、システム構築には影響があります。具体例として、分散システムは基盤となるストレージレイヤーが提供する整合性保証に依存しています。しかし、今日のストレージシステムは複雑な弱整合性モデルを採用しており、文書化が不十分で、ストレージシステムのコードベース全体を学習コンテキストに追加しなければ（利用できない場合や、コード自体が絶えず変化している場合）、AIモデルが正しく理解できない可能性があります。その結果、AIモデルが整合性の前提に違反するコードを変更する可能性があり、プログラマーが見落としやすい問題が発生します。

この姿勢は予測可能な副作用をもたらしました。いずれ、何かが壊れます（人間もAIも完璧ではないため）。そのときになって初めて違いが明らかになり、広範な影響範囲によって、壊れた単一のシステムに依存する多くの他のサービスが停止します。例えるなら、私たちは日常的に迅速かつ安価に作られた実世界の製品（加工食品やIKEAの製品など）を使っていますが、そうでないもの（果物や野菜、道路や橋など）も必要としています。問題が発生するまで（健康被害が発生したり、橋が崩落したり）、これら2つを区別する良い方法は必ずしも存在しないため、重要なインフラサービスと重要度の低いソフトウェアを区別する方法を学ぶことが重要です。

遅いソフトウェア運動

このことから、ソフトウェアシステムの重要性と開発時間の間の結びつきを再確立する必要があります。人々は設計上の決定を検討する時間が必要であり、開発をより遅くさせることでこの時間を強制できます。そこで私は、遅いソフトウェア運動を提唱します。これは、私たちが食べ物についてより思慮深く配慮するよう促したスローフード運動に似ています。同様に、目標はすべてのソフトウェア開発を遅らせることではなく、開発速度の遅さが機能ではなくバグである重要なインフラソフトウェアを特定することです。

より具体的に言えば、ソフトウェアへの依存関係が多いほど、開発により多くの労力を費やすべきです。また、障害の影響が大きいほど、障害を避けるために多くの労力を費やすべきです。経験豊富なプログラマーはこの区別を理解できます。Mark Russは最近、自分が読むべきコードと読む必要のないコードをどのように判断しているかについて語り、同じ経験を他の人に伝えるためのメンターシッププログラムを提唱しました。しかし、私はこの直感は経験から学ぶ必要は必ずしもなく、開発環境に組み込むことで支援できると考えています。

新しいプログラマーがこれらのことを考え、学ぶために時間を費やす必要があるだけでなく、経験豊富なプログラマーも同様に時間を費やすべきです。どのソフトウェアがより多くの思考を必要とし、どのソフトウェアがそうでないかを、すべての人が明確に理解できるようにする必要があります。自然な抵抗がない代わりに、プログラマーが重要なものを決定する際に、より責任を持つよう促す人工的な障壁を導入できるかもしれません。彼らは最終的にソフトウェアの保守に時間を投資する必要があり、最初に速く書くことは、特に若いプログラマーにとって、後で壊れたときに大きな痛みを意味します。

私はAIを使ってコードを書くべきではないと言っているわけではありません。AIはアイデアの迅速なプロトタイピングや、退屈で反復的なコードを書くのに明らかに役立ちます。新しいシステムを構築する場合、コンパイルスクリプト、テストインフラ、評価フレームワークを構築するためにエンジニアのチーム全体を必要とすべきではありません。異なるキャッシュアルゴリズムを試したい場合、それらすべてを手動で実装する必要はありません。しかし、これらのコードが失敗した場合の影響範囲は非常に小さく、開発を速めるべきです。一方で、システム構築の高速化にはコストがあり、そのコストはコードを書く時点で明らかになるべきであり、後で修正する時点でのみ明らかになるべきではありません。

システム研究の機会

これはシステム研究にとって何を意味するのでしょうか。構築するシステムの背後にある動機について考えることは、常に重要でした。過去にはアイデアをプロトタイプ化することが高価だったため、構築する価値のあるアイデアはほぼすべて論文として発表する価値がありました（例：最初のSOSPプログラムを参照）。今ではその障壁は取り除かれ、プロトタイプの実装が極めて安価になったため、カンファレンスは十分に検討されていない投稿で溢れています。学生や研究者は実装する前にアイデアが良いかどうかをじっくり考えるのではなく、単に実装して投稿し、アイデアが有用な貢献になるかどうかを考える困難な作業を査読者に委ねています。

残念ながら、これは建物の建築模型が、理想的でない気象条件下で何十年も耐えられるかどうかを推測しようとするようなものです。数十年にわたりシステムを構築・保守してきた経験豊富な査読者は判断を下せることが多いですが、研究の最も困難な部分が学生から査読者に移り、経験豊富な査読者を急速に消耗させることになります。プロトタイプ化の難しさによって以前課せられていたような、ある種のスロットリング機能を必要とし、システム研究をより遅く、より思慮深いペースで行う必要性を強化する必要があります。

過去10年間にシステム研究のペースを加速させた要因を非難したり無視したりすべきではありませんが、それに乗るべきでもありません。代わりに、システム開発のベストプラクティスを再確立するための研究に焦点を当てる必要があります。性能や汎用性とともに、システムの実用性と保守性を判断する方法を積極的に見つけ出し、論文執筆者がこれらの軸で決定を正当化するよう促すべきです。すべての答えを持っているわけではありませんが、システムコミュニティは過去に適応してきたので、再び適応すると信じています。