2026 年最重要的軟體交付反直覺:AI 讓程式碼寫得更快,但大多數組織的主幹合併率反而下降了。 Thoughtworks 拿 CircleCI 的 2026 全球數據直接說:問題不在生成速度,在於交付管道沒有跟上。

數據事實(來源:CircleCI 2026 State of Software Delivery)

Thoughtworks 分析師 Rickey Zachary(2026-03-16)對 CircleCI 報告做了逐條拆解:

指標數值意義
平均 pipeline 吞吐量年增+59%AI 確實讓程式碼產出大增
中位數團隊主幹吞吐量-7%但真正合進 main 的反而少了
主幹成功率70.8%(5 年最低;基準值 90%)品質在下滑
平均恢復時間72 分鐘失敗後很難快速修復
Feature branch 吞吐量+50%程式碼在 branch 上堆積,但不流動到 main
Elite 團隊(前 5%)主幹+26%頂端有抓住管道,其他人沒有

核心洞見(Thoughtworks 引述):「AI 提升了個人效能和局部吞吐量,但若沒有對應投資在這些變更流過的系統上,淨效果可能是負的。」

在企業規模(每日 500 次變更),失敗恢復相當於每年消耗 12 個全職工程師 的時間。

AI-First Software Delivery(AIFSD)框架

來源:Thoughtworks Looking Glass 2026,“AI and software delivery”

Thoughtworks 提出的回應框架不是「更多 AI」,而是把 AI 鋪到交付全程,不只集中在程式碼生成這一步。

四個新興模式(目前 Assess 階段,非 Adopt):

  1. Goal-Based Development Environments(GBDE):工程師以業務目標表述需求,AI 負責實作細節
  2. Continuous Learning Delivery Systems:用戶行為反饋迴圈整合進迭代發布
  3. Neural Software Twins:運行中系統的數位副本,讓 AI 做實驗、預測回歸
  4. Synthetic Engineers(實驗性):能管理整條開發流的複合 AI 實體

立即採用(Thoughtworks 建議)

  • AI 程式碼助理 + 治理框架
  • AIOps(據報可減 70% 以上的平均恢復時間)
  • AI evals 作為品質檢查點
  • 清晰的護欄與倫理框架

DORA 指標比 AI 時代之前更重要

來源:Technology Radar Vol.34,“DORA metrics” blip(Adopt

Radar 直接說:

「在 AI 輔助軟體開發的時代,DORA 指標比以往更重要。用 AI 生成的行數或 PR 數衡量生產力是誤導性的;真正的改善必須反映在交付流動性和穩定性上。如果 lead time 沒有縮短、部署頻率沒有提升,更快的程式碼生成並不等於更好的成果。」

Vol.34 新增了第五個指標:Rework rate——用來監控 AI 引入的回溯修復量,這在 AI 時代是全新的技術債形式。

五個核心指標:

  • Lead time for changes(需求到部署的時間)
  • Deployment frequency(部署頻率)
  • Mean time to restore(MTTR,平均恢復時間)
  • Change failure rate(變更失敗率)
  • Rework rate(AI 時代新增)

主張 vs 可佐證

  • 可佐證:吞吐量 +59%、主幹 -7%、成功率 70.8% 都是 CircleCI 公開報告數據;Thoughtworks 分析有具體文章記錄。DORA 指標是 DORA Research(Google DevOps Research & Assessment)的多年研究成果,有公開論文支撐。DORA blip 評等為 Adopt,代表 Thoughtworks 在多個客戶場景中已驗證。
  • 主張:AIFSD 四個新興模式(GBDE、Neural Software Twins 等)是 Thoughtworks 預測框架,尚無大規模實證;AIOps 的「70%+ MTTR 改善」數字的來源方法論未在這篇文章中完整說明;「12 個全職工程師」的計算假設未公開。
  • 收斂結論交付管道,不是程式碼生成速度,才是 2026 年 AI 輔助工程的真正約束。 量測方式需要從 velocity(速度)轉向 flow(流動性),並加入 rework rate 監控 AI 引入的回頭債。

來源: