速度終於到來，但團隊還沒準備好
軟體交付的速度在過去二十年被一層層技術推高。Hannah Foxwell 在 QCon London 2026 的演講「The Reinvention of the Dev Team」中回顧，她職涯第一支團隊是大型主機團隊，一年只交付兩次；後來進入電子商務，一年能交付四次已算不錯；敏捷讓每個兩週衝刺交付一次成為可能；雲端帶來隨需環境；DevOps 與持續交付再把速度推高，如今一天多次發布到產品與平台並不罕見。Foxwell 是擁有十多年平台工程經驗的獨立顧問，長期關注平台工程、安全與代理式 AI 的交會。她的判斷是：速度終於解鎖了，但多數組織還不知道該拿它怎麼辦。
代理式程式開發是這波變化的核心。Steve Yegge 在發表代理式程式開發編排平台 Gastown 時提出「代理式程式開發的八個階段」，這個框架後來被同樣投入代理編排平台的 HelixML 推廣。在那些最前沿的團隊裡，工程師不再逐行提示模型，而是透過規格與工單驅動一整群代理：代理拆解工作、撰寫程式、寫測試、部署到生產、執行監控。Foxwell 坦言，對多數人而言這仍是理論，不是日常。但變化來得比想像快。熱門代理式程式開發平台 Cursor 今年出現一個轉折點，內部代理請求數首次超過 tab 補全的接受次數，他們稱之為程式開發的第三個紀元，代理驅動的工作已成多數。Foxwell 提醒，大多數組織還沒準備好讓開發團隊加上代理艦隊直接上生產，但自上而下的嘗試壓力一定會出現，先動手玩、理解什麼有效什麼無效，是務實的做法。她演講的重點不在代理本身，而在人與團隊如何調整，並提出三個她認為不受技術速度影響的錨點：建造值得建造的東西、速度需要安全、人很重要。
錨點一：建造值得建造的東西
Foxwell 強調，程式碼是「怎麼做」，不是「做什麼」。真正交付的是問題的解法。典型回饋循環是：使用者有痛點，產品經理理解並過濾需求，六到八人的開發團隊設計解法並以軟體交付，使用者使用後給出回饋。許多開發團隊很少直接和使用者對話，產品經理成了使用者的代理，這在過去很常見，因為產品經理必須無情地排序點子，讓工程師保持專注。
代理式開發把這個結構推向極限。當團隊速度提升十倍，能推進的變更量暴增，產品端反而出現背壓：漏斗裡沒有足夠且合格的工作讓工程師忙。Foxwell 說，幾年前她還自信滿滿地表示自己有三年的路線圖，團隊永遠不會缺待辦事項；如今她真的看到團隊因為速度太快而沒東西可做。選項不是對每個點子都說好，那會導致平台塞滿功能、每件事都做得平庸，也就是所謂的 enshitification。真正的轉機在於驗證想法的成本大幅下降。過去團隊常帶著確認偏誤，認定路線圖上的東西一定會成功，卻沒有工程餘裕實驗，只能先做出來再說。更健康的做法是先做原型、找使用者測試、反覆迭代，再決定要不要把它變成必須長期支援的產品承諾。
順著這個邏輯，實務上出現幾種新模式。vibe coding PM 不是要交付生產程式碼，而是快速做出原型來驗證想法；forward deployed engineer（FDE，前線部署工程師）被嵌入客戶端並被授權解決問題，角色不同於實作或專業服務工程師，能讓回饋循環縮到最短；product engineer（產品工程師）則常見於服務開發者的軟體公司，因為工程師自己就是使用者，能直接決定產品該有什麼、不該有什麼，incident.io 就偏好這類人才並讓工程師直接接觸使用者。團隊比例也開始鬆動。傳統的 two-pizza team 是六到八名開發者配一名產品經理，但挪威銀行投資管理機構 NBIM 正在實驗兩名開發者配一名產品經理的微型團隊，理由是產品經理已餵不飽六到八人；AI 領域的 Andrew Ng 則提出相反比例，認為兩名產品經理配一名開發者才合理，因為那名開發者背後有一整群代理，可同時推進多條產品線。Foxwell 也引用一家顧問公司的觀察：他們在兩百家公司部署約三千名開發者，目前只有兩三家真的縮減團隊，其餘都期待更多產出，這意味著團隊負責的領域可能必須擴大。
她也提醒，設計與使用者體驗不會消失，反而更關鍵。當寫程式的速度變快，能否讓使用者驚豔、能否把使用者研究與可用性測試加速到軟體開發的速度，才是差異化來源。該被淘汰的實務包括 ship and switch，也就是交付第一版後立刻切換到下一個問題、從不回頭改善；對每個客戶要求都說好；以及 HIPPO，也就是由最高薪者的意見決定優先順序。該保留的是能自主決策的產品團隊、與真實使用者的快速回饋循環，以及使用者研究。她甚至直言，六到八人的 two-pizza team 與六個月路線圖都該退場，不是說規劃無用，而是現在就決定半年後要建什麼已不再是有價值的練習。
錨點二：速度需要安全
第二個錨點是速度不能犧牲安全與可靠性。通往生產環境的路徑必須驗證軟體做對的事、沒弄壞重要功能。許多組織仍存在手動步驟與測試覆蓋缺口，這在高速交付時非常危險；一旦程式碼產出速度超過管線吞吐量，堆積就會出現，並在其他環節造成背壓。Foxwell 的結論很直接：高信心需要測試，高速度需要自動化，兩者缺一不可。她引用 AWS 的案例，該團隊透過代理式程式開發把吞吐量提升十倍，但前提是徹底重想測試、部署與協調方式，而不是把 AI 的速度硬接到舊流程上。摩根大通則用 AI 代理驅動持續元件測試，這被 Foxwell 視為合乎人性的選擇：幾乎沒有開發者喜歡測試，那是繁瑣的苦工，交給代理處理，同時也把品質閘門自動化，讓速度有機會真正兌現。
她指出，第二天成本永遠高於第一天，也就是軟體上線後的維護、支援、修補與改善，長期一定比開發更貴。使用者雖然不會明說，卻非常在意安全與可靠性；當 Amazon、Claude、GitHub 的可用性問題登上主流新聞，產品聲譽就會受損。好的安全往往隱形，直到出事那一刻才被看見，使用者則永遠預期資料受到保護。為了在大量變更中維持可靠感，漸進式交付仍然重要，包括功能旗標、A/B 測試與藍綠部署。SRE 領域早已提供一套語言：SLI 是以使用者為中心的服務水準指標，SLO 是對使用者的可靠性承諾，錯誤預算則是可接受的失敗量。Foxwell 特別強調錯誤預算政策，因為它明文寫下當組織違背可靠性承諾時要做什麼，例如放慢發布、投資可靠性或韌性。若組織還沒有這份文件，現在正是時候。
平台工程與 SRE 可能因此回歸核心。平台工程師提供鋪好的路、隨需環境與預設安全，讓安全的事同時是容易的事；SRE 團隊則可作為內部顧問，專門協助打造韌性系統。Foxwell 坦承自己過去認為把 SRE 獨立成一個組織是反模式，但現在重新考慮，因為當變更速度暴增，可靠性需要專家介入。她也點出比例問題：目前 SRE、平台與安全團隊的人數往往遠少於開發者，但這些功能正是解鎖開發速度的關鍵，未來比例可能需要調整。至於技術債，代理很擅長遷移、離開老舊平台與重構，當產品經理一時擠不出足夠的合格工作時，正是把長年爭取不到時間的工程待辦事項清一清的時機，尤其代理平台現在成本還低。她主張保留錯誤預算政策、漸進式交付與內部平台，淘汰任何手動步驟，並開始用 AI 補測試覆蓋與處理技術債。
錨點三：人很重要
第三個錨點回到人。Foxwell 直言，審查 AI 產出的大量程式碼並不有趣，尤其當量又大又快。她引用 Joseph Ruscio 關於 write-only code 的假設：現在幾乎所有程式碼都會被人讀過，但未來可能翻轉，多數程式碼會被執行卻從未被人類閱讀。如果這是目標，開發生命週期就必須重新設計，否則將成為噩夢。同儕審查也出現左移現象：不再只是等程式碼寫完後審查 pull request，而是在程式碼產生之前就審查規格、測試策略與架構。重點仍是兩個腦袋一起判斷方向與做法是否正確，只是不必逐行讀程式碼。
待命值班也是人力規劃的硬限制。維護脆弱服務一點都不有趣，而要支撐一個生產服務有最小可行人力。若一人擔任主要值班、另一人備援，即使每人每四週輪一次，也等於一半時間處於待命，對許多人仍不可持續；把團隊縮到一人永遠拿著呼叫器更不現實。這也讓 SRE 團隊回歸多了一個理由：Google 最初的 SRE 模式只願意為符合其可靠性標準的服務值班，不符合就不接手。敏捷儀式同樣需要重新檢視。Foxwell 感覺兩週衝刺已太長，多數團隊迭代更快，每日站立、衝刺規劃與待辦事項整理可能過重，規劃與重新規劃的必要性正在下降。
技能方面，她引用 Sophie Weston 在 QCon 提出的 broken comb，也就是破梳子概念。相對於 T 型或 Pi 型人才只有一兩個專長，broken comb 強調在多個領域具備廣度，再於少數領域深入。Foxwell 認為單一領域專家未必能在代理式開發時代勝出，廣泛技能加上願意與客戶並肩工作、發展產品思維，會更有價值；可靠性與發布工程等領域也需要更多專才。她主張保留可持續的待命制度與錯誤預算政策，職涯規劃則要針對今天的現實重寫，淘汰沉重的規劃流程、兩週衝刺與逐行強制程式碼審查，並嘗試把同儕審查左移、採用規格驅動開發，讓代理有更清楚的系統行為可依循。
從 BIMP 看兩週打造產品的現實
Foxwell 以自己近期打造的 BIMP 為例，說明現在建造產品有多容易。BIMP 是 Base Image Management Platform，用來管理容器基礎映像，正好落在她平台工程與安全的專長範圍。她和另一名夥伴花了兩週，第一天早上訂下當日目標，午餐前就完成；於是午餐再開一次規劃會決定晚上要做什麼，這個節奏持續下去，直到他們重新學會不要無情地只排一兩個功能，而是早上密集規劃四五項，當天全部完成。她坦言，以前當產品經理絕不會在第一週就做管理儀表板，但這次平台功能已經可用，他們想要更好的可見性，也就做了，並很快體驗到產品端背壓的痛苦。兩週內產品出貨，用 Cursor 的代理模式重構程式碼庫只花幾小時，文件靠 AI 自動產生，幾分鐘完成；首頁甚至有一台不該出現在 MVP 的 3D 飛船，只因為建造本身就很有樂趣。
她的結語是，大家都在同一段旅程上，不是每個人都已到第八級、能編排一整群自主代理，很多人還在用提示逐步解決問題，而這同樣會釋放速度。這不是終點，也沒有單一正確方法，重點是針對當下的問題空間與任務選擇合適做法。建造從未如此容易、如此有趣，但組織要面對的改變還很多；三個錨點的作用，是讓團隊在速度湧現、新問題接踵而來時，仍能建造值得建造的東西、用安全支撐速度，並且把人放在中心。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。