系統研究重視效率與效能。在過去十年中，我一直致力於超低延遲系統：Demikernel 及其相關的奈秒級系統（如 Cornflakes、Capybara）的目標，是用更少的運算週期完成更多工作。AI 輔助程式設計已將同樣的效率帶入系統建置，讓更少的程式設計師撰寫更多程式碼。然而，這也讓開發速度與軟體的重要性脫鉤，導致故障更頻繁且「波及範圍廣泛」。除非我們找到方法，讓慢速軟體能對我們最關鍵的系統強制執行深思熟慮的設計與開發，否則這些問題只會惡化。

背景：天生緩慢的系統

直到現在，系統建置一向耗時。首先，低階系統開發通常與硬體緊密結合，而硬體必須實際製造與部署。其次，系統軟體的部署可能很慢；它經常需要將軟體實體交付與安裝，或是對整個系統進行重新開機或替換。最後，使用基本工具（通常是組合語言或 C）建置大型系統，意味著實作複雜度會限制開發速度。

這些障礙讓系統的開發速度與重要性之間產生粗略的相關性。軟體越依賴某個系統，實作與更新該系統所需的努力就越多。同樣地，系統故障的波及範圍越大，自然會花費更多時間來建置該系統，並確保它不會發生故障。

在過去 20 年中，這些障礙已被系統性地移除。超大型資料中心業者正以前所未有的速度興建資料中心，並持續部署新硬體。大多數軟體運行在集中式雲端上，這使得每週甚至更頻繁的更新成為可能。AI 雖然不完美，但已大幅加快系統程式碼的撰寫速度，而無需使用基本工具。久而久之，軟體的重要性已與開發時間完全脫鉤。

這種脫鉤讓人們得以將系統軟體視為一般軟體。同樣的 AI 應用推力被平等地施加在測試基礎設施、網路路由、資料中心管理與作業系統上。近期研究已強調如何在不理解整個系統、甚至不實作最佳化的情況下，使用 AI 提升系統效能。程式設計師正快速進行修改，卻不理解系統或我們用來推論基礎設施的保證。

雖然這種方法對許多軟體而言運作良好，但對系統建置卻有其影響。具體來說，分散式系統依賴底層儲存層提供的一致性保證。然而，現今的儲存系統通常採用複雜的弱一致性模型，這些模型文件記載不全，且 AI 模型若未將儲存系統的完整程式碼庫加入訓練脈絡（可能無法取得或本身持續變化），可能無法正確理解。因此，AI 模型可能修改某些程式碼而違反一致性假設，而程式設計師很容易忽略這些假設。

這種態度已導致可預期的副作用。不可避免地，某些東西會壞掉（因為人類與 AI 都不完美）。只有到了那個時候，差異才會顯現，因為廣泛的波及範圍會拖垮許多依賴單一故障系統的其他服務。作為比喻，我們都使用快速且廉價製造的真實世界產品（如加工食品、IKEA），但也想要某些非快速廉價的東西（如水果蔬菜、道路與橋樑）。我們不一定有好方法在出問題前區分兩者（如健康問題出現、橋樑倒塌），因此我們必須學會將重要的基礎設施服務與其他較不關鍵的軟體區分開來。

慢速軟體運動

這促使我們重新建立軟體系統重要性與開發時間之間的連結。人們需要時間來思考設計決策，而迫使他們放慢速度就能帶來這段時間。因此，我提出「慢速軟體運動」，類似於慢食運動（slow food movement），它呼籲我們對所吃的食物更加深思熟慮。同樣地，目標不是減緩所有軟體開發，而是辨識重要的基礎設施軟體，在這些地方，較慢的開發速度是一項特點，而不是缺點。

更具體地說，一段程式碼的依賴越多，開發它所應投入的努力就越多。而故障的影響越大，投入避免故障的努力就應越多。資深程式設計師能夠做出這種區分：Mark Russ 最近談到他如何知道哪些程式碼需要閱讀、哪些不需要，並主張建立導師制度，將同樣的經驗傳授給他人。然而，我認為這種直覺不需要完全從經驗中學習，我們可以在開發環境中內建某些機制來協助。

不僅新手程式設計師需要花時間思考這些事情並學習，資深程式設計師也應該如此。所有人都應該清楚知道哪些軟體需要更多思考，哪些不需要。在缺乏自然阻抗的情況下，我們或許可以引入人工障礙，促使程式設計師在決定實作重要功能時投入更多心力。他們最終仍需投入時間維護軟體，而前期快速撰寫只會在日後故障時帶來更多痛苦，尤其是對年輕程式設計師而言。

請注意，我並不是說我們不應該使用 AI 撰寫程式碼。它顯然對快速建立原型或撰寫繁瑣、重複的程式碼很有用。如果我正在建置一個新系統，我不應該需要一整個工程師團隊來建立編譯腳本、測試基礎設施或評估框架。如果我想嘗試不同的快取演算法，我不應該需要手動實作所有演算法。然而，這些程式碼在故障時的波及範圍很小，因此可以較快開發。另一方面，較快的系統建置有其代價，而這些代價應該在撰寫程式碼時就顯而易見，而非等到日後修復時才發現。

系統研究機會

這對系統研究意味著什麼？思考我們所建置的任何系統背後的動機一向很重要。在過去，原型設計代價高昂，因此幾乎任何值得建置的想法都值得發表（例如，參見第一屆 SOSP 的議程）。如今這個障礙已被移除，因為實作原型已變得極其廉價，因此我們的會議正充斥著考量不周的投稿。學生與研究人員不再在實作前認真思考想法是否良好，而是直接實作並投稿，將思考該想法是否為有用貢獻的艱難工作留給審稿人。

不幸的是，這就像試圖猜測建築模型在不理想的天候條件下是否能屹立不搖或持續數十年。擁有數十年建置與維護系統經驗的資深審稿人通常能做出判斷，但這將研究中最困難的部分從學生轉移到審稿人身上，並將迅速耗盡資深審稿人的精力。我們需要某種節流機制——先前由原型設計難度所施加——來強化系統研究必須以更慢、更深思熟慮的速度進行的需求。

我們不應指責或忽視過去十年加速系統研究進度的因素，但也不應過度依賴它們。相反地，我們需要專注於研究，以重新建立系統開發的最佳實務。我們應該積極嘗試找出如何在效能與通用性之外，判斷系統的實用性與可維護性，並要求論文作者在這些面向說明其決策理由。雖然我沒有所有答案，但系統研究社群過去曾適應變化，我相信他們能再次做到。