Scarf 從 Haskell 遷移至 Python 以優化 AI 驅動開發

AI Agent 已改變軟體開發的經濟效益

Scarf 已將其新的 API 開發從 Haskell 轉向 Python，因為大型語言模型 (LLMs) 和 AI 編碼代理 (AI coding agents) 的興起，使得緩慢的編譯時間成為開發週期中的主要成本。雖然 Haskell 在生產環境中提供了七年的可靠性與強大的型別安全性，但現在 AI 生成程式碼的速度已超過了 Haskell 編譯器的速度，造成了阻礙平行、代理主導實驗的瓶頸。

瓶頸：冷啟動與平行工作流

在傳統的人力主導工作流中，漫長的編譯週期雖然令人困擾，但通常是可以忍受的，因為人類在撰寫程式碼上花費了大量時間。然而，AI agent 可以幾分鐘內擬定出合理的變更。當開發迴圈包含 15 分鐘的冷啟動構建 (cold build) 時，編譯器就成了生產力的主要限制因素。

這種問題在平行工作流中會被放大。Scarf 理想的工作流包括：

• 同時啟動多個 worktrees。
• 分叉 (forking) 不同的工作線以供各種 agent 進行探索。
• 快速審查並捨棄結果。

由於 Haskell 環境通常需要複雜的快取設定（透過 Nix 或遠端構建器），且記憶體使用量高，啟動新工作線的「稅收」會成倍增加。雖然增量構建 (incremental builds) 可以很快，但冷啟動和深度變更的情況——這在以 agent 為主的開發工作流中很常見——仍然慢得令人望而卻步。

遷移策略：增量遷移

Scarf 避免了冒險的「大爆炸式」切換，而是透過部署一個與現有 Haskell API 同時運行的 Python API 伺服器來進行。遷移遵循以下規則：

• 新功能： 所有新的 API 路由都使用 Python 編寫。
• 現有功能： Haskell 程式碼會繼續運行，直到特定的功能被觸及並進行移植。
• 移植過程： 使用 LLMs 將現有的 Haskell 邏輯移植到 Python，這個過程比以往手動移植要快得多且更直接。

該公司報告稱，先前花費在與工具鏈搏鬥的時間已被重新分配到交付功能和增加測試覆蓋率上。其結果是實現了更快的「從客戶來電到部署」流程，有時在支援電話結束前，錯誤修復就能上線。

Haskell 生態系統在「AI 時代」的挑戰

Scarf 主張，如果 Haskell 不針對 AI 作為一等公民進行優化，它將面臨危險。作者建議，社群應將對型別系統研究（例如：相依型別）的關注點，從優先順序降低，轉而支持工業需求：

• 減少冷啟動構建時間 以及專案啟動的摩擦力。
• 改進文件，提供可直接複製貼上的真實範例，而非僅僅是抽象型別。
• 增強錯誤訊息，使其對 agent 更友善，讓 LLMs 能更快修復程式碼。
• 增加高品質的訓練數據，讓模型能更好地理解 Haskell 模式。

社群觀點與反論點

轉向 Python 的決定引發了開發者之間的激烈辯論，凸顯了 AI 如何影響語言選擇的差異：

為 AI 時代的強型別提供辯護

某些開發者認為，在使用 LLMs 時，強型別系統更顯得重要，因為它們可以作為 AI 常產生的「垃圾」的護欄。

"I cant imagine using a language without a good type system to catch all the junk the LLM produces." — @noelwelsh

其他人建議 Scarf 可以遷移到同時提供型別安全性與快速編譯的語言，例如 OCaml 或 Go，而不是遷移到像 Python 這種動態型別語言。

為生產力與迭代的辯護

相反地，一些工程師發現，當迭代迴圈足夠快時，靜態型別是沒那麼關鍵的。一位開發者指出，隨著轉向 Elixir，其生產力有所提升，因為與營運維護類型的錯誤（如佇列長度或 API 錯誤）相比，較少發生與型別不相容的錯誤。

營運維護上的疑慮

對轉向 Python 的批評者指出，雖然編譯速度更快，但 Python 引入了自己的一套摩擦力，特別是在不同作業系統間的依賴管理與版本控制方面。

「Vibe Coding」的批評

一些觀察者將此舉描述為一種向「vibe coding」的轉趨向，即編譯器的嚴謹性被代理式迭代 (agentic iteration) 的速度所取代，並依賴廣泛的測試套件來捕捉原本由型別系統防止的錯誤。