2026和AI一起寫程式 - 7. Steve Yegge 的 AI 協作程式的八個階段

前篇： 2026和AI一起寫程式 - 6. 再談 AI 與 沙堆模型程式

 ( 圖 by Midjourney )

Steve Yegge 提出了一個 8階段模型，描述開發軟體中，人的角色: 從工匠 -> 工頭 -> 管理 AI工頭 的演變，也才發現 AI 在 2025 年進步真的很快，先前我的概念，還停留在兩年前;

也難怪去年底，矽谷很多公司, 裁掉了軟體初階和中階工程師的職位;

目前我還在工匠階段，熟悉此階段 和 AI 協作的方法;

而為了後面這工頭模式，了解 AI Agent, 昨晚裝了 opencode, 正下載一些 local AI model, 看怎麼來進行; 實驗後再和大家分享;

各階段詳述於後＾＾

==

Steve Yegge - 維基百科英文版

Steve Yegge（史蒂夫·耶格）是一位美國資深軟體工程師、工程領導者，以及極具影響力的科技部落客，有30年以上的軟體開發經驗。

他在多家知名公司工作過, Google 是其工作最長的公司; 從 2005 - 2018 長達 13 年。職位為Senior Staff Software Engineer（資深員工工程師）。他在Google Kirkland辦公室工作，參與內部程式碼智慧平台（如Grok的前身）、程式碼搜尋與導航工具開發，也擔任過招聘委員會成員，並領導過最多150人的團隊。

他以直率、幽默且深刻的「rant」（吐槽式長文）聞名，經常討論程式語言、開發者生產力、軟體文化、公司內部運作，以及近年來最熱門的AI輔助程式開發（特別是agentic/vibe coding）。

經典的部落格文章

Stevey's Blog Rants

• 「Google Platforms Rant」（2008左右）：內部洩漏的長文，批評Google平台策略失敗，成為業界經典（至今在GitHub Gist上仍有大量討論）。

https://gist.github.com/chitchcock/1281611 

•  「Get that job at Google」：求職指南，影響無數人申請Google。

• 其他如關於JavaScript、Lisp、生產力等長文，風格幽默、毒舌，常被稱為「drunken rants」。

AI 時代：

• 2024年6月：《Death of the Junior Developer》，引入CHOP概念，預測AI會淘汰不願轉型的初階工程師，引發巨大爭議（甚至被Anthropic CEO Dario Amodei引用）

https://sourcegraph.com/blog/the-death-of-the-junior-developer

• 2024年12月：《The Death of the Stubborn Developer》

https://steve-yegge.medium.com/the-death-of-the-stubborn-developer-b5e8f78d326b

AI時代的軟體開發已從「手動寫碼」轉向「聊天導向程式設計」（chat-oriented programming，簡稱chop），拒絕chop的人會像1990年代堅持用組合語言（assembly）的老派工程師一樣，面臨職業末日。

其中提到的：軟體專案像一張圖譜，傳統上初級開發者從最底層的葉節點任務（寫小功能、修bug、寫測試）開始練功，逐步往內部節點（架構、整合、決策）爬升。現在AI已能自動化大部分葉節點，導致初級開發者的「練功階梯」斷裂。

這點個人覺得很有道理 

• 2025年3月：《Revenge of the Junior Developer》

https://sourcegraph.com/blog/revenge-of-the-junior-developer

AI編程正經歷六波演進，目前已進入「代理集群/艦隊」階段

• 2025年6月：《The Brute Squad》 

https://sourcegraph.com/blog/the-brute-squad

代理編碼已從實驗階段進入主流，生產力提升驚人，但學習曲線陡峭、易成癮；拒絕適應者將被邊緣化。公司將強推代理使用，API消耗（token burn）成為新KPI

• 2025年10月：開源專案 Beads 

GitHub: https://github.com/steveyegge/beads

專為 AI coding agent（如 Claude Code、Cursor Agent、Aider 等）設計的持久化結構化記憶系統 + 輕量圖形化 issue tracker。它解決 AI agent 的最大痛點：短期記憶與上下文遺失（session amnesia），讓 agent 能處理長時間跨會話（long-horizon）、多步驟、依賴複雜的任務，而不會每次「醒來」就忘記前情。

