[AI 洞察] 當百個AI Agent加入專案：軟體工程如何重新分工

摘要 : AI Agent加速開發與維護，也迫使團隊重思架構、文件及工程師角色。

內容:

如果一個週末內，就有100個AI Agent加入你的軟體專案，最先跟不上節奏的會是什麼？

在9月9日釋出的《The Pragmatic Engineer》播客訪談中，Codex早期建立者之一、負責OpenAI核心產品與平台組織的Dibble Sodiol提出一個對比：過去，一個小團隊可能要發展一年，才會有50至100名工程師參與；現在，100個Agent同時貢獻程式碼，一個週末就可能發生。

當程式碼產出突然加速，專案的複雜度也會更快到來。原本還有時間逐步補上的文件、模組邊界與協作方式，可能很快就要接受考驗。這也帶出一個更長遠的問題：當AI開始接手軟體維護、審查與重構，人類工程師應該把注意力放在哪裡？一個會寫程式碼的模型，又需要經歷哪些變化，才能真正承擔這些工作？

Dibble將軟體維護比喻為一筆持續繳納的稅。功能完成後，為了讓它繼續正常運作，團隊仍要升級第三方依賴、跟進安全補丁，並讓舊程式碼適應新需求。這些工作未必會增加可展示的新功能，卻決定了專案能否健康地延續。

以依賴升級為例，如果變更日誌清楚、文件完善，模型便能理解新版帶來的影響，並在程式碼庫中完成大範圍調整。這類過去因枯燥、麻煩而不斷延後的工作，現在可能在幾小時內推進。

Agent做的也不只是修改版本號，而是讀懂新版變更、找出專案中受影響的位置、調整程式碼並驗證結果。當模型能將這些分散步驟串連起來，維護工作便有了自動化的可能。文件也因此產生新的價值：變更條件交代得越明確，Agent越容易判斷哪些呼叫需要修改，專案留下的知識將直接影響自動化品質。

當維護成本下降，團隊評估新功能的方式也會改變。工程師仍須提出證據，說明改動會受到使用者歡迎、值得加入產品，也值得長期維護；但如果後續照顧功能的負擔降低，一些過去不划算的嘗試，就有了重新討論的空間。

不過，團隊仍要回答：這個功能究竟幫助了誰？它是否與整體產品協調？

Dibble曾在Google參與一項改善網頁、尤其是行動版網頁速度的專案。技術問題很有挑戰性，他也很享受這份工作，但大約兩年後，專案因只有幾百名使用者、未達Google期待的規模而被取消。

這段經歷讓他持續追問：正在做的事情有什麼影響？專案為何重要？技術上的興奮，必須與真實使用者的回饋一起衡量。

後來，他在DeepMind與OpenAI從事研究基礎設施及工具開發，關注如何讓其他人更有效率。Codex的一部分前身也源自這項需求：讓模型協助研究人員與工程師，更快建構內部系統。

團隊最初訓練內部模型，讓它熟悉OpenAI的Python程式碼庫，使其產出的程式碼風格與架構選擇更符合內部需要。這項工作之後與「自主軟體工程師」方向合併，逐漸形成面向外部使用者的產品。

但這條路也經歷過調整。Dibble表示，早期的雲端Codex使用阻力較大，尚未找到良好的產品市場契合點。團隊持續推出CLI並反覆迭代，才逐步將模型能力轉化為使用者願意採用的工具。

這也引出訪談中的關鍵概念：harness。它可以被理解為包在模型外面的執行系統。模型負責理解任務、推理並決定下一步；執行系統則負責組織工具、指令、執行環境與安全限制，讓模型能讀取檔案、執行命令、查看結果，再根據結果繼續行動。

當使用者說「幫我把這個功能改好」，模型接收到的是一個目標，但真正完成目標，還需要把需求理解、程式碼修改與驗證串成完整流程。只要中間遺漏一步，最終交付就可能不完整。

主持人提到，早期使用Codex時，模型修改完程式碼後，有時不會主動執行既有測試；後來產品開始自行完成這一步。這究竟是模型變強，還是外部程式與指令改變？

Dibble的回答是：兩者都在變化。早期模型無法穩定完成的事情，可以由執行系統先行提醒，例如要求模型修改後執行測試。等到下一代模型更能理解使用者真正想要的結果，這類提醒便可能不再必要。

