從編碼到編排：AI 如何重新定義開發者的角色

Published: at 12:00 AM

軟體開發的方式正在發生根本性的轉變。這不僅僅是 AI 現在能夠生成程式碼——我們已經擁有這項能力好幾年了。真正改變的是我們與程式碼本身的關係。

我最近意識到，自己花了整個下午構建一個功能，卻沒有寫過一行程式碼。這不是因為我偷懶，而是因為我忙於編排三個 AI agent 在兩個 repository 中並行工作。一個 agent 實作後端 API，另一個構建前端 UI，第三個撰寫測試套件。我的工作是定義需要完成什麼、在它們的進度之間切換上下文，並在高層次上審查它們的工作。

這不是一次孤立的實驗。這正在成為新常態。

目錄

AI 編碼工具的三個世代

回顧過去，AI 編碼工具經歷了三個截然不同的世代，每一代都從根本上重新想像了開發者的角色：

第一世代：自動完成時代（2020-2023）

GitHub Copilot 於 2021 年推出並設定了範本：AI 作為超強的自動完成工具。你打字，它建議下一行，你按 Tab 接受或繼續打字拒絕。編輯器仍然是你的主要介面。AI 是一個有用的助手，但你仍在編寫每一行程式碼。

開發者的角色：偶爾接受 AI 建議的程式碼撰寫者。

侷限性：單檔案、單任務焦點。你仍然花費大部分時間在實作細節的雜草中。

第二世代：自主 Agent 時代（2023-2024）

然後出現了基於 CLI 的 agent，如 Aider 和 Claude Code。這些工具不再是自動完成你的按鍵，而是讓你用自然語言描述你想要什麼，它們會自主修改多個檔案、執行測試並提交變更。

$ aider
> Add authentication to the API with JWT tokens
> Run the tests and fix any failures
> Update the README with the new auth flow

這是自主性的階躍變化。AI 不僅僅是建議——它在執行。你可以委派整個功能，然後回來審查結果。

開發者的角色：審查並迭代 agent 輸出的任務委派者。

侷限性：糟糕的會話管理和視覺化。同時處理多個功能意味著要在終端標籤之間切換。上下文切換很痛苦。

第三世代：編排時代（2025-現在）

現在我們進入第三世代：專為同時管理多個 AI agent 而設計的平台。突破發生在 2025 年初，當 OpenAI 推出 Codex（2025 年 5 月 16 日）——不只是另一個程式碼編輯器，而是一個完整的編排平台。結合 Cursor 2.0+ 等工具以及像 OpenCode（一個 TUI/原生應用混合體，正在獲得關注）這樣的輕量級替代方案，我們終於有了專門設計用於同時管理多個 AI 編碼會話的原生應用程式。

開發者的角色：定義結果並協調並行工作流的 agent 編排者。

典範轉移：你不再大部分時間待在編輯器中。你在編排儀表板中，管理多個 agent 和 repository 的上下文。

什麼改變了？為什麼是現在？

兩個技術突破促成了這種轉變：

1. AI 可靠性跨越了閾值

像 Claude Sonnet 4.5、GPT-5.2 和 DeepSeek R1 這樣的模型生成正確程式碼的頻率足夠高，以至於逐行審查現在是瓶頸而不是必需品。你可以信任 agent 處理整個功能，而不僅僅是樣板程式碼。

這並不意味著 AI 是完美的——遠非如此。但錯誤率已經下降到足夠低的程度，監控每一行比在功能層面審查更低效。

2. Git Worktrees 實現真正的並行性

Git worktrees——一個相對不為人知的功能，讓你可以在不同目錄中同時檢出多個分支——結果是多 agent 工作流程中缺少的部分。

# 傳統問題：兩個 agent 在不同功能上工作
# 在同一目錄中互相阻塞

# Worktree 解決方案：
git worktree add ../feature-auth auth-branch    # Agent 1 在這裡工作
git worktree add ../feature-search search-branch # Agent 2 在這裡工作
# 主目錄繼續在 main 分支上

現在你可以給 Agent 1 認證功能，給 Agent 2 搜尋功能，它們在完全隔離的環境中工作。沒有合併衝突，沒有阻塞，真正的並行執行。

OpenAI 的 Codex 將這個功能直接內建到其介面中。當你在「worktree 模式」中創建新執行緒時，它會自動為該 agent 設定隔離環境。你在執行緒之間切換以檢查進度，而不是為了避免衝突。

新的開發者工作流程

這是編排優先開發的一天實際上的樣子：

早上：你打開編排平台（Codex、Cursor、OpenCode 或類似工具）並看到三個專案：

  • 你的主要 web 應用程式
  • API 服務
  • 行動應用程式

你為今天的優先事項創建執行緒：

  • 執行緒 1（API）：“為認證端點添加速率限制”
  • 執行緒 2（Web）：“實作深色模式並持久化使用者偏好”
  • 執行緒 3（API）：“重構資料庫查詢以使用連接池”
  • 執行緒 4（行動）：“修復 Android 13 上報告的崩潰問題”