• 2026年1月：《Gas Town》

https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04

多代理編排系統（multi-agent orchestrator），專門解決運行大量Claude Code（Anthropic的coding agent工具）時的繁瑣問題，讓開發者能同時高效驅動20–30個AI代理，像工廠生產線般大量產出程式碼。

能解決傳統單一LLM（大型語言模型）完全辦不到的極長序列、極高步數的複雜問題。 

他特別拿「20-disc Tower of Hanoi」（20片圓盤的河內塔問題）作為經典範例，稱之為MAKER問題（來自2025年的一篇arxiv論 https://arxiv.org/abs/2511.09030 ），用來證明Gas Town的多代理編排（multi-agent orchestration）能突破LLM的根本限制。

不過他也再三強調：非常燒錢！ 

先複習河內塔（Tower of Hanoi）問題

• 經典遞迴問題：有三根柱子（A、B、C），A柱上有n片大小遞減的圓盤，要把整堆盤子從A移到C，中間只能借助B柱。
• 規則：一次只能移動一片盤子，且大盤不能放在小盤上。
• 最少移動次數：2ⁿ - 1 次。
  • 10片：1023步
  • 20片：1,048,575步（約104萬步，超過百萬步）

傳統單一LLM為什麼失敗？

根據MAKER論文和其他實測，單一LLM（如Claude、GPT系列）在這種極長序列任務上會快速崩潰：

• 上下文窗口耗盡：LLM的context window（通常128K–200K tokens）只能記住有限步數。跑幾百步後，歷史對話/狀態就塞滿，模型開始「忘記」前面的盤子位置或規則，產生無效或重複移動。
• 持續性不足：LLM是「一次性」推理，無法真正「堅持」跑上萬步。它會在幾百步後「run out of steam」（沒力氣了），停止進展或產生幻覺（hallucination）。
• 累積錯誤：每步微小偏差都會在後續放大，最終完全偏離正確解。
• 實測結果：論文顯示，LLM通常在幾百步就失敗，遠遠到不了20片的百萬步。

Gas Town如何成功處理20-disc Hanoi？

Gas Town不是讓單一LLM「一次想出全部解法」，而是用多代理 + 持久工作流 + 分子化任務的方式，把問題拆解成可持續推進的「工廠生產線」：

1. 分子化（Molecularization）與Wisps：
   • 把整個河內塔流程「分子化」成一連串的Beads（Git-backed的持久任務單元）。
   • 使用Wisps（短暫的編排Beads）：這是高速度、不持久到Git的臨時工作流，專門處理「百萬步級」的長序列。
   • 透過Formula（TOML格式的模板/公式）自動生成整個wisp：例如，一個公式就能產生「移動第k片盤子的子任務鏈」，遞迴展開成百萬步序列。
2. GUPP（Gastown Universal Propulsion Principle）：
   • 核心引擎原則：「如果你的hook上有工作，你就必須推進它」。
   • 代理不會停下來，系統會持續「nudge」（輕推，如gt nudge指令）讓Claude Code繼續跑。
   • 結合NDI（Nondeterministic Idempotence）：即使AI行為有隨機性（non-deterministic），透過明確的驗收標準（acceptance criteria）和自我修正機制，保證最終結果確定且可重複。
3. 多代理角色分工：
   • Mayor（市長）：總協調，啟動整個「convoy」（車隊/工作流）。
   • Polecats（臨時蜂群代理）：負責產生大量小步驟的Merge Requests（MRs）。
   • Refinery（精煉廠）：智能合併變化，避免衝突或遺失。
   • Witness / Deacon / Dogs：巡邏與維護代理，負責「解卡」（un-stick）、監控進度、處理中斷。
   • 這些代理平行或接力運行，狀態全存在Beads中（Git持久化），即使中斷重啟也能接續。
4. 實際執行結果（Yegge的描述）：
   • 他實際跑了10-disc版本（1023步）：幾分鐘內完成，證明千步級沒問題（遠超LLM的幾百步極限）。
   • 20-disc（104萬步）：用公式生成的wisp，預估跑約30小時就能完成（不是一次呼叫，而是持續多代理推進）。
   • 這被他稱為「trivially」（輕鬆）解決MAKER問題，因為Gas Town把「百萬步」變成可管理的持久工廠任務，而不是單一模型的推理挑戰。

