AI Engineer onepage/ DX research
Justin Reock, Deputy CTO at DX · 約 18:32
這支影片在講：AI 讓交付變快，但沒有讓軟體工程自動變容易
DX 彙整約 20 萬名工程師、400 多家組織的資料指出：部署更頻繁、PR 產出略升，但變更失敗率更不穩，程式碼的生成從來就不是交付速度的主要瓶頸。
發布：2026-09-30講者：Justin Reock（DX Deputy CTO）
01 / 問題
速度感掩蓋品質波動
部署頻率上升，卻伴隨更劇烈的變更失敗率波動；可維護性變好，工程師對變更的信心反而下降。
02 / 反轉
程式碼不是瓶頸
最頂尖團隊也沒有普遍達成 2× 產出。真正卡住的是拆小交付、驗證、協作與把變更安全地帶到 production。
03 / 解法
把 AI 納入工程系統
用採用度、影響與成本三層指標，配合「agent experience」回饋，檢查平台是否真能支援人與 agent 一起工作。
Signals
影片最值得帶走的四個訊號
Research base
400+
組織資料，涵蓋約 20 萬名工程師；結論不是單一團隊的感受。
Throughput
+7.7%
PR throughput 的中位數增益有感，但遠不是「人人翻倍」。
PR size
44 → 72
PR 平均行數變大，反映增量交付正在被侵蝕。
Case study
300K h
Morgan Stanley 報告每年節省 30 萬工時，但必須放在完整 SDLC 中看。
Five trends
資料拆出的五個趨勢
01
交付更快，不等於交付更穩
部署頻率正在提高，但變更失敗率的變異更大。團隊不能只把 velocity 當 KPI；要同時觀察 release 是否可預測、回復是否快速，以及失敗的分布有沒有拉長。
02
維護性上升，變更信心卻下降
AI 可以協助整理與補齊程式碼，卻也可能讓審查者更難掌握意圖。當 PR 從約 44 行長到 72 行，遞增式交付和可理解性都值得被重新守住。
03
資深工程師未必用更多 token，但也能省下時間
初階工程師使用 AI 最多；資深以上工程師的使用量未必最高，時間節省卻相當。價值不只在產生量，而在是否把工作流中的判斷、探索與等待時間縮短。
04
衡量必須分開看採用、影響與成本
utilization 告訴你誰在用，impact 告訴你工作結果是否變好，cost 才讓你知道代價。混成單一「AI 使用率」會把工具熱度誤當成工程成效。
05
平台的 DX 也必須是 agent 的 DX
下一個使用內部平台的「開發者」可能是 agent。MCP server、skills、CLI、文件與回饋迴路是否能被 agent 消費，會影響 AI 能否走出聊天視窗、進入 SDLC。
Use this
給工程與平台團隊的實務清單
把效能指標配成成對護欄部署頻率旁邊放 change failure rate；PR throughput 旁邊放 PR size、review 時間與回退資料，避免只優化「更快」。
不要把 token 當 business KPItoken 是成本訊號，不是價值本身。先定義任務結果、可靠度與節省的工程時間，再看工具成本是否合理。
讓 agent 能走完整個工程路徑盤點 agent 是否能安全讀取文件、測試、部署資訊與回饋。可消費的 CLI、skills 與 MCP，比多一個 chat 入口更接近平台能力。
用案例建立可驗證的採用敘事Morgan Stanley、Zapier、Spotify 的案例都指向同一點：AI 的價值來自跨 SDLC 的重設計，不是把程式碼生成器丟給個人。
Source video