# 軟體工程的未來 / The Future of Software Engineering ## 關於本文 本文為 Thoughtworks 報告「軟體工程的未來」的中譯潤飾版。原文連結： --- ## 執行摘要 各大科技公司的資深軟體工程從業者，齊聚一場為期數天的 retreat（下稱研討會），共同思考 AI 重塑軟體開發時最迫切的問題。會議涵蓋超過二十場 breakout session，但真正關鍵的洞察並非出自任何一場。它們出現在議題與議題的交集處：相同的擔憂，由不同的人從不同的角度切入，反覆浮現。 > 「每間會議室都在問同一個問題：當 AI 接手寫 code，engineering 還剩下什麼？沒人能給出一致的答案。但所有人都同意：這個問題已經很急。」 ## 主題一覽 | 主題 | 時間範圍 | 核心洞察 | | --- | --- | --- | | **嚴謹性 (Rigor) 何去何從？** | 現在 | 當 AI 寫 code，engineering 品質不會消失。它會遷移到 spec、test、constraint 與 risk management 之上。 | | **從 code review 到 risk tiering** | 現在 | Code review 正在被拆解。它過去同時承擔的四項功能（mentorship、consistency、correctness、trust），如今必須各自找到新歸屬。 | | **生產力／體驗悖論** | 現在 | 開發者生產力與開發者體驗正在脫鉤。組織必須抉擇要先最佳化哪一邊。 | | **安全被當作事後考量** | 現在 | Agent security 嚴重不足；光是 email 存取，就足以完成完整的帳戶接管。 | | **中迴圈 (The middle loop)** | 現在–1 年 | 內迴圈 coding 與外迴圈 delivery 之間，正浮現一類新的監督工程 (supervisory engineering) 工作。它還沒有名字。 | | **認知負擔 (Cognitive debt)** | 現在–1 年 | 技術債正演化為認知負擔：系統複雜度與人類理解力之間的鴻溝。 | | **智能體拓樸 (Agent topologies)** | 1–3 年 | 康威定律對 agent 同樣成立。企業架構必須開始考慮 agent 的流動、專業化與漂移。 | | **知識圖譜 (Knowledge graph) 與語意層 (semantic layer)** | 1–3 年 | 沉寂數十年的技術突然重新關鍵，成為 domain-aware agent 的基礎層。 | | **角色的未來** | 1–3 年 | PM、developer、designer 的角色界線正在融合。Staff engineer 面臨全新期望，而 junior 比過去更有價值。 | | **自我修復系統 (Self-healing system)** | 2–5 年 | 從人類主導的 incident response 走向 agent 輔助修復，必須先解決「latent knowledge」問題。 | *以下為各主題的詳細發現。* --- ## 1. 嚴謹性 (Rigor) 何去何從？ *這是研討會最核心的單一問題，幾乎在每個議程裡都會浮現。* 當 AI 接手 code production，撰寫與 review code 中的工程紀律 (engineering discipline) 不會消失。它只是換了地方。研討會在這個議題上著墨最深，從 code review、testing、language design、self-healing system、organizational design 等多個角度切入。 嚴謹性遷移的五個方向如下。 ### 上游到 specification review 多位從業者表示，他們已將 review 重心從 code 移到 code 之前的 plan。其中一位形容自己的工作是「pre-reviewing plan 和 post-reviewing engineering」，而非審 code 本身。邏輯很直接：當 AI 從 spec 生成 code，spec 就成了捕捉錯誤的最高槓桿工件 (artifact)。**糟糕的 spec 會大規模產出糟糕的 code。** 實驗 SDD (spec-driven development) 的組織回報，**spec 本身需要新的格式**。傳統 user story 太模糊。部分團隊轉向結構化的描述方式，例如 EARS（Easy Approach to Requirements Syntax）、state machine 與 decision table。這些並非新技術；但因為它們能給 AI agent 足夠的精確度寫出正確實作，如今重新搬上檯面。 > [!note] 譯註 > SDD 並非 Agentic Engineering 唯一的路徑。對於需要極快速迭代的產品（例如目前最強的 Agent 產品 Claude Code），spec 反而會成為絆腳石；這類產品真正需要的是足夠乾淨的程式碼，讓持續新增與修改功能不會被阻礙。 > > 不過這類產品終究是少數。對多數較複雜的產品或團隊來說，spec 在現階段仍然必要，它會以一種約束與記憶的形式，成為下一次系統修改的依據。 ### 進入 test suite 作為一等工件 (First-class artifact) 研討會中最具傳播力的洞察：TDD (test-driven development) 能讓 AI coding agent 寫出明顯更好的結果。它的機制很具體。TDD 擋下了一種特定的 failure mode——agent 為錯誤行為寫出對應的 test。當 test 早於 code 存在，agent 就無法靠著「為自己的爛實作量身訂做一個能跑過的 test」蒙混過關。 這把 TDD 重新定義為一種 prompt engineering。test 成為非確定性生成 (non-deterministic generation) 的確定性驗證 (deterministic validation)。**多位從業者表示，他們已把 review 重心完全移到 test suite，把生成的 code 當成可拋棄品。只要 test 寫得對、code 通過驗證，code 長什麼樣都可以接受。** > **從業者洞察** > > 「我用 TDD 配合 agent coding，得到的成果比其他做法都好。它能擋下一種特定的心理錯誤：agent 為錯誤行為寫出對應的 test。」 ### 進入型別系統 (type system) 與約束 (constraint) 研討會中浮現一股強烈興趣：用程式語言本身的特性約束 AI 生成的 code。比起在生成後逐行審核，從業者更想探索如何讓不正確的程式碼從根本上寫不出來。 關鍵之一是把規格 (specification) 與約束 (constraint) 分開。Spec 描述什麼東西「該改變」；constraint 定義可以變動的有界上下文，包含什麼東西「不准被觸碰」。這類約束限制了爆炸半徑 (blast radius)，讓 agent 在領域邊界內也能安全工作。某條約束必須被打破時，那就標誌出一個新的系統邊界，並觸發重構。 ### 進入 risk mapping 並非所有 code 都承載相同的風險。研討會討論了依業務爆炸半徑 (blast radius) 將 code 分層，把內部工具、對外服務、safety-critical system 區分對待。這種 risk mapping 決定了哪些地方需要人工審核，哪些地方自動化驗證就夠。 一位從業者把這件事重新框架為新的核心工程紀律：與其問「這段 code 有人 review 過嗎？」，組織該問的是「這段 code 出錯，blast radius 多大？我們的驗證強度與這個風險成比例嗎？」這代表軟體工程從 craft model（每一行都人工 review）走向 risk management model（驗證投入與曝險程度匹配）。 ### 進入 continuous comprehension 當 code 變化的速度快過人類能 review 的速度，靠 code review 建立 mental model 的傳統途徑就會崩潰。研討會討論了幾個替代做法：每週 architecture retrospective、ensemble programming（多名 engineer 同時在同一段 code 上工作），以及能依需求生成系統概覽的 AI 輔助 code comprehension 工具。 底層的擔憂是真實的。一位從業者指出，code review 在歷史上同時是學習機制與品質關卡。Mentorship、shared understanding、codebase familiarity 都從 review 中自然發生。失去這條管道又沒有替代方案，理解力的缺口會隨時間累積。 > 「Pair programming 同時解決了這些問題。如果理解系統真的重要，那就持續去做。不要只在『有 code review 的小階段』才做。要持續理解這段 code 在做什麼。」 --- ## 2. The middle loop：一類新的工作 *這是研討會中最強的 first-mover 概念。業界還沒有人替它命名。* 軟體開發向來被描述為兩個迴圈：內迴圈是開發者個人撰寫、測試、debug code 的循環，外迴圈是更廣的 CI/CD、DevOps（deployment 與 operations）的交付循環。研討會提出第三個迴圈，介於兩者之間：監督工程 (supervisory engineering) 的中迴圈。 中迴圈的主要工作是引導、評估、修正 AI agent 的輸出。它需要的能力組合，與「寫 code」截然不同：把問題拆成 agent 大小的工作包、校準對 agent output 的信任、識別 agent 何時產出表面合理但其實不對的結果，以及在多個平行的 agent 工作流之間維持架構連貫性 (architectural coherence)。 在這項新工作中表現出色的人，往往有幾個共同點： - 思考時習慣以 delegation 與 orchestration 為起點，不直接動手實作。 - 擁有強大的、以系統架構為優先的心智模型 (system architecture mental model)。 - 不必逐行閱讀，也能迅速判斷 output 的品質。 這些通常是資深工程師才有的能力，但極少有組織在職涯路徑中明確培養或認可。 > **Career 影響** > > 中迴圈替那些因熱愛 programming 而入行的開發者，帶來真正的身分認同危機。許多人原本的工作就是把消化好的 ticket 翻譯成可執行的 code（譯注：只負責接任務、執行任務的個體）。這類工作正在消失。新的工作要求不同的能力，也仰賴不同的專業滿足感來源。沒有幫員工度過這層轉換的組織，會因為挫折感而流失最有經驗的人才。 研討會把這件事類比於電腦圖學 (computer graphics) 的歷史。1992 年，工程師親手寫多邊形繪圖演算法。兩年後，這項工作下沉到硬體，工作重心轉向 animation 與 lighting；今天則是客製 physics 與 game world。每一次抽象層 (abstraction layer) 上升，堅持「我被雇來畫多邊形」的工程師都會被甩在後頭。同樣的動態，現在正發生在 code production 上。 產品管理面也同樣不穩定。如果開發者開始更多去想「要做什麼、為什麼做」，他們其實在承擔過去屬於 PM (product manager) 的工作。一家大型科技公司正在認真評估 PM 這個角色是否需要改名。另一家則在訓練所有 product manager 在 Markdown 與 developer 工具裡工作。這種角色趨同是真實的，但最後會落腳在哪裡，沒人知道。 --- ## 3. 智能體拓樸 (Agent topologies) 與企業架構 (enterprise architecture) *康威定律 (Conway's Law) 沒有退休。它變得更複雜。* 研討會引入「agent topologies」這個概念，作為團隊拓樸框架 (Team Topologies framework) 的延伸。前提是：如果組織所設計的系統會反映其溝通結構，那當 agent 成為這些結構中的一等公民時，會發生什麼？ 跟人類不同，agent 可以即時複製、部署到多個團隊，沒有 onboarding 的摩擦成本。一個專責的 database agent 可以同時存在於每個團隊裡，帶來一致的專業知識，又不會像單一人類 database 專家那樣形成瓶頸。聽起來像純粹的好事，但研討會點出了幾個複雜化因素。 ### 速度不匹配 Agent 消化 backlog 的速度太快，會撞上組織的緩慢依賴。一位參與者描述他的經驗：你給某個團隊 AI 工具，他們幾天內就把 backlog 清空，接著一頭撞上跨團隊依賴、架構審核、人類速度的決策制定。**結果並沒有更快交付**；交付速度沒變，挫折感反而更多，因為瓶頸已經從工程能力轉移到了其他每一個環節。 ### Agent drift（智能體漂移） 從環境上下文中學習的 agent，會隨時間發散（譯注：分歧化；累積了不同上下文後，agent 的偏好也會不同）。即使從相同配置出發，在 e-commerce backend 上工作的 database agent，與在 ERP system 上工作的同型 agent，會累積出不同的模式與偏好。這對應到人類團隊「團隊特定 norm」的問題，但時間軸被加速了。研討會辯論的是：這種漂移該「管理」（類似人類團隊內的標準化努力）還是「接納」（讓團隊在地最佳化）？ ### 決策疲勞 (Decision fatigue) 成為新瓶頸 當 agent 產出工作的速度比領導者能審核與批准的速度更快，限制就從「生產容量」轉到「決策容量」。**過去做為協調節點的中階主管，如今變成了批准瓶頸**。多位從業者表示這已經在他們的組織中發生：agent 生成 job specification、code fix、feature implementation 的速度，比任何人能 say yes 的速度都快。 研討會於是提出一個尖銳的問題：**如果人類對系統的理解力有上限而 agent 沒有，我們真的還需要那麼多中階主管嗎？** 與會者沒有共識，但這個問題本身就標示出前方一道組織挑戰。 > 「我們把軟體交付流程 (software delivery process) 為人類最佳化。如今參與者不只是人類，我們必須重新追問：所謂的『組織』到底是什麼意思。」 --- ## 4. 自我修復與自我演進系統 (Self-healing 與 self-improving) *野心是真實的，但前提條件遠未到位。* 研討會探討的是：軟體系統能否超越人類主導的事件回應 (incident response)，走向 agent 輔助的自我修復？與會者區分了兩個層次的野心：self-healing（把系統還原到已知良好狀態）與 self-improving（主動演化系統的非功能品質，例如效能與可靠性）。 ### 尚未到位的前提條件 自我修復需要幾個多數組織還缺乏的基礎： - **完整紀錄每一次變更的帳本**，讓 agent 看得懂發生了什麼。 - **一套作業系統，提供 agent 的 identity control 與 permission boundary**。 - 強大的通用緩解能力（rollback、feature flag），不動 code 也能生效。 - **以 agent 可評估的形式表達「健康」(healthy) 是什麼意思**。 研討會提出一個直白的論點：code 變更應該是 incident remediation 的最後手段。通往自我修復的路徑，在於更好的 rollback、更好的 feature flag、更好的可觀測性 (observability)，而非靠 agent 重寫生產環境的 code。 ### 潛知識 (Latent knowledge) 問題 資深工程師處理事件，靠的是數十年累積的模式匹配 (pattern-matching) 經驗。他們記得某個特定 error code 其實是底層 infrastructure 問題的症狀；他們知道某個 service 的 CPU 飆高，第一件事該檢查的是 database connection pool。這類知識幾乎沒人寫下來，它存在於人腦中，靠經驗在當下被喚起。 要替 agent 重現這些知識，組織必須建構研討會所稱的「agent subconscious」：一張知識圖譜 (knowledge graph)，由多年事後分析 (post-mortem) 與事件資料 (incident data) 提煉而來，賦予 agent 解讀即時訊號所需的歷史脈絡。**部分組織已經透過自動化的事後分析報告累積這份資產**，但加上細微差異與脈絡的人類步驟仍然不可或缺。 > **事件指揮官 (Incident commander) 問題** > > 人類會挑戰假設、反駁聽起來舒服的假說，並維持態勢感知 (situational awareness)。LLM 則傾向正向強化與順從。要打造一個有效的 agent 事件指揮官，必須先解決這種行為上的不匹配。研討會提出的一個方向：訓練專門用來挑戰主流假說的「angry agent」。 ### 智能體協調風險 (Agent coordination risk) 多個 agent 同時嘗試修復同一個問題，可能形成 feedback loop：一個 agent 的修補觸發另一個 agent 的修正，循環不斷升級。研討會舉了一個真實案例：某個能存取 linter 的 agent，被要求遵守 500 行的檔案大小限制；它的解法是把單行寫得更長，技術上滿足規則，卻違反了規則背後的精神。當多個 agent 對 trade-off 排出不同的優先順序，系統可能震盪而非收斂。 --- ## 5. 人的一面：角色、技能與體驗 *AI 並沒有取代人，它在重新編排人做什麼，以及對所做之事的感受。* ### 生產力／體驗悖論 開發者體驗 (Developer experience，DX) 過去定義為三個維度：flow state、feedback loop、cognitive load。生產力與 DX 數十年來一直緊密耦合；研討會則探討了它們正在脫鉤的證據。即便 developer 回報滿意度較低、cognitive load 變高、flow 感變少，組織仍可以透過 AI 工具獲得生產力提升。 > [!note] 譯註 > 長期身處惡劣的開發環境，會讓部分工程師或管理者轉向「DX 無用論」。但這裡所謂的緊密耦合，譯者認為想表達的是：糟糕的 DX 不一定直接表現為生產力低落，影響會反映在其他面向。把交付快速的低品質產出當成高生產力是有問題的；高品質產出與 DX 高度相關，因為 DX 低落代表工程師必須花大量時間在與開發無關的事情上。 這造成了一個真實的兩難。如果組織不投資開發者也能拿到更多產出，那麼投資的商業理由就會弱化，除非「開發者體驗」這個概念進化到能涵蓋 agent-supervised 工作的新現實。一位從業者提出一個犀利的重命名：別再叫它「開發者體驗」，改叫「智能體體驗」。**組織會更願意花錢創造讓 agent 表現良好的條件**，而那些條件與「讓人類表現良好」的條件，幾乎完全重疊。 ### Staff engineer 承受壓力 Staff engineer 比過去更重要，也比過去承受更大的壓力。一份覆蓋 500 家公司的研究機構資料顯示，staff engineer 用 AI 工具的頻率低於 junior engineer，但他們每次使用節省的時間更多。較廣的脈絡與較深的系統架構理解，讓他們成為更有效的 agent 監督者。 張力在於：staff engineer 被要求做的事，與他們應該做的事不一致。**許多人花了不成比例的時間在人類協調，而非技術監督**。研討會主張一個刻意的轉變：**staff engineer 應該成為摩擦殺手 (friction killer)，找出並移除拖慢人類與 agent 工作的障礙**。他們對「骨頭埋在哪裡」的深度理解，讓他們特別適合這個角色。但許多人多年來提出改進建議卻被告知「沒有預算」之後，已經陷入 learned helplessness。 ### Junior developer 反而更有價值 研討會挑戰了「AI 會消除 junior developer 需求」這個敘事。Junior 的投資報酬率比過去更高。AI 工具讓他們更快走過那段尷尬的 net-negative 初期。他們是組織未來生產力的 call option。而且他們比 senior engineer 更擅長使用 AI 工具，因為他們從未養成那些拖慢採用速度的習慣與假設。 真正令人擔憂的，是過去十年招聘潮中成長起來的中階工程師。他們可能還沒長出在新環境裡蓬勃發展所需的根基。這群人在業界佔了相當大的比例，重新培訓他們是真正困難的事。研討會討論了 apprenticeship model、rotation program、lifelong learning 結構是否能填補這道差距，但顯然沒有任何組織已經破解了這道題目。 > [!note] 譯註 > 此處譯者持不同意見：並非「任何」junior 都更有價值。比起 senior，junior 真正獨特的優勢只有一點：天生不受傳統做法約束，有機會成為轉變的種子。但若 junior 選擇放棄批判性思考、把 agent 當成應付工作的工具（例如把任何問題都單純轉傳給 AI、再原封不動把回應傳回來的新人），他們與停滯不前的 senior 相比並沒有更好。 ### Product management 的未來 研討會中沒有人能定義 product manager 在 AI 驅動的世界裡會做什麼。一些組織把 PM 推向更貼近技術的工具，訓練他們在 Markdown 與 developer 環境中工作。其他組織則看到角色進一步分化：PM 成為策略統籌者 (orchestrator)，開發者承擔更多戰術產品決策。 **比較確定的是，AI 正在暴露 PM 與 developer 之間既有的功能失調**。知識碎片化、學科之間的文化鴻溝、模糊的角色邊界，這些問題在 AI 之前就存在了，AI 只是讓忽視它們的代價變得更高。研討會強調工具作為「boundary object」的角色：讓不同角色以自己的方式工作，同時維持共享的可見性。 > [!note] 譯註 > 個人感覺 PM 與 RD 會各自往 TPM 方向靠攏，差別只在誰靠攏的程度更高。RD 的優勢在技術背景，PM 則應該善用 AI 補強自己缺乏的技術知識。 > > 至於所謂的互相取代，譯者認為關鍵在於該角色的人是否能透過 AI 進一步強化自己的跨領域能力。 --- ## 6. 技術基礎：語言、語意與作業系統 *Agent 時代的 infrastructure 還不存在，目前看到的只是正在組裝的零件。* ### 為 agent 設計的程式語言 每一種現存的程式語言，主要都是以人類使用者為對象設計的。動態型別存在，是為了減輕人類工程師的認知負荷；強型別存在，是為了攔截人類的錯誤。研討會提出一個問題：如果一種語言是為「agent 生成 code」而設計，它會長什麼樣？而它是否同時能更好地服務人類？ 與會者在一個原則上趨於一致：**對 AI 好的東西，對人類也好**。讓不正確的 code 從根本上無法表達的語言（透過 strong type、restricted computation model、formal constraint），既能幫 agent 寫出正確的輸出，也能幫人類驗證它。反過來，重視表達力勝於安全性的語言，會同時讓 agent 生成與人類審核都更困難。 更激進的可能性是：我們所知的「原始碼」可能變成一種瞬時工件，按需生成、從不儲存。研討會在這點上意見分歧。一部分人認為原始碼會在十年內消失；另一部分人主張，定性驗證需要一個穩定的工件可供測試，那個工件無論叫什麼名字，本質上仍是原始碼。 > [!note] 譯註 > 譯者目前也是這樣想的：在足夠完善的規範與規格之下，程式碼只是一份可以反覆重新生成的「文件」。 ### 語意層 (Semantic layer) 與知識圖譜 (knowledge graph) 數十年來進不了主流的技術，突然重新關鍵起來。語意層 (semantic layer)、知識圖譜 (knowledge graph)、領域本體 (domain ontology) 重新被發掘，作為理解業務 domain 的 AI agent 的基礎層。研討會中有些從業者正在大規模建構這類系統，**他們回報：一家大型電信公司的整套 domain ontology，可以用大約 286 個概念捕捉**。這個數字讓這項工作從「不切實際的宏大」變成「可實現」。 AI 在 legacy system 現代化中的價值，在於它能像考古學家一樣，自動從舊程式碼中挖出業務基因（DDD 元素），並翻譯成結構化的「語意藍圖」。這釋放了人類專家原本耗時的體力勞動，讓他們轉做高價值的「監督與校準」工作；原本漫長的轉型前置作業因此縮短數倍，並確保 AI agent 能在安全的語意邊界內自信地重構系統。 ### 智能作業系統 (Agentic operating system) 研討會探討了 agent 的作業系統需要哪些東西： > [!note] 譯註 > 智能作業系統並不只是在現有作業系統上加一個 LLM。 - 智能體身份 (Agent identity) 與權限管理 (permission management)。 - 記憶 (memory) 與上下文視窗管理 (context-window management)。 - 一份工作帳本 (work ledger)，記錄未來、當前與過去的工作，並標註所需技能 (required skill)、驗收標準 (acceptance criteria)、服務水準目標 (SLO) 與成本約束 (cost constraint) 等屬性。 - 透過 agent capability 與合規要求 (compliance requirement) 圖譜實現的治理路徑 (governance path)。 一個核心洞察是：agent 不只是它的 persona、goal 或當前 context；它還包括它執行過的工作歷史。Model 在 agent 內可以替換（你可以拿一個 LLM 換掉另一個），但更換 model 會根本改變 agent 的行為，這件事必須被追蹤。Work ledger 是這個新作業系統的核心原語，類似金融區塊鏈：可搜尋、可審計，並讓 agent 發現工作、競標工作。 --- ## 7. Security、governance 與 agile 的未來 ### 「安全性」危險地落在後頭 研討會關切地注意到，security session 的出席率偏低，反映出更廣泛的產業模式：業界把安全當成事後才解決的東西，等到技術運作正常且可靠之後才處理。對 agent 而言，這個排序很危險。 最生動的例子：給 agent email 存取權限，就足以完成 password reset 與帳戶接管。Development tool 的完整機器存取，意味著 agent 決定要做的任何事都擁有完整的機器存取權。研討會的建議很直接：Platform engineering 應該透過設計來驅動安全預設值，讓「安全行為簡單、不安全行為困難」。組織不該依賴個別 developer 在配置 agent 存取時做出有安全意識的判斷。 三個優先方向：把 security by design 當成不可妥協的基準線；以跨產業聯盟制定可互通的 agent security 標準；建立速度與複雜度都足以匹配 AI 攻擊的 AI 防禦機制。 ### Agile 沒有死，它在演化 研討會強力反駁了「agile is dead」的說法。實際發生的事情更微妙。一些團隊把衝刺節奏壓縮到一週，並用 AI 自動化衝刺結束儀式 (end-of-sprint ceremony)，例如 demo、reporting、status summary。其他團隊則重新發現 XP 實踐（pair programming、ensemble development、continuous integration），因為這些實踐能提供 agent-assisted development 所需的緊密回饋迴圈與共享理解。 **對 agile 真正的威脅是治理 (governance)**。**採用 AI 工具、節奏加快的團隊，仍然會撞上同一套審批流程、合規閘門、組織依賴。如果在改革開發實踐的同時不一併改革治理，更快的團隊只是更快撞牆。研討會強調：在重新思考團隊實踐時，要儘早把 internal audit 與 governance 拉進來，而不是把它們當成事後要繞過的障礙。** 軟體穩定性也隨 batch size 增加而下降。AI 工具讓大型 changeset 變得容易產出，這把一些團隊推回類似瀑布的模式：以大型、不頻繁的發布取代小型、頻繁的 release。這直接逆轉了十年來 DORA 研究的結論：較小的 batch size 與較高的穩定性正相關。研討會把這標示為一種主動退化，需要產業層級的注意。 --- ## 8. Agent swarm：超越循序思維 研討會撥出專門時段討論智能體集群 (agent swarming)，並浮現了一些挑戰傳統假設的洞察：AI-assisted 工作該怎麼組織。 集群的第一個障礙是心理層面，不是技術層面。受過 sequential decomposition 訓練的 engineer，難以把平行的 agent 工作概念化。這套舊有的心智模型會主動阻礙學習。在集群這件事上有突破的從業者形容，那種經驗跟他們過去任何軟體開發經歷都根本不同。一個簡單的做法：直接要求 agent 明確平行化工作，然後觀察結果。這比任何理論框架教得都多。 對企業使用情境而言，研討會找到一個重要的模式：個別 agent 的完美準確度，沒有「集體朝目標收斂」來得重要。一群個別不完美的 agent，只要透過系統架構引導它們收斂，就能產出有價值的結果。這是一個借自分散式系統與生物集群智慧的設計原則，被應用到 AI agent 統籌上。 研討會也注意到：多數企業的智能體統籌看起來根本不像集群。更常見的模式是「patrol worker on loop」——agent 在持續迴圈中執行良好定義的 ETL transform、data quality check、business process monitor。換句話說，data reliability 與 cleanliness 這類不起眼的工作，持續在背景運行。擁有強大、設計良好 API 的組織，在 swarming 與 patrol-style agent deployment 兩條路上都明顯處於更有利的位置。 > **Model 限制** > > 部分 frontier model 有結構性弱點，使它們不適合 swarm-style scenario。這正在影響 evaluation 的設計方式；隨著我們更深入理解這些限制，預期 swarm-oriented architecture 也會持續改善。為 agent deployment 選 model 的組織，應該專門測試 multi-agent coordination，而不只是 single-agent capability。 --- ## 9. Open question *研討會浮現的問題比答案多。以下是讓房間裡的人睡不著的問題。* ### 關於工作與身分認同 我們如何幫助熱愛寫 code 的 engineer，在監督工程 (supervisory engineering) 工作中找到意義與滿足感？什麼樣的職涯路徑通往中迴圈？如果 PM 與開發者的角色正在融合，融合後的角色叫什麼名字？由誰來持有它？ ### 關於組織設計 如果 agent 讓中階管理的瓶頸更為可見，組織的回應會是「更少的管理者」、「技能不同的管理者」，還是「一種根本不同的協調模式」？當 agent 可以跨越團隊邊界但治理結構不行，企業架構該如何重新設計？ ### 關於信任與驗證 要滿足什麼條件，組織才能完全停止 review AI 生成的 code？是否存在這樣一個世界：test suite 與約束已經提供足夠驗證，不再需要人類檢查？面對一個本質上非確定性的系統（相同輸入重新執行會得到不同輸出），我們如何建立信任？ ### 關於知識與理解 如果 code 變化的速度快過人類能理解的速度，我們是否需要一種新的模型來維繫制度知識 (institutional knowledge)？知識圖譜與語意層真的能取代多年在 codebase 中工作累積出的人類直覺嗎？多數組織尚未建構的「agent subconscious」系統，正確的投資水準應該是多少？ ### 關於速度與穩定性 我們是否正處於一場退化中：AI 帶來的生產力提升，正被較大 batch size 帶來的穩定性損失抵銷？開發是否需要刻意放慢，因為決策的數量已經壓垮人類評估它們的能力？認知負擔 (cognitive debt) 在累積時的真實成本，我們該如何衡量？ --- ## 接下來會發生什麼 研討會中反覆出現一個共同的模式：為人類主導的軟體開發所打造的那一套實踐、工具、組織架構，正在 AI 協作的浪潮下以可預期的方式逐一鬆動。新的替代方案已經開始萌芽，但離成熟還有很長一段距離。 已經準備好進入更廣泛產業對話的概念，包括：supervisory engineering（監督工程）、middle loop（中迴圈）、把 risk tiering（風險分層）視為新的核心工程紀律、把 TDD 視為最強的 prompt engineering 形式，以及把 agent experience（智能體體驗）作為「開發者體驗投資」的新框架。 尚未被回答的問題同樣重要。如何幫助人們度過職涯中的身分認同轉換；如何治理一個 agent 比人類決策更快的組織；如何在一個本質上非確定性的系統中建立信任。這些並非有現成技術解的技術問題，它們是需要坦誠對話與合作才能推進的人的問題。我們將在接下來的數月持續為此貢獻心力。 > 「這場研討會沒有產出一張路線圖。它產出了一份共識：整張產業地圖正在被重畫，而最適合畫它的，是那些願意承認自己還不知道很多事的人。」