永恆的 Sloptember：為什麼 AI Agent 可能成為軟體工程中最昂貴的錯誤
AI Agent 在軟體開發中的承諾通常被框架化為向全面生產力的飛躍——一個工程師只需描述功能，Agent 就會實作的境界。然而，George Hotz (geohot) 主張，這條軌跡並非向前邁進，而是一個昂貴的錯誤。他認為 AI Agent 並非真的在「程式設計」；相反地，它們是模仿程式設計分佈的複雜統計模型。
這種區別至關重要。當一個模型模仿程式設計時，它產生的輸出看起來是正確的——語法有效、語法專業——但在根本上是破碎的，且這種破碎程度對人類來說越來越難以察覺。 Hotz 將這種現象稱為 "slop"，並警告我們正在進入一個 "Eternal Sloptember"，在這個時期，生成的代碼量遠遠超過了人類驗證其正確性的能力。
理性的幻覺
對許多人來說，與 AI Agent 的初步體驗是令人陶醉的。它們提供即時的進度爆發，以荒謬的速度衝破樣板代碼 (boilerplate) 和原型設計。但正如 Hotz 所觀察到的，這種進度是前置的。一旦初始結構建立起來，過程往往會退化成一種 "slot machine"（老虎機），開發者不斷拉動槓桿（重新提示），希望 Agent 會最終達到生產級軟體所需的精緻度與正確性。
這創造了一個危險的悖論：這些工具足以在幾分鐘內建立一個原本需要數天才能完成的原型，但它們在達到最後 5% 的品質要求時卻顯得力不從心——而這部分正是穩定性、邊緣案例 (edge cases) 和長期可維護性所在之處。
組織風險：高績效者 vs. 平均水準
討論中最具挑釁性的主張之一是，AI Agent 會對大型組織的傷害比對個人或小型、高績效團隊的傷害更大。其理由在於錯誤修正的反馈迴路 (feedback loop)。
- 高績效者： 通常具備強大的錯誤修正能力。他們將 AI 視為外骨骼——一個加速意圖的工具，而非取代批判性思考的工具。他們會閱讀並理解 Agent 產生的每一行代碼。
- 大型組織： 通常受困於較慢的反馈迴路和較低的對齊度。在這些環境中，表現不佳的開發者可能會利用 Agent 產出 10 倍於常人的代碼量，卻沒有必要的自我檢查。
因此，組織的平均輸出可能會向 "slop" 偏移。當表現不佳的開發者產出大量看似合理但脆弱的代碼時，組織整體的技術債會呈指數級增長，即便「生產力」指標（如代碼行數或功能開發速度）看起來在上升。
「正確的問題」與品味的侵蝕
除了技術性的 Bug，還存在著更深層的架構風險。社群討論中一個反覆出現的主題是「解決正確的問題」的概念。
能夠識別出應解決的正確問題，是區分頂尖資深工程師的關鍵... AI Agent 掩蓋了錯誤問題設計所帶來的摩擦力。它們並非修復它，而只是將其成本延後。
在傳統工程中，糟糕的設計選擇會產生摩擦力，從而減慢開發速度，這本身就是一種自然信號，提醒設計需要重新審視。AI Agent 移除了這種摩擦力。它們可以極其高效地實作一個錯誤的設計，以至於開發者直到系統達到災難性的規模時，才意識到設計是有缺陷的。這可能導致產生一代不再具備健全架構的「品味」或直覺的工程師，因為他們從未必須與設計選擇的後果搏鬥。
反對觀點： 「10x」差距與領域特定性
並非所有人都同意這種悲觀的展望。許多開發者主張，AI 的效用完全取決於使用者的技能水平與任務的領域 (domain) ：
- 彌補差距： 對於那些不是 "10x" 大師的工程師來說，Agent 可以彌補差距，讓他們能夠在時間限制內實作複雜的系統（例如一個 Debian package caching proxy），這在以往是無法做到的。
- 領域差異： 低階系統程式設計（如 USB reverse engineering）與高階應用程式開發（如 Node.js CRUD apps）之間存在著顯著差異。在後者中，模式高度重複且樣板代碼繁多，AI Agent 通常被被視為不可或缺的工具。
- 審查流程： 有些人認為問題不在於 AI，而在於缺乏紀律。如果一個團隊維持嚴格的 diff reviews，並為每個 Agent session 定義嚴格的範圍，那麼無論最初的代碼是如何編寫的，代碼庫的品質都會保持穩定。
結論：過程才是關鍵
最終，辯論的核心在於程式設計究竟是一種統計學練習，還是一種推理過程。如果程式設計僅僅是 token 的分佈，那麼 LLMs 幾乎已經達標了。但如果程式設計需要一個「世界模型」——即對系統在物理或邏輯環境中如何運作的理解——那麼目前的基於 RL 的模型在根本上是受限的。
隨著我們進入 AI 輔助開發的時代，真正的挑戰將不再是模型的能力，而是使用它們的人類的紀律律。目標是避免 "AI psychosis"（AI 精神錯亂），即對速度的渴望壓蓋過了對理解的必要性，導致一個軟體世界，其運作全靠偶然，而其崩潰卻是設計使然。