編按：本文綜合整理自 Armin Ronacher 的〈The Coming Loop〉、Pragmatic Engineer Podcast 相關集數、Geoffrey Huntley 的 Ralph Wiggum 技術文，並加入 Siami 編輯部觀點與分析。
背景：什麼是「Loop」？
近幾個月，開發者社群出現了一種繞著 AI 編碼代理（coding agent）打轉的新型工作流。Anthropic 的 Claude Code 創辦人 Boris Cherny 在訪談中直言：「我已經不再手動下 prompt 了。我有跑著的迴圈在 prompt Claude，然後判斷下一步該做什麼。我的工作是寫迴圈。」
這句話被 Armin Ronacher 引用在最新文章〈The Coming Loop〉的開頭，引發整個工程師社群的討論。Ronacher 是 Flask 框架作者、Sentry 共同創辦人，也是新興 AI 編碼代理 Pi 的早期投資人與重度使用者。他對這波「loop 化」浪潮抱持複雜態度：既承認「the coming loop」幾乎無可避免，也對人類工程師角色的流失提出尖銳質疑。
「我比我想承認的還更常想著那種迴圈。」—— Armin Ronacher
這篇文章不只是技術分析，更像是資深工程師對整個產業走向的「提前告別信」。
兩種迴圈的差別
Ronacher 區分了兩種完全不同的「loop」：
Agent 內部迴圈（模型對工具）
這是 Claude Code、Codex、Aider 等工具內建的迴圈：模型呼叫工具、讀取結果、調整方向、再呼叫下一個工具、修改檔案、跑測試，最終產出答案。這種迴圈開發者早已熟悉，工程師在過程中可以隨時介入與調整方向。
Harness 外部迴圈（迴圈包著迴圈）
這是 Ronacher 真正關注的——harness（編排層）包在 agent 外面的迴圈。工作被丟進一個佇列，機器接手嘗試、停下來，然後由另一個機制判斷「這算不算結束」：
- 如果還沒結束，就在同一個 session 繼續注入訊息
- 或者開新的 session，帶著修改過的 context 重來
- 或者把任務丟給另一台機器
這個任務會一直存活到「模型自己說 done」之後。Geoffrey Huntley 提出的「Ralph Wiggum technique」就是這類模式的典型：用簡單的 bash 迴圈把 AI 輸出（連同錯誤）重新餵回去，直到它「夢到」正確答案為止。Huntley 在 Y Combinator hackathon 中示範過「把 coding agent 丟進 while 迴圈，一晚就 push 了 6 個 repo」的場景。
Ronacher 觀察到，這種 harness-level 的迴圈從 Claude Code 早期就有了，但近幾週它在 Twitter 上的討論度急劇飆升，已經主導整個 agentic engineering 的話題。
為什麼有些場景特別適合
Ronacher 承認，loop 模式在某些領域「驚人地有效」：
- 程式碼移植：例如把 Bun 部分程式碼從 Zig 移植到 Rust 的大規模自動化移植工作；Ronacher 自己也曾用 loop 把 MiniJinja 移植到 Go。
- 效能探索：機器可以不斷嘗試實驗、跑 benchmark、丟棄失敗、繼續搜尋。
- 資安掃描：天然適合迴圈化。
- 研究類任務：請系統探索一個複雜的問題空間並回報，不一定留下長期程式碼。
這些成功案例有個共同點：它們要嘛不產生新程式碼、要嘛產生短期壽命的程式碼，像是概念驗證、研究發現、或機械式轉譯。Ronacher 認為，能產出「不需要長期保存」的成果、或可驗證的機械翻譯的迴圈，比那種「harness 機械式衡量某個目標」的一般化能力更有價值。許多成功的 loop 應用會用另一個 LLM 當作 judge 或 orchestrator。
Claude Code 在建立整個實驗流程並執行這件事上越來越強；至於產出的程式碼是否夠乾淨，那是模型的問題，不是 harness 沒有能力判斷「這一步有沒有讓事情變好」的問題。
🚨 為什麼這件事重要
Software as Organism — 軟體從機器變成有機體
Ronacher 用了一個非常關鍵的隱喻：從「軟體是確定性的機器」轉向「軟體是有機體」。
他這一代工程師是在「鼓勵理解機器」的環境中成長的：總有可以一層一層剝開、加深理解的層次。理想上，程式碼被設計成連新工程師都能透過巧妙架構去導航複雜的 codebase；在設計良好的系統裡，永遠有工程師知道 invariance 在哪、哪些部分是 load-bearing 的、哪些變動是安全的。
然而，在 LLM 時代正在這個方向上推得更深、推得更快。已經有不少工程師活在這樣的世界裡：生產環境出問題時，第一步是請「clanker」（Ronacher 對 AI agent 的暱稱）讀 log、提出 root cause、主動丟 patch，然後另一台機器接手 review，有時候甚至完全沒有任何人類監督就直接 merge 到 main branch。
這聽起來當然很有吸引力。但 Ronacher 認為，特別是在人類監督越來越少的情況下接受這個想法，等於接受可能不再以同樣的方式理解整個系統。治療它、監控它、穩定它，但不一定理解它。
無法「光榮退出」也是問題
另一個讓 Ronacher 非常不安的點是：可能根本無法選擇不加入這場迴圈。
最清楚的例子是資安。即使不用 loop 來寫程式碼，攻擊者會用 loop 攻擊軟體。安全研究員也會用 loop，而這些自動化工作中有些會丟出噪音，但也會找到真正的問題。signal 跟 noise 都會以幾乎無法處理的量湧向你，除非自己也派機器上。
Daniel Stenberg 在 curl「summer of bliss」 的文章中就是這類壓力的縮影——即使 AI 在 curl 核心開發中沒有扮演重要角色，維護者已經被 AI 生成的回報淹沒了。
如果攻擊者跟回報者都在 loop，防禦者最終也得 loop 才能跟上——也許不是直接寫 patch，而是 triage、重現，壓力會持續升高。
正在建立新的依賴關係
最讓 Ronacher 害怕的是：正在用新的方式依賴這些機器。軟體一直以來都依賴工具——他記得當年要付費買 compiler 的時代。但這些新工具讓他想起過去那種「寫軟體有真實成本」的年代，差別在於這不再是「一次買斷」，而是持續性的依賴。
不只是錢包的依賴，也是認知的依賴。
Ronacher 質問：
如果一個 codebase 是被 loop 生、被 loop review、被 loop patch、被 loop 維持的，當不再能取用同等級的系統時會發生什麼事？當某些貿易限制讓你拿不到最強的模型時呢？當成本變得無法負擔時呢？當你跟你的團隊失去「不靠機器也能讀懂自己程式碼」的能力時呢？
可能正在創造的不是「對人類難以維護」的 codebase，而是**「把機器參與當作維運模型一部分」**的 codebase。這已經在發生了。
🚨 數據解讀 / 質疑
Siami 編輯部觀察
把 Ronacher 的反思放回更廣的脈絡——這不是個人抱怨，而是整個產業正在經歷的集體焦慮。Pragmatic Engineer 在最近一集 podcast 中提到，根據對 30 個以上工程團隊的訪談，「agentic 產出讓程式碼品質下降，但這不是刻意的」，而且多數開發者其實不知道要怎麼刻意保持乾淨。
更值得警惕的是 Nvidia CEO 黃仁勳在 2026 年中的公開發言：「沒人在寫 prompt 了。新工作就是寫跟處理 loop。」這個訊號代表：
- 大廠正式承認這是產品方向，不是邊緣實驗
- 「工程師」這個角色的定義正在被重新協商——從「寫程式碼的人」變成「設計迴圈的人」
- Token 成本正在重塑軟體經濟學——同樣的功能，可以由 5 人小團隊用 loop 在幾天內完成，或 50 人傳統團隊用幾個月；哪邊會贏不一定是技術問題
「不喜歡」不等於「不會發生」
Ronacher 自己也很誠實地承認：「沒有任何疑問這個 looping 的未來將會是我們的未來，即使現在討厭它。」
他看到有些小團隊用不可能的速度建造東西，也看到 codebase 越來越變得只能由更多機器診斷的「混亂有機體」。這些 codebase 同時是有用的也是混亂的。
所以重點不是「要不要 loop」——顯然會 loop。真正的問題是：
在一個 loop 的未來裡，要怎麼不放棄判斷力、要怎麼保留好的工程規則、要怎麼確保有責任感的人類能繼續監督、要怎麼重新思考如何架構程式碼才能沿路保持理智？
Loop 的危險訊號
從 Ronacher 的分析可以歸納出幾個需要警惕的徵兆：
- 「done」失去意義：當結束訊號只是被傳給另一個機器判斷時，人類對「完成」的定義就瓦解了
- 責任分散：工程師從「作者」變成「傳令」，沒有人對最終結果負全責
- 防禦性程式碼累積：每個 iteration 都加一層小防線，系統表面看起來更穩固，實際上更難理解
- 認知依賴加深：當所有人都依賴 LLM 來摘要、重新表述、表達意見時，集體思考能力會下降
Pi 的角色與未來
Ronacher 也是 Pi（Mario Zechner 打造的極簡 AI 編碼代理）的重度使用者與支持者。他在這篇文章中微妙地調整了對 Pi 的看法：
Pi 一直以來都很謹慎，這種謹慎是好的。不想要一個未來，每個互動都變成無法控制的機器群，做出無法追蹤的改變。
他不希望 Pi 為了搶「會自我寫的軟體」這場競賽而變得難以維護，也不希望 Pi 鼓吹這類工程。但同時他也承認：Pi 是個 harness，而 harness 正處於人們進行這類新實驗的中心。
任務佇列、子代理、持久 session——這些會越來越重要。即使是那些對 loop 有保留、沒有盲目擁抱的人也必須開始做這些實驗，因為他們需要理解如何讓這個未來「有邊界、可存活」。
結語：工程師的角色重定義
Ronacher 的核心訊息其實很簡單：
- Loop 會來——擋不住、也最好不要擋
- 但現在可以決定——是要放棄判斷力，還是設計出能讓人類保持在 loop 中的工具
- 「只是個 messenger」的未來——不是工程師該有的位置
這篇文章不是反對 AI 的宣言，而是一個深度參與 AI 工具開發的人，對「如何避免失去工程師靈魂」的提前呼籲。對任何一個還在懷疑「是不是該更積極擁抱 agentic coding」的人來說，這都是必讀。
延伸閱讀：
- Pragmatic Engineer Podcast: Building Pi — Mario Zechner 與 Armin Ronacher 的深度對談
- Geoffrey Huntley: Ralph Wiggum as a ‘software engineer’ — Ralph 技術的原點
- Daniel Stenberg: curl’s summer of bliss — 開源維護者被 AI 報告淹沒的真實案例
- Karpathy: models are ‘mortally terrified of exceptions’ — 為什麼 LLM 傾向寫過度防禦性的程式碼