上週我在 Mechanical Orchard 舉辦的 The Orchard Retreat 待了一天，邀請了多位從事軟體開發工作的人，共同討論在代理式程式設計興起之際，這個專業的未來走向。活動依循 Chatham House Rule 進行，因此我無法歸屬所聽到的評論與故事。（若有人認出自己，並希望獲得歸屬，請告訴我。）以下是我筆記中記下的一些片段。

❄ ❄

有一個小組用 Rust 開發出 GNU Cobol 編譯器的行為複製。成果是 70K 行的 Rust 程式碼，且在 3 天內完成。這再次顯示 LLM 能有效將既有程式碼移植到新平台。良好的迴歸測試在此極具價值（我不知道 GNU Cobol 的測試品質如何）。若能存取既有實作，也有機會建置測試套件。

❄ ❄

大型規格文件對人類來說審查起來可能很複雜。一位與會者分享了一個想法：讓 LLM 對人類專家進行訪談，透過提問來驗證規格的正確性，這是一種 Interrogatory LLM 的形式。

❄ ❄

這並非專門關於 AI 的討論——但我很喜歡一位與會者的評論：他與組織合作時，第一件事就是閱讀其變更控制委員會的準則。這是過去出錯所留下的疤痕組織。我常說，要理解一件事為何如此，就必須了解它是如何形成的。這似乎是探討歷史中重要面向的極佳方式。

❄ ❄

我那些從事遺留系統現代化的同事，長期以來對「Lift and Shift」——將遺留系統移植到新平台並保留 Feature Parity ——持保留態度。

我們認為這個模式錯失了巨大的機會。舊系統往往隨時間膨脹，許多功能未被使用者使用（根據 2014 年 Standish Group 的報告為 50%），且業務流程也隨時間演進。替換這些功能是一種浪費。相反，應該嘗試退一步，了解使用者目前的需求，並根據業務成果與指標來優先排序這些需求。

但這種觀點是在 LLM 具備移植程式碼能力之前形成的。一位在這個領域投入大量心力的與會者表示，他認為將系統 Lift and Shift 到新平台，現在應該永遠是遺留系統遷移的第一步。成本已不再像過去那麼高，而更好的環境也讓後續的演進變得更便宜。只是不要停在這一步。

❄ ❄

有幾位與會者來自金融業，因此深陷於複雜遺留環境、監管控制，以及軟體操作金錢時可能帶來的重大風險等問題。他們的其中一個挑戰是，當金融產品在多個司法管轄區提供時，需滿足各管轄區的法規所帶來的複雜性。在決定適用哪個管轄區，以及在工作流程的正確時點套用正確的規則集時，會產生大量的軟體複雜度。

這裡的問題是，代理式程式設計的快速發展，是否意味著我們可以為每個管轄區建置獨立、較簡單的系統。然後再利用 LLM 確保這些系統之間的一致性，以便在產品規則變更時，每個系統都能反映到各自的環境中。

軟體設計的很大一部分，在於辨識不同業務情境中哪些是相同、哪些是相異的部分。當事情是相同的且需要保持一致時，我們理所當然會避免複製程式碼，因為這會增加更新的成本與不一致的風險。有趣的問題是，LLM 能扮演什麼角色，為我們提供新的工具來應對這個挑戰。

❄ ❄

如同這類聚會常見的情況，與會者都很關心初階開發人員。當我們與 Genie 合作時，我們的價值來自良好的判斷力——我們要如何傳授這種能力？這個團體有一個共同的工具：Pair Programming。配對的一大好處一直是技能移轉，在這裡，有經驗的代理式程式設計師可以傳授他們對軟體設計的判斷力，以及如何使用 Genie 來達成目標。而初階開發人員也常能分享一些技巧——在邁向代理式未來的轉型中，這雙新鮮的眼睛特別有價值。

❄ ❄

在歷史上，我們使用電腦系統為混亂的人類流程帶來秩序。AI 是否正在逆轉這件事？

❄ ❄

