即將到來的迴圈：從編碼代理向自主代理迴圈的轉變

向 Harness-Level 迴圈的轉變

軟體開發正從簡單的編碼代理轉向「harness-level 迴圈」。雖然標準的編碼代理在迴圈中運作（呼叫工具、讀取檔案、編輯、測試），但 harness-level 迴圈是一個管理代理的外部編排層。這個 harness 會決定任務是否完成；如果沒有，它可能會注入新訊息、修改上下文，或將任務移交給另一台機器，在模型通常會宣告任務已完成後的很長時間內，仍能讓過程持續進行。

「軟體即有機體」的風險

自主迴圈通常會產生優先考慮局部魯棒性而非系統完整性的程式碼，這會導致長期專案的整體程式碼品質下降。 \n### 局部防禦性的問題

模型往往「對異常極度恐懼」，導致它們傾向於添加局部防禦和回退機制，而不是建立強大的不變量（invariants）來使錯誤狀態變得不可能。當被置於迴圈中時，這種行為會被放大：每一次迭代都會增加另一個微小的防禦，使系統看起來更魯棒，但實際上卻變得更難以理解且更複雜。

人類理解力的喪失

這種轉變標誌著從「軟體作為確定性機器」——工程師可以剝開層次來理解邏輯——向「軟體作為有機體」的過渡。在這種模式下，開發者觀察症狀、提出假設，並透過 AI 應用補救措施，將系統視為更像生物實體而非設計好的機器。危險在於未來人類不再理解整個系統，僅在不真正理解其運作方式的情況下對其進行處理和穩定化。

自主迴圈何處成功

儘管對長期架構存在風險，代理迴圈在程式碼壽命並非首要要求的領域中非常有效：

• Code Porting: 大規模自動化移植工作（例如，將 Bun 的部分組件從 Zig 移植到 Rust，或將 MiniJinja 移植到 Go）展現了令人印象深刻的結果。
• Performance Exploration: 機器可以快速進行實驗、嘗試、基準測試並捨棄失敗的結果，以尋找最佳路徑。
• Security Scanning: 對複雜問題空間的自動化探索，非常適合研究與漏洞發現。
• Mechanical Translation: 可以透過二進制測試案例驗證或由另一個 LLM 判斷的任務，非常適合迴圈。

迴圈化未來的必然性

由於外部壓力，退出自主迴圈可能是不可能的：

• Security Asymmetry: 攻擊者與安全研究人員已經在使用迴圈來尋找漏洞。防禦者必須使用類似的自動化技術來分流與重現問題，其規模是人類無法手動處理的。
• Competitive Speed: 使用有效編排的小型團隊可以透過純粹的速度，在開發速度上超越大型團隊，無論底層程式碼是否為「slop」。
• Cognitive Dependency: 存在著日益增長的「認知依賴」風險，即程式碼庫被迴圈產生、審查與修補，以至於它們將機器參與視為維護模型的核心部分。

維持工程師的理性

為了在自主迴圈的未來生存，產業必須演進其工具鏈，使其超越簡單的的編排。目標是尋找方法來「將人類重新拉回迴圈中」，使機器產生的變更在長期內是可讀的。下一個工程時代的核心挑戰是：如何在利用代理迴圈速度的同時，保留人類的判斷力與良好的工程規則。