===

前四個階段是在工匠模式，第五到第八階段進入 工頭/ Manager AI 模式

Stage 1: 基本自動補全（Basic Autocomplete）

• 階段描述：你自己打字寫碼，AI只在你輸入時自動補全幾行或單詞。類似傳統的IDE智能提示，但更強大，能預測上下文（e.g., 輸入"def func("，AI補上參數和簡單邏輯）。這是大多數人初次接觸AI的起點，AI就像個「打字加速器」，還沒涉及生成完整功能。

• 常見工具：GitHub Copilot（基礎版）、Cursor的autocomplete模式、VS Code的IntelliSense + AI插件、Continue.dev的輕量模式。

• 人類角色：你主動寫大部分碼，AI只補空白或修小錯（e.g., 語法錯誤）。

• 進階關鍵點：當你開始覺得「AI的補全太淺，不夠用」時，就是轉到Stage 2的訊號。關鍵是練習接受AI建議（別總是刪掉重寫），並觀察AI如何根據上下文生成。練習方式：每天寫小練習題（e.g., LeetCode easy），強迫自己用AI補全至少50%的行數。轉折：從「被動接受」到「主動請求生成」。

最近我發現, 很多 IDE 開發環境, 都開始有 AI 輔助整合這一個功能;

例如 Intellij IDEA , 像先前的 沙堆模型 程式, 我有個 MyLog 物件,

打 TAG 參數定義時, 會自動把後面我要加的該物件或該檔案的名字帶入,

只要按 TAB 即可完成

Stage 2: 生成小片段或函數（Snippet/Function Generation）

• 階段描述：你不再只靠自動補全，而是主動「問」AI生成特定小片段（e.g., "寫一個Python函數來排序列表"）。AI輸出完整但簡單的碼塊，你複製貼上後微調。這階段AI開始像「助手」，但還在編輯器內，生成範圍限於單一函數或小模組（<50行）。

• 常見工具：Cursor的Composer模式、Claude in IDE（e.g., Anthropic的VS Code插件）、Copilot Chat、Windsurf的inline生成。

• 人類角色：你描述需求（prompt），AI寫碼，你審核+整合到專案中。重點是迭代：如果AI錯了，你回頭改prompt再生成。

• 進階關鍵點：當生成的小片段開始連成「功能塊」時（e.g., 不只一個函數，而是相關的幾個），就是Stage 3的起點。關鍵是精煉prompt技巧：從模糊描述（"寫排序"）進化到精準（"用Python寫bubble sort，處理邊界情況，包含單元測試"）。練習方式：用AI生成日常小工具（e.g., 腳本處理CSV），記錄每次prompt的優化。轉折：從「單次生成」到「多次迭代對話」。

像 MyLog 物件製作，即是我請 AI 實作出來的

https://github.com/neojou/sandpile/blob/main/src/commonMain/kotlin/com/neojou/MyLog.kt

Stage 3: 迭代生成中型碼塊（Iterative Medium-Sized Code）

• 階段描述：AI生成更大的碼塊（e.g., 整個class或小模組，50–200行），你透過聊天式互動迭代（e.g., "這錯了，加error handling"）。這階段強調「對話」，AI記住上下文，能逐步精煉輸出。還是編輯器內，但你開始依賴AI處理邏輯細節。
• 常見工具：Cursor的全聊天模式、Claude Code的conversation view、Copilot的workspace chat、Continue.dev的context-aware生成。
• 人類角色：你提供初始架構或spec，AI生成初稿，你反饋修改（loop 2–5次）。最終你整合到repo。
• 進階關鍵點：當你發現「單一生成不夠，需AI debug或refactor」時，转到Stage 4。關鍵是培養審核能力：快速掃描AI碼的bug、安全漏洞、效能問題。練習方式：拿開源專案的issue，重現並用AI迭代修復。轉折：從「生成新碼」到「用AI優化既有碼」。

先前的確寫大一點程式時（井字遊戲)，執行時有遇到一些 bug; 發現是自己提供的邏輯有誤;

Stage 4: 完整功能開發與debug（Full Feature with Debugging）

