The Great Loops Debate — Dex Horthy, Geoff Huntley, Ian Livingstone, Greg Pstrucha, @insecure-agents

這場辯論圍繞一個核心問題展開：業界關於 AI 代碼生成循環的宣傳，是否超越了實際可用性。支持者（Ian Livingstone、Jeff Huntley）認為 Loops 已經成熟可用，是軟體工程的必然演進；懷疑者（Dex Horthy、Greg Kostusha）則認為，目前的 Loops 實踐仍存在巨大鴻溝，尤其在經濟可行性和品質控制上。

Jeff Huntley 分享了他在 Canva 的親身經歷。當時他觀察到工程師不斷提示 AI 做同樣的事，意識到這可以被程序化。他創造的 Ralph Loop—一個簡單的 Bash 迴圈，透過不斷清空上下文窗口、注入新狀態、執行單一步驟—證明了低成本自動化的可行性。成本約為每小時 10.42 美元，這意味著 Loops 生成的代碼品質已超越大多數開發者。然而，Jeff 同時強調，這不是銀彈，而是一種新的工程紀律。關鍵在於用 Pre-commit hooks、Linter、靜態分析築起防線，像「機車工程師」一樣把失控的 AI 牢牢限制在軌道。

Dex 和 Greg 的擔憂則更深刻。Dex 指出，Hype 已經超越紀律。人們渴望用 Loops 解決架構決策、UI 設計判斷這些根本上需要人類品味和經驗的問題。Greg 用具體數據支撐：大型公司仍需要 Sentry 這類工具捕捉簡單 Bug，代表 Loops 尚未解決基本問題；經濟上，如果代幣成本無限增長（迴圈次數愈多誤差率愈高），整個模型就不可持續。最諷刺的是 Jeff 自己的 Loom 實驗—試圖讓 Loops 自動建造軟體平台—已停滯六個月，因為「需要更好的編程語言或模型」。

實踐層面，Loops 的成功有明確邊界。它在高度可驗證的任務上表現優異：安全掃描（每個 PR 約 5 美元但帶來實際價值）、多語言代碼遷移（如 TypeScript 到 Golang）、已有完整測試套件的系統重寫（如 Rust 遷移）。但對於需要權衡的決策—選擇簡單性或複雜性、什麼該構建什麼不該、API 設計—Loops 傾向盲目複雜化，工程師必須保持掌控。

速度提升上，現實與夢想差距明顯。Dex 強調，可行的目標是 2-3 倍速度提升，足以改變所有企業的經濟學，而不是 100 倍。試圖激進優化會陷入「元優化地獄」，最終失去代碼可讀性和架構掌控。正確做法是從小迴圈開始，逐步在系統各處嵌入 Loops，一天忽然會發現整個組織快了 2-3 倍，同時仍保有代碼主權。

最後是供應鏈的深層轉變。Jeff 提到他已十個月不依賴開源，而是用 Loops 直接生成並修改代碼。這推動靜態類型語言（Rust、Haskell）重要性上升—型系統成為驗證的基礎。同時，Git 的簽署機制需要擴展以追蹤多方代理行為，責任最終仍歸人類。整個軟體工程的信任模型正在重構。