當開發看板成為新的 IDE：AI Agent 如何將軟體工程的重心轉向「流程控制」
想像一下，你的開發看板不再只是任務清單，而是驅動 AI Agent 完成所有開發工作的「控制中心」。baton 這個開源專案，正將軟體開發的重心從手寫程式碼，轉移到更高層次的「流程定義與狀態管理」。這篇文章將深入探討，當 AI Agent 接手實作細節後，人類工程師的價值將如何重新定義，以及我們將面臨哪些新的挑戰。
近期的 AI Agent 發展正將軟體開發的核心價值，從「親手撰寫程式碼」轉移到更高層次的「流程定義與狀態管理」。一個名為 baton 的開源專案具體而微地展示了這個未來：開發者只需在看板上移動任務卡片，AI Agent 便會自動完成實作、發出 PR、監控 CI。這意味著，當實作細節被大規模自動化後，人類工程師的真正瓶頸與價值，將不再是編碼速度，而是能否精準定義工作流程的狀態轉移、驗收條件與例外處理，成為整個開發系統的「控制平面」設計者。
baton 是什麼？它如何顛覆傳統開發流程？
最近，由日本開發者 Kensuke Terui 發布的開源工具 baton，提供了一個非常具體的想像。它將我們熟悉的開發看板（例如 Notion 或 GitHub Issues）與本地端的編碼 Agent 串連起來。
整個工作流程的觸發點極其簡單：只要開發者將一張任務卡片從「待辦」欄位拖曳至「進行中」（In Progress），baton 就會啟動一連串的自動化程序。
這個程序涵蓋了傳統開發週期的大部分環節：
- 自動實作：本地的 AI Agent 會根據任務描述，開始撰寫或修改程式碼。
- 建立 PR：完成初步實作後，Agent 會自動建立一個 Pull Request (PR)。
- 監控 CI：PR 提交後，baton 會持續監控 CI (Continuous Integration) 的狀態，確保測試通過。
- 回應審查：它甚至能根據初步的程式碼審查意見進行修改。
- 偵測合併：直到 PR 被合併，整個任務才算完成。
在這個模型中，人類開發者的角色從一個親力親為的「執行者」，轉變為只需專注於看板的「管理者」或「監控者」。這並非單純的腳本自動化，而是一個由高層次意圖（移動卡片）驅動的複雜工作流，是軟體開發人機介面的重大轉變。
為什麼說這是「控制平面」的轉移？
「控制平面」（Control Plane）是源於網路與分散式系統的詞彙，指的是系統中負責決策、設定狀態、下達指令的部分，而「資料平面」（Data Plane）則負責實際執行這些指令。
以 Kubernetes 為例，使用者透過 YAML 檔案向 API Server 宣告（declare）期望的系統狀態，這就是控制平面；而 Kubelet 在各節點上實際運行容器，則是資料平面。使用者不需手動操作每個容器，只需定義最終目標。
baton 所展示的，正是將這個概念應用於軟體開發流程。過去，開發者的工作大多發生在「資料平面」：在 IDE 裡寫程式碼、在終端機下 Git 指令、手動觸發 CI/CD。現在，看板成了新的「控制平面」。開發者在看板上定義任務的「期望狀態」（例如，從「待辦」變成「進行中」），而背後的 AI Agent 系統則負責所有底層的實作細節，將系統推向該狀態。
當機器能完美執行指令，人類的價值就體現在「定義出好的指令」。開發者不再是與程式碼直接互動，而是與定義程式碼生成流程的系統互動。
這種轉變，呼應了 Andrej Karpathy 多年前提出的 Software 2.0 概念。我們不再是直接撰寫邏輯（Software 1.0），而是設計一個能找出正確邏輯的系統（例如訓練一個神經網路）。如今，在 AI Agent 的驅動下，我們正在進入一個「開發流程 2.0」的時代：我們不再是手動執行每個開發步驟，而是設計一個能自動執行這些步驟的流程與規則。
當寫 Code 不再是瓶頸，新的挑戰是什麼？
當 AI Agent 能處理越來越多實作細節，開發工作的瓶頸與核心技能也隨之改變。過去，我們衡量一個工程師的產出，可能看他寫了多少行程式碼、解了多少複雜的演算法。未來，關鍵將轉向以下幾點：
1. 精準的任務定義與拆解
AI Agent 的能力強弱，高度依賴輸入的品質。如果任務描述模糊不清、需求矛盾，Agent 產出的結果也將是垃圾。因此，如何將一個模糊的商業需求，拆解成一系列原子化、可驗證、無歧義的具體任務，將成為首要技能。這需要比以往更深刻的領域知識與系統性思考。
2. 嚴謹的驗收條件（Acceptance Criteria）
如何驗證 Agent 的產出符合預期？這不僅僅是單元測試或整合測試。我們需要定義更全面的驗收標準，可能包含效能指標、安全性掃描、使用者體驗的量化標準等。這些標準將成為 Agent 工作循環的終止條件與品質閘門，其重要性遠超以往。
3. 系統性的例外處理
自動化流程必然會出錯。CI 可能會失敗、Agent 可能會誤解需求、產出的程式碼可能有效能陷阱。一個成熟的「控制平面」設計者，必須預先設想各種失敗情境，並定義好應對策略：是自動重試？還是發出警報交由人類介入？或是觸發另一個 Agent 進行修復？這種對系統韌性的設計能力，將變得至關重要。
像 Devin 或 SWE-agent 這類 autonomous agent 的研究，已經在 SWE-bench 這類真實世界的軟體工程問題集上，達到了接近 14% 的無輔助解決率。這個數字雖然不高，卻標示了一個清晰的起點。
從 baton 這類工具開始，我們正在見證軟體工程從一門「手藝」逐漸轉向一門「系統設計與治理」的科學。未來的頂尖工程師，或許不再是打字最快的人，而是那個能設計出最高效、最可靠的開發流程與狀態機的人。
延伸閱讀
- baton on GitHub: 專案的原始碼與說明文件。
- 原文 Zenn.dev 文章: 開發者 Kensuke Terui 的第一手介紹（日文）。
- Software 2.0: Andrej Karpathy 關於程式碼典範轉移的經典文章。
- SWE-bench: Can Language Models Solve Real-World Software Engineering Problems?: 關於評估大型語言模型解決軟體工程問題的學術論文。
- What is a control plane?: Red Hat 對於控制平面的清楚解釋。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。