DX 最近公布了一項為期 16 個月、涵蓋 400 多家工程組織的縱向研究的結果：AI 工具使用量成長了 65%，而 PR 吞吐量的中位數僅成長不到 8%。大多數組織落在 5% 至 15% 的區間。雖有意義，卻遠低於部分廠商所承諾的 3 倍或 10 倍。

在 Microsoft 領導開發者生產力研究的 Brian Houck（布萊恩·霍克）提出了一項解釋：寫程式約占開發者每週工時的 14% 左右。

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

這並不是反對寫程式工具，我每天都在用。但「全面導入寫程式工具」並不是一種策略，而我最近在 Mintel 轉向了一個新的重點領域：協助工程團隊更有效地導入 AI 工具。如果我的工作是幫助團隊加速前進，我需要知道哪些工具正在幫助哪些團隊、真正的瓶頸在哪裡，以及如何將投資精準投入團隊實際面臨的問題。這在成為工具問題之前，首先是一個量測問題。

DORA 告訴你發生了什麼，卻沒告訴你為什麼

大多數團隊其實已經擁有能說明一些情況的資料。DORA metrics(DORA 指標)（部署頻率、變更前置時間、變更失敗率、復原時間）是相當合理的訊號，但擁有指標與理解指標的涵義是兩回事。

兩年前，我利用 GitLab API 從儲存庫活動中提取部署頻率與前置時間，建置了一個內部儀表板。我們的工程經理們都在使用它，相較於單看 Jira 的週期時間，它為討論提供了更貼近實際的依據。但它的限制很快就顯現出來：它能告訴你前置時間變慢了，卻無法幫助你理解原因。我曾與一些工程經理交流，他們甚至開始手動將指標匯出到試算表中以尋找規律，這清楚顯示資料就在那裡，但洞見卻沒有。

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

更貼近實際的回顧

為了彌補這個落差，我一直在打造一個 agent(代理)，將指標帶入回顧會議的討論中，結合量化與質性資料來理解背後的原因。它會從 Jira 與 GitLab 提取衝刺指標（當次衝刺與前兩次衝刺），並將其輸入至 LLM(大型語言模型)，同時配備可查詢個別工單與合併請求的工具。產出的是供團隊衝刺回顧使用的一組假設與討論要點：資料所顯示的模式、值得提出的問題、值得深入探究的線索。

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

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

• 週期時間飆升。 agent 會逐步檢視那些週期時間較長的工單如何在工作流程中流轉，並指出其中有許多工單曾多次進出「blocked（受阻）」狀態。重點不是「週期時間上升了」，而是「週期時間上升了，且有許多工單反覆停留在受阻狀態——是否在規劃時忽略了某個外部依賴？」
• 有一張工單拖了三週。 agent 追蹤相關的 MR，並發現這項工作分散在三個服務中。重點不是「這是一張很慢的工單」，而是「這張工單牽涉到三個服務——變更的邊界是否劃在正確的位置，還是我們正在為耦合付出代價，而這個代價還會一再出現？」
• 有一個 MR 在審查階段停留了一週。 agent 查看差異內容，發現異動了 40 多個檔案。重點不是「審查很慢」，而是「這個 MR 可能過大而難以有效審查——是否存在應拆分卻被打包在一起的變更模式？」

這些仍然只是假設。團隊必須加以評估、提出質疑、判斷哪些假設真正符合實情。目標是在由人主導的對話開始時，提出由資料支撐的更好問題，讓掌握完整脈絡的工程師能夠反思真正發生的情況。

超越程式撰寫的 Agent

幾乎所有關於工程領域 AI 的討論，最後都落到寫程式上。DX 的數據顯示生產力的提升是真實的，但有其上限。如果另外那 86% 的工作占據了大部分時間，那麼真正的生產力提升空間就在那裡。

一個回顧用的 agent 並不是在寫程式。它在幫助團隊看清時間都花在哪裡，並針對這些情況提出更好的問題。如果它能發揮作用，這將是一個使用案例，證明最有意思的 agent 應用，或許看起來完全不像寫程式用的 agent。

這是系列文章的第一篇。下一篇將介紹這個 agent 的運作方式：資料來源、提示方法，以及棘手之處。再下一篇則會談到我們如何推廣它，以及從實際使用中學到的經驗。