你為每個執行緒分配一個 agent。執行緒 1 和 3 使用 worktree 模式，因為它們都在處理 API。所有 agent 同時開始工作。

上午中段：你在執行緒之間切換，審查進度：

  • 執行緒 1：Agent 推送了一個 PR，你添加行內註釋請求變更
  • 執行緒 2：仍在進行中，目前看起來不錯
  • 執行緒 3：遇到問題，你用額外的上下文優化提示
  • 執行緒 4：完成，測試通過，你合併 PR

下午：收到新的緊急請求。你創建執行緒 5：“調查為什麼電子郵件通知延遲。“Agent 分析日誌，識別問題，提出修復方案。你審查差異，批准，然後部署。

晚上：你檢查自動化收件匣。夜間安全稽核 agent 標記了一個依賴漏洞並創建了一個修復 PR。你審查它，合併它，並歸檔通知。

你今天的實際編碼：也許 30 分鐘的實作編輯，當你需要提供 agent 遺漏的特定實作細節時。其餘的是編排——定義工作、審查輸出、協調跨 repository 的變更。

當前的工具版圖

編排領域仍處於早期階段，但明確的領導者正在出現：

OpenAI Codex

於 2025 年 5 月 16 日推出，可透過 ChatGPT Plus/Pro/Enterprise 計劃使用。這是 OpenAI 對開發環境應該是什麼樣子的賭注：

  • 桌面應用程式（macOS，Windows/Linux 開發中）用於視覺化執行緒管理
  • IDE 擴充功能用於 VS Code 整合
  • CLI 用於自動化和腳本（也可作為獨立開源工具使用）
  • 內建 worktrees 和 git 工具
  • 自動化用於重複性任務
  • 語音輸入（Ctrl+M）用於自然任務描述

宣傳語：你不再需要程式碼編輯器，你需要一個指揮中心。

關鍵區別：OpenAI 提供 Codex（完整的雲端編排平台）和 Codex CLI（輕量級終端工具），服務不同的使用案例。

Cursor

從 AI 增強的 VS Code 分支開始，演變成完整平台：

  • Composer 介面用於 agent 驅動的開發
  • 自主性滑桿：Tab 自動完成（低）→ Cmd+K 編輯（中）→ Agent 模式（高）
  • 整合：Slack bot、GitHub PR 審查（Bugbot）、CLI
  • 被 Stripe、OpenAI、Linear、Datadog 使用

宣傳語：IDE 能力與內建的 agent 編排。

CLI 優先工具（Aider、Claude Code）

對於喜歡終端工作流程的開發者仍然相關：

  • 輕量級，快速啟動
  • 直接 git 整合
  • 無 GUI 開銷
  • 最適合專注的單功能工作

宣傳語：不是每個人都需要編排。有時你只想快速修復一個 bug。

「中間層」工具

在重量級 IDE 和純 CLI 之間，一個新的工具類別正在出現：

OpenCode：一個混合 TUI（文字使用者介面）和原生應用程式，因其管理多個 AI 會話的輕量級方法而越來越受歡迎，沒有完整 IDE 分支的開銷。它在 CLI 效率和視覺化會話管理之間架起橋樑。

其他：Google 傳聞中的「Antigravity」專案據說也針對這個領域，儘管具體細節仍然稀少。這仍然是最前沿——預計在接下來的 12-18 個月內快速演變。

這對開發者意味著什麼

技能轉移

變得更重要的技能：

  • 規格撰寫：清晰、明確的需求定義
  • 上下文切換：在並行工作流之間快速移動
  • 高層次程式碼審查：架構健全性優於語法細節
  • Agent 提示：知道如何有效地向 AI 傳達意圖
  • 系統思維：理解跨 repository 的變更如何互動

變得不那麼重要的技能（不是過時，只是不那麼核心）：

  • 語法記憶：Agent 處理細節
  • 樣板編碼：讓 agent 生成它
  • 文件閱讀：詢問 agent 解釋
  • 低層次除錯：Agent 可以更快地追蹤程式碼庫

職涯影響

這不是關於 AI 取代開發者。這是關於 AI 改變「開發者」的意義。

在這個新世界中茁壯成長的開發者是那些：

  • 以結果而非實作方式思考
  • 可以同時協調多個工作流
  • 對系統有足夠深入的理解以發現架構問題
  • 撰寫清晰的規格和約束

初級開發者實際上可能受益最多。「我理解需要發生什麼」和「我可以實作它」之間的差距正在迅速縮小。如果你能清楚地描述解決方案，agent 可以處理大部分實作。

資深開發者正在從「實作建造者」轉變為「架構審查者」。你仍然需要深厚的技術知識——也許比以往任何時候都更需要——但你在更高的抽象層次上應用它。

經濟學轉變