有大量的軟體涉及資料轉換。那邊的記錄需要被這邊的 API 所使用，但資料結構上存在差異，通常是因為處於不同的 Bounded Contexts，因此我們必須進行某種轉換。代理特別擅長撰寫這類轉換程式碼，而這類程式碼往往比我們希望的更繁瑣。

❄ ❄

混沌工程已成為提升韌性的寶貴技術，因 Netflix 的 Chaos Monkey 而廣為人知，該工具會隨機破壞線上服務，以觀察生態系統的反應與恢復能力。那麼，AI 版的 Chaos Monkey 會是什麼樣子？它會刻意在管線中引入幻覺，以測試感測器是否能捕捉到它們嗎？

❄ ❄ ❄ ❄ ❄

回到我的辦公桌

關於 Structured-Prompt-Driven Development (SPDD) 的文章，作者們在 Q&A 區塊 回答了許多問題。其中有一個問題特別引起我的注意：

你們是否考慮過讓代理自行進行提示／規格審查——不是由人類審查 Canvas，而是由代理讀取 REASONS Canvas 與程式碼差異，並驗證是否一致？

回覆中提到確實有可用的指令來執行此操作，但也有缺點。特別是不自動執行的一個原因是：

讓人類學習。審查也是人類從 AI 的選擇中學習的地方——模式、權衡、他們未曾想過的選項。將人類排除在外可以加快速度，但會阻礙 SPDD 所設計要保護的長期技能成長。[…] 一旦累積足夠的決策規則，讓我們真正有信心，我們或許可以逐步將更多審查移交給代理步驟——但人類從 AI 學習的那部分，我們計畫保留。

我們應該用來判斷 AI 工具價值的方式之一，是它能幫助我們人類對所處與所建構的世界，學到多少東西。

❄ ❄ ❄ ❄ ❄

上週我以某種奇怪的方式弄傷了手肘。我不知道怎麼發生的，並沒有哪個事件讓我說「糟糕」。它只是逐漸開始疼痛和腫脹。我終生避免運動傷害的策略1 失效了。我敷冰並服用布洛芬，腫脹消了，但活動範圍卻變差了。我很慶幸我在英國的童年學會用刀叉，所以我通常用左手吃飯。

我注意到活動範圍的喪失發生在我回家之後，當我再次整天坐在電腦前時。雖然我不會直接使用手肘，但我的右手做了很多打字和滑鼠操作。我的桌面設置相當符合人體工學，有一把 好的鍵盤、滑鼠腕墊，以及椅子上的扶手。但即便如此，我使用電腦是否讓手肘在回家後變得更糟？我無法想像不使用電腦，對我來說，寫作已經成為一種無法停止的習慣。但也許我應該利用這個機會探索語音輸入——畢竟大多數人說話的速度比打字快。

我多年前就試過，當時一位同事告訴我，語音辨識在訓練之後有多麼好用。我試了，確實即使在那些 AI 之前的時代，語音辨識也非常好。但它對我不起作用。當我寫作時，我會快速在 Emacs 中輸入文字，但幾乎立刻就會回去編輯它們。寫兩句話，編輯它們，再寫一句，重新編輯整段。看到我的文字並思考它們之間的來回往返非常緊密——我無法只是口述我的文字。

這讓我進一步反思。我是在 20 多歲時才開始使用電腦寫作。在學校時我必須手寫，在大學時則是用打字機。但那些媒介並不支持我現在所做的持續重寫。如果文字編輯器沒有被發明，我還會成為作家嗎？

❄ ❄ ❄ ❄ ❄

James Pritchard 認為許多開發人員在產品中過度使用執行時期的代理，而 LLM 更適合作為函式使用。

代理的問題不在於它們不起作用，而在於它們的作用不可預測。你用已知的執行路徑換來「自主性」，而自主性大多意味著「我不知道它會做什麼」。當代理驅動的功能在正式環境中壞掉時，你是在除錯對話紀錄，而不是堆疊追蹤。

大多數「代理」使用情境實際上是工作流程，是已知的步驟序列，其中一或兩個步驟碰巧涉及 LLM。你不需要自主性。你需要一個函式呼叫。