• 階段描述：AI不僅生成，還幫你debug、refactor、寫測試（e.g., "重構這段碼，加unit tests，修bug"）。你能用AI處理完整功能（e.g., 從需求到可運行的feature），但還在編輯器內循環。AI像「資深夥伴」，能處理複雜邏輯，但你仍需最終把關。
• 常見工具：Cursor的advanced agent模式、Claude in IDE的full loop、Copilot的PR-ready生成、Windsurf的debug chain。
• 人類角色：你定義高層需求，AI生成+測試+優化，你只改關鍵部分。重點是整合到git flow（e.g., commit前用AI review）。
• 進階關鍵點：當你覺得「編輯器內太侷限，想讓AI自己跑環境」時，就是跳到Stage 5（單一agent）的訊號。關鍵是建置強大測試套件（AI生成碼易錯，需自動化驗證）。練習方式：完整開發小app（e.g., CLI工具），用AI cover 80%工作，測量時間節省。轉折：從「編輯器內互動」到「跳出編輯器，讓AI自主執行」。

- 正在學習 refactor , 例如前篇所記錄的這個： https://github.com/neojou/sandpile/commit/9ba3f7ef0ebaf1811eb51aa615a27721d2b179d8

- 繼續看怎麼生成 debug code 和 debug

整體進階建議（前四階段通用）

• 常見瓶頸：信任問題（AI碼常有hallucination，如邏輯漏洞）、prompt疲勞（寫好prompt很累）。
• 加速訣竅：1. 每天練習1小時，記錄prompt template（e.g., 用Notion存常用格式）。2. 結合測試框架（pytest/Jest），讓AI生成後自動跑。3. 從簡單語言開始（Python/JS），再擴到複雜（如Rust/Go）。4. 測量進度：計算「AI貢獻的行數比例」，從Stage 1的10%到Stage 4的70%。
• 為什麼前四階段重要：這是基礎，練好能讓你生產力翻倍（e.g., OpenAI內部報告，工程師寫碼速度快30–50%）。多數人（~70%）停這裡，因為Stage 5起需學新工具（agent CLI），風險更高（AI可能搞壞環境）。

===

Stage 5: 單一agent跳出編輯器，自主跑完整任務（CLI, single agent, YOLO mode）

• 階段描述：你開始跳出傳統編輯器（如VS Code / Cursor），直接用CLI工具讓單一AI agent自主處理整個ticket或任務。AI會自己讀取repo、修改檔案、跑測試、產生diff / commit / PR，甚至debug環境問題。你可能只看diff或結果，不再逐行介入。這階段AI像「獨立實習生」或「YOLO模式」（You Only Live Once，信任爆表），開始感覺「AI在自己寫軟體」。工作流從「聊天生成」轉為「派任務 → 等結果 → 審核」。
• 常見工具：Claude Code CLI、Aider、OpenCode、Cursor Agent模式（CLI版）、Cline / RooCode、Codex CLI變體。許多人用tmux或終端多開來監控。
• 人類角色：你寫高品質spec / ticket（prompt），給agent完整上下文（repo路徑、依賴說明），然後監控輸出。重點是「餵食」好任務，讓agent自己推進；你只介入卡住時（nudge）或最終審核。開始練習「信任但驗證」：快速掃diff、跑測試、找hallucination。
• 進階關鍵點：當單一agent跑得順，但你想同時處理多個功能（frontend + backend + test）時，就是轉到Stage 6的訊號。關鍵是建立強大regression test suite與清晰的acceptance criteria（AI最怕模糊需求）。練習方式：拿個人專案或小開源issue，讓agent完整從0到PR，測量「人類介入次數」與時間（目標：人類時間降到20%以下）。轉折：從「單一任務監督」到「多任務平行管理」。

Stage 6: 多agent手動管理（CLI, multi-agent, YOLO, 3–5 parallel instances）