因此，harness總會比模型領先一點。它先以額外支撐，讓當前模型更可靠、更有效率，也更容易被使用者控制；當下一代模型吸收部分能力後，這些外部支撐便能逐漸縮減。

對開發團隊而言，這也產生一項特殊取捨：發現模型弱點後，應投入多少工程資源彌補？研究團隊可能在一個月後改善模型，也可能需要三個月或半年。產品團隊必須綜合判斷，是立即修改執行系統，還是等待模型層面的解決方案。

Dibble特別不鼓勵為了繞過模型缺陷，建立上萬行複雜程式碼。因為模型一旦更新，這套龐大的結構可能很快失去存在的必要。Agent產品團隊因此必須持續理解模型邊界，判斷哪些部分值得長期建設，哪些只是現階段的臨時輔助。

不過，有些底層設計仍值得從一開始就重視，例如Codex核心選擇Rust。當時模型對Rust的熟練程度不如Python等語言，但團隊更看重正確性、效率、穩健性與安全性，同時也擁有能力很強的Rust開發者。

Rust能在編譯階段提供大量檢查，這些明確回饋對Agent也有幫助。程式碼發生問題時，Agent可以更早取得提示，再據此修改。Dibble認為，只要投入足夠的訓練與工程資源，Rust也能成為適合Agent使用的語言。

更深一層的考量，是將Agent本身與產品介面分開。Agent可以在不同環境中執行，介面則負責讓人使用它。如果兩者過早綁在一起，未來發展新的產品形態時，就容易受到既有結構限制。即使AI讓重寫程式碼變得更容易，良好的初始架構仍能減少後續阻力。

這一點在多個Agent同時工作時更加重要。Dibble以「盒子」比喻模組：團隊先約定盒子要完成的功能、資源使用方式、資料存取與安全要求，以及哪些條件必須始終成立。只要符合這些約定，盒子內部的實作便可以更靈活地變化。

放回軟體工程中，這就是清楚的模組邊界。一個模組修改內部邏輯時，其他部分仍可依賴既有約定運作，讓變更被限制在可理解的範圍內。

過去，系統重構可能耗費數年。即使團隊發現原本架構已經限制新功能，或對工作負載有了新的認識，也未必有能力立即調整。Dibble認為，Agent正在大幅加速這類工作，降低修正錯誤選擇的成本；但這種速度更需要清楚的結構承接。

盒子的邊界劃分得越好，內部就越能快速修改，同時減少對其他服務的影響。程式碼越容易變動，團隊就越需要知道：哪些東西可以改，哪些約定必須保持穩定。

這正是100個Agent在短時間內加入專案所帶來的問題。人類團隊逐步擴張時，大家還有機會觀察協作困難、補充文件並整理結構；Agent加入的速度快得多，軟體會在短時間內走過原本漫長的生命週期。

模型本身也持續進步，開始更能考慮長期維護與架構問題。關注點正從單一檔案是否整潔，延伸到整個系統能否支援未來的功能變化。人與Agent討論的內容，也會逐漸從「這一段程式碼怎麼寫」，轉向「整個系統應該如何組織」。

程式碼審查則提供了另一個觀察視角。Dibble早期曾參與程式碼審查模型的開發。他提到，有些錯誤極難發現：開發者依照文件理解第三方程式庫的行為，但程式庫的實際實作與文件描述並不完全一致。

要找出這類問題，可能需要沿著依賴關係向下追查三、四層。人工審查往往得花數小時，甚至需要熟悉相關依賴的實作細節。這類需要大量閱讀、追蹤與交叉驗證的工作，正是AI Agent未來可能協助工程師處理的方向。

當AI開始大量產出、維護、審查與重構程式碼，人類工程師的價值不會只剩下「寫得比模型更快」，而是更集中於定義問題、理解使用者、設計邊界、建立約束，並判斷哪些結果真正值得交付。

AI讓程式碼變得更容易產生，也讓好的文件、清楚的架構與穩定的協作規則變得更加重要。真正跟不上100個Agent速度的，可能不是打字與寫程式碼的能力，而是團隊理解系統、管理複雜度，以及決定產品方向的能力。