慢速軟體的終結：AI 驅動的效能優化

效能優化成本的崩解

高階軟體效能優化曾需要稀有的專業知識與大量的工時，現在任何使用 AI agent 的開發者都能輕鬆實現。實施複雜優化（例如 JIT compilers、多執行緒演算法與 native code generation）的成本已下降了數個數量級，瓶頸已從技術難度轉向了投入 token 的意願以及定義清晰目標的能力。

這種轉變意味著，以往僅限於大規模或利潤豐厚的專案所進行的優化，現在對於小型專案也變得可行。當驗證棘手優化的成本從數天的開發工作降至數分鐘的 agentic loops 時，進行優化的合理性與數量將大幅增加。

特定工作負載的客製化軟體

由於 AI agent 可以針對特定基準測試進行迭代優化，軟體正朝向「動態客製化軟體」模式發展，即針對特定工作負載進行調整，而非僅提供通用類型的軟體。

個案研究：FRE Regex Engine

在針對 FRE regex engine 的實驗中，使用 agent 來針對特定的 ripgrep 查詢進行優化，在僅經過一次優化後，於 holdout set 上便比標準 ripgrep 快了 2%。雖然 2% 的增益看似微不足道，但所需的開發成本極低（僅需幾分鐘的人力時間），這證明了軟體現在可以針對單一使用者或組織的特定數據模式進行量身打造。

向客製化效能轉型

這種能力讓開發者得以超越生產通用工具的「軟體工廠」。相反地，他們可以創建針對客戶特定工作負載高度優化的軟體版本。正如業界專家所言，對於管理海量數據負載的大型企業而言，這種方法很可能成為一種標準做法。

打破「程式碼寫作從來不是難點」的迷思

雖然有人認為與系統設計相比，編寫程式碼是微不足道的，但對於某些高效能組件而言，實施過程確實是難點所在。JIT compilers 與複雜的資料庫引擎就是典型的例子，其程式碼編寫的極高難度在歷史上限制了它們的普及程度。

AI agent 已降低了這一進入門檻。例如，在一個遊戲 AI 專案中，透過 LLMs 快速實現了多執行緒與多種搜尋架構——這些任務若由人工完成將是一項巨大的工程。最終的 AI 表現優於其他對手，主要歸功於這些因時間成本效益比而常被開發者略過的「煩人」優化。

人類在 AI 優化循環中的角色

儘管 agent 有強大的能力，但它們並非實驗設計的替代品。目前 SOTA models 的現狀顯示，對人類定義的框架有著關鍵的依賴性：

• 實驗設計： Agent 通常不擅長開放式的實驗設計。人類仍必須建立基準測試環境、定義 holdout sets 並確立成功指標。
• 驗證： Agent 在處理繁瑣的驗證工作方面表現出色——例如實施 replay logs 來除錯非決定性的多執行緒 bug，但它們需要正確的規格說明（specification）以避免對基準測試過度擬合（overfitting）。
• 判斷： 高層次的架構決策與避免「臃腫」的增量式變更，仍需要人類的監督，以確保效能增益不會因穩定性或安全性方面的退化（regressions）而抵消。

社群觀點與反論點

雖然快速軟體的技術可能性已提升，但社群討論指出，實務中軟體仍然緩慢的幾個原因：

結構性與經濟障礙

"The reason why software may continue to be slower or less secure than it could be is simply that no one cares enough to invest the time and money in improving it."

許多開發者與使用者認為，商業激勵機制優先考慮新功能而非效能，商業模式（如 Electron）與網路延遲（等待美國主機的伺服器）造成了一種本地端程式碼優化的無法解決的緩慢基準線。

客製化軟體的風險

一些批評者警告，稱向工作負載特定的軟體轉型，可能會使支援與知識共享變得不可能。如果每個程式實例都是客製化且優化方式各異，那麼分享除錯步驟或對軟體行為的常見理解將會消失。

硬體導向設計

經驗豐富的工程師指出，真正的效能來自於記憶體與快取優化（Hardware-Oriented Design），這是一個 LLMs 仍面臨挑戰的領域，因為訓練數據中充斥著大量高階且低效能的程式碼。為了達到頂尖效能，人類仍必須知道如何將必要的硬體資訊傳遞給 agent。