• 階段描述：你同時跑3–5個（或更多）agent實例，每個專注不同子任務（e.g., 一個寫API、一個寫frontend、一個寫測試、一個refactor）。用tmux / 多終端或簡單腳本切換監控diff stream。AI開始像「小團隊」，你頻繁檢查、nudge卡住的、合併結果。這階段生產力爆發（可能5–10x），但人類負擔也大：review跟不上、上下文散亂、易出衝突。
• 常見工具：多開Claude Code / Aider終端、tmux + script分派、Beads（持久記憶工具，幫助追蹤任務狀態）、簡單bash / Python wrapper派任務。部分人用AutoGen / CrewAI的輕量版手動調度。
• 人類角色：像「工頭」管3–5個實習生：拆大任務成小bead / 子任務、分配給agent、監控進度、解決衝突、合併PR。你開始感覺「管不過來」，review時間變長，但整體產出遠超單人。
• 進階關鍵點：當10個以上agent時，手動切換 / 追蹤已接近極限（認知負荷爆表），就是Stage 7的起點。關鍵是練習任務拆解與優先級管理（用Beads或簡單todo list）。練習方式：用多agent開發中型功能（e.g., 完整web app feature），記錄「人類花費時間 vs. agent總token」；目標：同時監控5+ stream而不崩。轉折：從「手動多開」到「需要自動調度系統」。

Stage 7: 10+ agent，手動已極限（10+ agents, hand-managed, pushing limits）

• 階段描述：你管理10個以上agent，頻繁手動nudge、監控、合併，但已明顯感覺人類是瓶頸（review負荷、遺漏錯誤、燒API錢）。這階段像「工頭過載」，開始意識到需建自動化層來減輕負擔。產出極高，但品質控制與成本管理變成挑戰。
• 常見工具：自寫簡單orchestrator（bash / Python script + Beads）、LangGraph / AutoGen / CrewAI框架的客製版、多開tmux + 監控腳本。Gas Town的早期原型或類似系統開始出現。
• 人類角色：高層規劃 + 頻繁介入（dispatch、un-stick、merge）。你定義大方向、審核最終輸出，但日常細節全交agent。重點是「防崩潰」：設guardrail、cost limit、error recovery。
• 進階關鍵點：當手動調度已無法scale（e.g., 每天燒幾百美元API、review追不上），就是Stage 8的訊號。關鍵是學orchestration基礎（router、長期記憶、tool use）。練習方式：用CrewAI建簡單多agent pipeline（e.g., planner → coder → tester → reviewer），測試在真專案。轉折：從「手動管理」到「建自己的調度系統」。

Stage 8: 自建調度系統，AI管AI（Building your own orchestrator, frontier）

• 階段描述：你建了一套完整orchestrator（如Gas Town），讓「Mayor」AI自動拆任務、派給專門agent（coder、reviewer、tester、refinery等）、平行跑、整合結果、處理錯誤/合併。AI像「工廠」，人類只定大方向、審核最終產出，幾乎不寫碼。這是前沿階段，產出可達傳統團隊數十倍，但需高工程能力與燒錢（API成本高）。
• 常見工具：Gas Town（Yegge的開源實現）、自建Beads + 自訂腳本、LangGraph / AutoGen進階版、OpenDevin-like系統。公司內部平台（如Block的Repo Quest + agent fleet）。
• 人類角色：像「工廠老闆」或「Mayor」：定義願景、監控整體產出、處理例外（極少介入）。重點是系統設計與風險控制（e.g., GUPP推進原則、NDI idempotence）。
• 進階關鍵點：這已是頂峰，進一步可能是「聯邦agent」或「Mol Mall」（公式市場）。關鍵是建持久記憶 + 自動恢復（用Beads）。練習方式：從Gas Town fork開始，客製你的factory（e.g., 加專門agent角色）。轉折：無限擴展，但需面對成本、穩定性、倫理挑戰。

整體進階建議（第五到第八階段通用）

• 常見瓶頸：review跟不上（品質崩）、API燒錢（每日數百美元）、agent卡住 / hallucination累積、學習曲線陡（需懂orchestration）。
• 加速訣竅：1. 先練強大測試套件與spec寫作（AI最依賴）。2. 用Beads建持久記憶，避免重複解釋。3. 從Stage 5小任務開始，逐步加agent數。4. 監控成本與產出（token / PR速率）。5. 加入社群（如Gas Town contrib）學前沿實踐。
• 為什麼後四階段重要：Stage 5–8讓生產力從2–5倍跳到10–50倍+（Yegge自稱2025年產出近百萬行碼）。但只有~5–10%開發者到這裡，因為需高信任、工程基礎與金錢成本。多數人停在Stage 4–6，Stage 8是前沿玩家（如Yegge）的領域。