在一個令人侮辱又諷刺的時刻，那些追求簡潔（neats）的人們，卻被那些追求隨意（scruffies）的人們創造出一個更偏好撰寫任何非 Lisp 程式碼的 AI。

我工作上身為 DevOps 工程師，經常使用代理式 AI 來完成我的工作。我使用 OpenRouter 搭配 Goose CLI 工具，並已經建立了一個相當不錯的設定檔。

最近我開始撰寫一個工具，用於在不同的 RSS 閱讀器格式之間進行轉換。當然，我一開始是用 Lisp 開始寫的，這是我最愛的語言。

但我遇到了一個問題。我必須教 AI 如何使用 REPL。起初，我讓它透過 tmux 執行指令來與 REPL 互動，例如 tmux capture-pane -t 0.0 -p | tail -n 1。這效果還可以，但我注意到 AI 在 REPL 開發上非常困難。Claude 真的在這裡卡住了。較差的 AI 會更糟。我會在幾分鐘內花費 10 到 20 美元，卻只得到一些還算可以但最終需要我重寫的 Lisp 程式碼。我嘗試使用像 DeepSeek 和 Qwen 這樣較便宜的 AI，我發現它們在工作上對某些任務表現還可以，但這行不通。

我認為，也許如果我讓 REPL 開發更順暢，AI 會做得更好。我想給予 goose 對 REPL 的無限權限，同時也保留一般的指令權限。因此，我創建了一個名為 tmux-repl-mcp 的工具，讓與 REPL 的互動更直接。它不再需要消耗大量 token、執行一堆 sleep 指令並解析 tmux 輸出，而是可以直接在 REPL 中執行 execute_command 並取得其輸出。

我用 Python 寫了這個工具，因為我在 goose 設定檔中的許多 AI 工具都已經圍繞著 uvx 建立。我喜歡只需要安裝 uvx，goose 就能立即使用所有這些工具。我的設定檔中已經建置了所有這些東西，所以我認為如果以相同的方式分發，對大家來說會更容易使用。此外，官方的寫 MCP 伺服器指南本身就是用非 Lisp 語言寫的。

當然，用 Python 和 Lisp 寫程式碼的差異是戲劇性的，簡直是天壤之別。我讓它寫了所有的程式碼和所有的測試。我必須半手動除錯，但我仍然能夠在一兩天內完成這個比沒有更好的工具，而且還使用了便宜的模型。最糟糕的是，對我來說，這種體驗在很多方面都是一樣的：我透過成為 AI 的窮人版產品負責人來寫程式碼，只有 AI 在處理 Python 時表現良好。我感受不到我平常寫 Lisp 時的快樂。

回到我實際的專案很痛苦。我最終手動寫了一個檔案（src/newsboat.lisp）。我當時正在除錯，才意識到用 AI 寫 Lisp 有多麼困難。我不得不切換回 Claude，它至少相對於其他模型能取得一些進展。tmux-repl-mcp 工具很有幫助，但我仍然在 30 分鐘內花費了 10 美元。與 Python 相比，AI 互動中的訊號雜訊比，或者換句話說，原地打轉與進展的比例，簡直是天壤之別。而在 AI 中，你為雜訊和訊號一起付費。

現在我考慮用 Go 重寫它。有了 AI，程式碼變得便宜，但前提是你使用的語言有大量的訓練資料。

另一個令人沮喪的地方是工具。Lisp 有很多工具可供選擇。例如，我喜歡使用 OCICL 而不是 QuickLisp，但我必須告訴 AI 每個會話都不要使用 quicklisp。它似乎內建就是為了使用它。這也讓我意識到，AI 產生程式碼 sort of 是沿著阻力最小的路徑進行的。

除了缺乏訓練資料之外，還有其他原因讓 Lisp 特別難以被 AI 取代。我們與 AI API 互動的高延遲請求-回應方式，與 REPL 不太相容。REPL 開發透過減少人類的延遲來讓程式設計更容易、更好，但這些 API 本身已經有很高的延遲了。不使用 REPL 的缺點是，你必須在編寫程式碼時有更高的準確性，而且只能一次測試大批程式碼，但 AI 可以一次寫出數百行程式碼，所以它使用不使用 REPL 的語言是很有道理的。

用 Go 和 Python 這類高網路流量的語言來寫程式，比用 Lisp 來寫要容易且便宜幾個數量級。AI 的出現將語言的流行度轉化為實際的每百萬個 token 的成本節省。更重要的是，用一種語言或另一種語言來建構，對我體驗語言的方式沒有任何區別；無論如何，在理想情況下，我是一個相當有主見、喜歡微觀管理的產品負責人。這真的很令人難過。

這讓我想起我故鄉關於 Naperville, IL 的 Plank Road 的一個故事。十九世紀的道路總是泥濘不堪，所以一群投資者建造了一條鋪設木板的路。這條路的建造者會對使用這條路收取費用。後來，鐵路公司提出要在 Naperville 修建鐵路，但他們拒絕了，說他們在木板路上賺了很多錢，所以鐵路建在了另一個城市。每個人都停止使用木板路而改用鐵路，它最終只剩下名字，沒有人以其原始形式使用它。

我知道金錢在這裡不是問題，至少對我來說不是。然而，我忍不住在腦海中進行比較。Plank Road 走起來一定比泥濘的道路好得多，讓旅行者在與泥濘的比較中感到愉悅，就像 Lisp 讓我在寫其他東西時的感受一樣。然而，當鐵路出現時，所有農民所要做的就是將貨物裝上車。如此輕鬆，為什麼還要使用那條愚蠢的道路呢？

這只是「更糟就是更好」（Worse is Better）的另一個例子。然而，Lisp 在這個網路時代已經存活了幾十年。我想知道當它在 AI 時代倖存下來時，我們將學到什麼。我喜歡 neats 陣營。它更有趣。我想知道需要做出哪些適應才能讓 AI 在 Lisp 上更好地工作。