在現代軟體開發的開發浪潮中，許多團隊正陷入一種所謂的 Vibe Coding（氛圍編碼）狀態，即過度依賴 AI 生成程式碼，追求快速產出而忽略深層邏輯。然而，對於許多企業而言，他們面對的並非乾淨的全新專案（Greenfield），而是充滿歷史包袱、累積數十年邏輯的舊有系統（Brownfield Codebases）。在這種複雜的環境下，單純依賴 AI 往往無法達到預期的品質，反而可能增加維護成本。
根據 InfoQ 的訪談，來自挪威 SpareBank 1 Utvikling 的資深開發者 Asgaut Mjølne Söderbom 與 Ola Hast 分享了他們在處理高流量金融 API 系統時的實踐經驗。他們發現，在面對極其複雜且對穩定性要求極高的系統時，人類的協作能力與對領域知識的掌握，遠比 AI 的生成速度更為關鍵。
背景：舊有系統的挑戰與 AI 的侷限
所謂的 Brownfield 專案，是指在既有的程式碼基礎上進行開發或擴展的系統。這類系統通常具有深厚的歷史背景，其中包含許多無法被簡單記錄在文件中的隱性知識（Tacit Knowledge），例如特定的業務規則、過去為了修補漏洞而留下的特殊處理，以及與數十年之久的後端系統對接時的古怪行為。
當團隊嘗試將 AI（如 Claude）全面引入開發流程時，會發現一個核心問題：AI 缺乏這種深層的上下文（Context）。AI 雖然能快速生成符合語法且看起來正確的程式碼，但它無法理解系統內部的微妙關聯。在金融等關鍵領域，一旦 AI 生成的程式碼忽略了某個隱藏的業務邏輯，可能會導致嚴重的生產事故。此外，過度依賴 AI 會導致開發者產生心理上的懈怠，僅僅是審閱 AI 產出的結果而非主動思考，這反而削弱了團隊對系統所有權（Ownership）的掌控。
核心實踐：從 Pair Programming 到 Mob Programming
為了對抗知識孤島（Knowledge Silos）並確保品質，該團隊採取了極端且徹底的協作模式。他們將 Pair Programming（結對編程，由兩名開發者共同作業）擴展為 Mob Programming（群體編程，整個團隊共同處理單一任務）。
這種模式的核心在於「絕對不孤立地執行任務」。無論是撰寫程式碼、分析日誌、製作簡報還是設計文件，所有成員都會聚在一起。為了維持專注力，他們採取高頻率的角色切換：在結對編程時每 15 分鐘切換一次駕駛者（Driver，操作鍵盤的人）與導航者（Navigator，思考方向的人）；在群體編程時則縮短至每 5 分鐘切換一次。
這種做法的目標不再是追求單純的產出速度，而是追求「易於變更的程式碼」。透過 TDD（測試驅動開發，先寫測試再實作功能）與持續部署，團隊能將變更切分成極小單位，每小時多次部署至生產環境。這種工作流強制團隊在開發過程中不斷溝通與同步，使領域知識自然地在成員間傳播，而非集中在少數資深人員腦中。
AI 的正確定位：作為加速器而非替代品
儘管對 AI 生成程式碼持保留態度，該團隊並非排斥 AI，而是將其重新定義為「超級顧問」或「加速器」。他們將 AI 的應用場景區分為兩類：
首先是分析與啟動階段。AI 非常擅長處理大量數據、分析複雜的程式碼結構或將監控指標（Telemetry）視覺化。例如，當團隊需要理解一個複雜 API 的測試覆蓋率時，先讓 AI 進行分析並提供概覽，能極大地縮短人類進入狀況的時間。這就像是騎自行車，AI 提供額外的能量讓開發者更快到達起點，但方向盤仍由人類掌控。
其次是低風險的重複性工作。對於一些標準化的整合介面或前端原型的快速搭建，AI 能顯著提升效率。但一旦進入核心領域層（Domain Layer）的邏輯實作，團隊會堅持由人類親手撰寫，以確保對業務邏輯的絕對控制。
影響與實務意義：心理安全感與人才培育
這種以人為中心的協作模式對團隊文化產生了深遠影響。最顯著的改變在於新成員的入職（Onboarding）過程。傳統方式是給新進員工一個簡單任務，讓他們在壓力下證明能力；而該團隊則採用 Job Shadowing（職務跟隨），讓新成員直接加入 Mob Programming 流程。
由於每 10 分鐘就輪到一次操作機會，新成員能在資深同事的即時指導下，在入職第一天的午餐前就將程式碼部署到生產環境。這種方式不僅消除了新人的恐懼，建立了極高的心理安全感（Psychological Safety），更解決了業界常見的初級開發者（Junior）成長斷層問題。新人在實作中學習 TDD 與領域知識，而非在 AI 生成的程式碼中迷失。
限制與反思
然而，這種模式並非沒有限制。群體編程需要極高的團隊共識與管理支持，且在短期內看來，多人處理單一任務似乎降低了「人力產出比」。但從長遠來看，它減少了昂貴的 Code Review 循環、消除了因單點故障（Single Point of Failure）導致的開發停滯，並大幅降低了系統出錯的風險。
總結來說，在複雜的舊有系統中，技術挑戰往往不在於「如何寫出程式碼」，而是在於「如何正確理解系統」。AI 能提供速度，但無法提供方向。真正的工程卓越來自於團隊對領域知識的共同掌握，以及透過協作建立的信任與品質保障。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。