粗略計算：

  • 傳統開發：開發者（$150K/年）生產 10-20 個 PR/月 = ~$750/PR
  • AI 輔助開發：開發者 + AI 工具（$150K + $1-5K/年）生產 30-60 個 PR/月 = ~$300/PR

小團隊可以以以前需要更大團隊的規模構建。獨立開發者可以交付看起來像來自 10 人新創公司的產品。

這改變了經濟上可行的東西。微型 SaaS 業務、利基工具、個人化軟體——當你編排 agent 而不是手動編寫每一行時，原本太昂貴而無法手動構建的東西變得可行。

下一步：多 Agent 專業化

下一個前沿已經在研究實驗室和早期產品中出現：專業化 agent 團隊。

想像編排以下 agent，而不是通用的「編碼 agent」：

  • Frontend Agent：React、無障礙、響應式設計專家
  • Backend Agent：API 設計、資料庫優化、快取策略
  • Security Agent：漏洞掃描、安全編碼模式、滲透測試
  • Testing Agent：測試生成、覆蓋率分析、不穩定測試偵測
  • DevOps Agent：CI/CD、基礎設施即程式碼、效能監控
  • Documentation Agent：API 文件、教學、架構圖

你的角色：協調這些專家。定義專案目標，讓 agent 在他們的領域中找出實作細節，審查他們工作的交集處。

技術挑戰令人著迷：

  • Agent 溝通：Agent 如何共享上下文和協調變更？
  • 衝突解決：如果安全 agent 和效能 agent 提出矛盾的方法怎麼辦？
  • 責任邊界：哪個 agent「擁有」程式碼庫的哪些部分？

我們還沒有好的答案。但現在構建這些系統的公司在 2-3 年內將擁有顯著優勢。

心智模型轉變

這個轉變中最困難的部分不是技術性的——是心理性的。

對我們大多數人來說，「成為開發者」意味著編寫程式碼。我們的身分與將想法轉化為語法、除錯邊緣案例、為清晰性重構的工藝相關聯。將這些交給 AI 可能感覺像是放棄了使我們成為開發者的東西。

但退一步問：我們實際上在嘗試做什麼？

我們在嘗試構建解決問題的軟體。編寫程式碼是達成目的的手段，而不是目的本身。如果我們可以透過編排 agent 更快地構建更好的軟體，為什麼不呢？

在這個轉變中掙扎的開發者是那些執著於手段的人。茁壯成長的開發者是那些專注於目的的人。

實用建議：現在開始實驗

如果你仍處於「AI 作為自動完成」的心態，這裡是如何開始邁向編排的方法：

  1. 嘗試 CLI agent（Aider、Claude Code）：習慣委派整個功能而不是逐行接受建議。

  2. 學習 worktrees：練習在不同目錄中管理並行分支。這是多 agent 工作流程的基礎。

  3. 實驗編排平台：嘗試 Codex、Cursor 或 OpenCode。為單一專案創建多個執行緒，看看切換上下文而不是專注於一個檔案的感覺如何。

  4. 練習規格撰寫：不要想「我如何實作這個」，而要想「我如何清楚地描述這個，以便其他人可以實作它。」Agent 就是那個「其他人」。

  5. 在更高抽象層次審查：審查 agent 輸出時，專注於架構、邊緣案例和效能影響。假設語法是正確的，除非證明相反。

工具仍處於早期階段。Codex 的桌面應用程式僅限 macOS（目前）。Cursor 對休閒使用者來說很昂貴。OpenCode 仍在獲得採用。CLI agent 仍有粗糙的邊緣。

但方向是明確的。現在適應的開發者在這些工具成熟時將擁有顯著優勢。

我們正在建構的未來

五年後，我預測：

  • 「打開你的 IDE」將像「啟動你的文字編輯器」 在今天聽起來一樣古雅。你將打開你的編排平台。

  • 手動編寫程式碼將保留給 真正新穎的演算法、效能關鍵路徑，以及當你想深入理解某些東西時。大多數程式碼將被指定，而不是編寫。

  • 初級開發者入職將專注於 規格撰寫、agent 提示、系統設計和高層次審查——而不是語法和標準程式庫 API。

  • 「你有多少開發者？」將被 「你每週編排多少 agent 小時？」取代，作為生產力指標。

  • 最好的開發者將是那些 能夠在頭腦中保持最複雜的系統模型，同時協調最多 agent 的人。

這不是科幻小說。這些工具今天就存在。缺少的是編排心態的廣泛採用。

從編碼到編排的轉變正在進行中。一些開發者會抵制，堅持手工編寫程式碼的工藝。其他人會擁抱它，發現他們可以構建以前從未能夠構建的東西。

茁壯成長的開發者不一定是那些編寫最好程式碼的人。他們將是那些能夠編排 agent 來構建最好系統的人。

問題不在於這個未來是否會到來。而在於當它到來時你是否準備好。