程式碼代理的現況可以透過這個事實來總結。
Claude 花費了 2 萬美元開發一個代理群組，實作（差不多是）一個用 Rust 編寫的 C 編譯器，但桌上型 Claude 卻是個 Electron 應用程式。
如果你不熟悉，Electron 是一個用於建構桌面應用程式的編碼框架，使用網頁技術，特別是 HTML、CSS 和 JS。Electron 的優點在於它能讓你建構一個支援 Windows、Mac 和 Linux 的桌面應用程式。此外，它還讓開發者能利用現有的網頁應用程式程式碼來開始。這對大小團隊來說都非常棒。你可能每天都在使用的許多應用程式都是用 Electron 建構的：Slack、Discord、VS Code、Teams、Notion 等等。
不過，也有缺點。Electron 應用程式很臃腫；每個應用程式都運行自己的 Chromium 引擎。最小的應用程式大小通常是幾百 MB。它們經常反應遲鈍或無回應。它們與作業系統功能的整合性不佳。
（最後兩個問題可以透過聰明的開發和特定作業系統的程式碼來解決，但很少這樣做。Electron 的優勢（單一程式碼庫、多平台、就是網頁！）並未激勵 HTML/JS/CSS 以外的優化。）
但這些缺點遠遠不及能夠建構和維護單一應用程式，並將其發佈到所有平台的優勢。
但現在我們有了程式碼代理！而程式碼代理被證明在跨平台、跨語言實作方面表現相當不錯，只要有定義明確的規格和測試套件。
表面上看，這個能力應該讓 Electron 的優勢變得過時！與其編寫一個網頁應用程式並將其發佈到每個平台，我們應該編寫一個規格和測試套件，並使用程式碼代理將原生程式碼發佈到每個平台。如果這個能力是真實且被採用的，使用者將能從為廣泛市場服務的小型、專注的團隊那裡獲得反應靈敏、效能優異的原生應用程式。
但我們仍然依賴 Electron。即使是 AI 編碼工具的領導者之一 Anthropic，儘管不斷發佈華麗的代理編碼成就，其 Claude 桌面應用程式仍在使用 Electron。而且它是一個緩慢、有錯誤且臃腫的應用程式。
那麼，為什麼我們還在使用 Electron，而不是擁抱由代理驅動、規格導向的開發未來呢？
首先，程式碼代理在處理開發的前 90% 方面非常出色。但最後的 10%——處理所有邊緣案例並在滿足真實世界後持續支援——仍然很困難、乏味，並且需要大量的代理輔助。
Anthropic 的基於 Rust 的 C 編譯器遇到了這個瓶頸，在通過大部分測試後：
結果的編譯器幾乎達到了 Opus 能力的極限。我（努力地！）試圖修復上述幾個限制，但沒有完全成功。新功能和錯誤修復經常破壞現有的功能。
結果的編譯器令人印象深刻，考慮到交付時間和參與人數，但它在很大程度上是無法使用的。最後一哩路很難。
一旦程式遇到真實世界，情況會變得更糟。混亂、意想不到的場景堆疊起來，開發永無止境。代理確實讓事情變得更容易，但艱難的產品決策會受到挑戰，需要人類的決策。
此外，由於產生了 3 個不同的應用程式（Mac、Windows 和 Linux），錯誤和支援的表面積增加了 3 倍。當然，Electron 應用程式有本地的怪癖，但大部分都被通用包裝器緩解了。原生應用程式則不然！
一個好的測試套件和規格可以讓 Claude 團隊為每個平台發佈原生的 Claude 桌面應用程式。但最後 10% 開發的相關開銷以及增加的支援和維護負擔仍然存在。
目前，Electron 仍然有意義。程式碼代理很棒。但開發的最後一哩路和支援的表面積仍然是一個真正的擔憂。
在 Hacker News 上，Claude Code 的 Boris Cherney 評論道：
我是 Claude Code 團隊的 Boris。
一些開發該應用程式的工程師過去曾從事 Electron 開發，所以偏好建構非原生應用程式。這也是一種分享程式碼的好方法，我們可以確保網頁和桌面版的 features 具有相同的外觀和感覺。最後，Claude 在這方面做得很好。
話雖如此，工程就是關於取捨，這未來可能會改變！
這就是答案：開發者的熟悉度以及跨多個平台的簡單可維護性，值得付出「取捨」。我們擁有令人難以置信的程式碼代理，擅長轉譯，但仍然存在一些成本，這些成本超過了發佈非原生應用程式的成本。