他指出，函式可以預測性地組合，因此如果你知道工作流程，那麼在程式文字中進行組合，會比讓代理自行協調來得好。它更快，而且需要較少的 token。通常也更容易處理失敗，因為互動的範圍較小。

❄ ❄ ❄ ❄ ❄

Pritchard 也認為人們 使用 skills 的頻率遠高於應有的程度。他認為人們累積了一堆 markdown skill 檔案，但 LLM 使用它們的方式不一致，常常在需要時忽略它們，或是在不需要時膨脹上下文。許多應該放在 skills 中的東西，應該改為 harness 的其他部分，最好是計算性的。Skills 應該只用於刻意且不常見的工作流程。

對 skills 的執著是更深層模式的徵兆：人們伸手去拿配置，而非架構。

「LLM 不會寫出好的測試。」不要寫一個測試 skill。你的既有測試是否不一致？測試設定是否複雜？修復這些問題，它就會在沒有被告知如何做的情況下寫出好的測試。指向一個你引以為傲的測試檔案。程式碼比英文更清楚。

[…]

最好的設定是，你幾乎不需要配置 LLM。一個有清晰模式的乾淨程式碼庫、一個針對不明顯事項的簡短專案配置、自動化的掛鉤，以及也許一或兩個用於你刻意執行的特定工作流程的 skills。就是這樣。

❄ ❄ ❄ ❄ ❄

關於代理式程式設計興起的一個常見觀點是，我們必須開始處理工作中的非確定性。當然，這在某種程度上是一種簡化，因為軟體開發的某些面向早已必須面對非確定性。一個顯著的例子是分散式系統，而幫助我們探索分散式系統真正令人不安之處的著名人物是 Kyle Kingsbury (Aphyr)。

上個月，他發表了一篇長文（PDF 有 32 頁），闡述他對我們由 LLM 驅動的未來的看法。標題「The Future of Everything is Lies, I Guess」透露出他對這個未來的缺乏熱情。

有些讀者無疑會對我沒有花更多篇幅討論機器學習的奇蹟感到不滿——LLM 在程式碼生成上的表現有多麼驚人，Suno 能將哼唱的旋律轉化為精緻歌曲有多麼不可思議。但這不是一篇關於開車有多快或多方便的文章。我們都知道汽車很快。我試圖問的是，城市的形狀會發生什麼變化。

這篇文章值得一讀，即使它並不特別令人振奮。Kingsbury 從一個清楚了解 AI 能力的人的角度，提出了許多對 AI 成長的擔憂。

他的觀點是，對此最好的回應是我們應該停止。他希望避免將 AI 用於他的寫作、軟體或個人生活。他認為在 AI 公司工作的人應該辭職。然而，他也知道這些工具有用，並且想要使用它們。

對於我們的 AI 未來，我既是希望者也是末日論者。從根本上說，我將任何強大的技術視為一輛大巴士：我們要嘛在上面，要嘛被它輾過。我上了這輛巴士，因為我不認為設置一些障礙就能阻止我被它的輪子壓碎。也許如果我在巴士上，我可以加入一些人，稍微影響一下司機。我也非常不願意推測任何事情的未來結果，更不用說像這樣強大的事物了。十八世紀末的早期工業家們，是否知道他們所引發的工業革命會帶來什麼？雖然它造成了許多傷害，但至少對那些搭上巴士的國家的人民來說，它也大幅提高了數百萬人的生活水平。AI 可能會創造出我無法真正想像的好處，雖然當它幫助 一位朋友延緩帕金森氏症 時，我可以瞥見一些。

這些希望是存在的，但 Kingsbury 的文章照亮了當下的陰暗面，對責任提出了嚴肅的問題

作為 Mastodon 實例的版主，我的工作一部分是回應使用者檢舉，而偶爾那些檢舉是關於 CSAM 的，我有法律義務審查並將該內容提交給 NCMEC。我不想看到這些影像，我真的希望我能忘掉它們。在那些黑暗的早晨，當我坐在電腦前發現一份 AI 生成的性侵影像的檢舉時，我有時希望在 OpenAI 等公司工作的工程師也能看到這些影像。也許這會讓他們反思他們帶入這個世界的技術，以及「對齊」在實務上是如何運作的。