DX 最近公布了一項為期 16 個月、涵蓋 400 多家工程組織的長期追蹤研究結果：AI 工具的使用率上升了 65%，而 PR 吞吐量的中位數僅成長不到 8%。多數組織落在 5% 至 15% 的區間。雖有進展，但遠低於部分廠商所宣稱的 3 倍、10 倍效益。

微軟負責開發者生產力研究的 Brian Houck 提出了一個解釋：寫程式大約只佔開發者一週工時的 14%。即使寫程式的效率大幅提升，能省回來的時間也相當有限。

剩下的 86%，像是程式碼審查、規劃、除錯、情境切換、與利害關係人來回溝通，以及在尚未釐清需求前就動手做而產生的重工，並不會因為寫程式變快就跟著變快。

這並不是要否定寫程式工具，我自己每天都在用。但「全面導入寫程式工具」稱不上是一種策略，而我最近在 Mintel 的工作重心也轉向了新的領域：協助工程團隊更有效地導入 AI 工具。如果我的工作是幫助團隊提升速度，我就必須知道哪些工具對哪些團隊真的有幫助、真正的瓶頸在哪裡，以及該如何把資源精準投入到團隊實際遇到的問題上。這首先是一個量測的問題，然後才是工具的問題。

DORA 只能告訴你「是什麼」，無法告訴你「為什麼」

大多數團隊手上其實已經有能說明一些狀況的資料。DORA 指標（部署頻率、變更前置時間、變更失敗率、服務復原時間）算是相當可靠的訊號，但擁有指標和理解指標代表的意義是兩回事。

兩年前，我用 GitLab API 從儲存庫的活動紀錄拉取部署頻率與前置時間，做了一個內部儀表板。我們的工程經理們都有在使用，它也比單看 Jira 的週期時間提供了更踏實的討論基礎。但它的侷限很快就顯現出來：它能告訴你前置時間變慢了，卻無法幫你理解原因。我和一些工程經理聊過，他們甚至會手動把指標匯出到試算表來尋找規律，這正說明了資料已經有了，但洞察還沒有。

沒有量測，我們就是憑感覺做事；有量測卻沒有脈絡，我們就是對著圖表做事。

更貼近現實的回顧

為了弭平這個落差，我正在打造一個 Agent，試著把指標帶進回顧會議的討論中，結合量化與質化的資訊來理解背後的原因。它會從 Jira 和 GitLab 拉取衝刺指標（當次衝刺與前兩次衝刺），並將這些資料餵給 LLM，同時搭配可查詢單張 ticket 與 merge request 的工具。最終產出的是一組假設與討論要點，供團隊在衝刺回顧會議中使用：包含資料所呈現的模式、值得探討的問題，以及值得進一步追索的線索。

它的目的並不是要自動化回顧會議。回顧會議是團隊反思自身經驗的過程，這個過程之所以有價值，正是因為它是由人來進行的。它能建立共識、揭露那些不會出現在指標上的事情，並營造出讓坦誠對話得以發生的心理安全感。這是演算法無法取代的。

它能做的是抓住一個問題，開始順著線索追下去。以下是幾個來自真實衝刺的例子：

• 週期時間飆高。Agent 會逐步檢視那些週期較長的 ticket 在流程中如何流轉，並點出一大半 ticket 都曾多次在「blocked」狀態間來回。重點不是「週期時間變長了」，而是「週期時間變長了，而且很多 ticket 多次卡在受阻狀態——是不是在規劃時忽略了某個外部依賴？」
• 一張 ticket 拖了三週。Agent 追蹤相關的 MR，發現這份工作分散在三個服務中。重點不是「這是一張很慢的 ticket」，而是「這張 ticket 橫跨了三個服務——變更的邊界是否劃在對的地方，還是我們正在為耦合付出代價，而這個代價還會一再出現？」
• 一個 MR 在審查階段卡了一週。Agent 查看 diff 後發現異動了 40 多個檔案。重點不是「審查很慢」，而是「這個 MR 可能太大了，難以有效審查——是不是存在把多個變更打包在一起、其實應該拆開的慣性？」

這些終究仍是假設。團隊必須去評估、反駁、判斷哪些說法才符合實情。目標是在以人為主的對話一開始，就提出由資料支撐的更好問題，讓掌握完整脈絡的工程師們得以反思真正發生的情況。

超越寫程式的 Agent

關於工程領域 AI 的討論，幾乎無一例外都會回到寫程式這件事上。DX 的資料顯示，生產力的提升確實存在，但有其上限。如果 86% 的工作佔據了大部分時間，那麼真正的提升空間就在那裡。

回顧 Agent 並不是在寫程式。它是在幫助團隊看清時間都花在哪裡，並針對這些狀況提出更好的問題。如果這個做法可行，它就證明了最有意思的 Agent 應用，或許根本就和寫程式的 Agent 長得完全不一樣。

這是系列文章的第一篇。下一篇會介紹這個 Agent 的運作方式：資料來源、提示策略，以及棘手之處。之後則會分享我們如何實際導入，以及從真實使用中得到的經驗。