Google Developers Blog 在 2026 年 6 月 22 日發布「Measuring What Matters with Jules」，討論 AI coding agents 的下一個評估問題。文章指出，coding agent 正由被動完成任務的助手，轉向可以持續吸收上下文、發現風險、提出診斷洞察的 proactive engine。這代表評估標準也要改變。
現時不少 benchmark 例如 SWE-Bench，主要測試 agent 能否修好一個清楚定義的 bug。但 Google Labs 的觀點是，真正主動的 agent 要面對的是 goal，而不是單一 task。它需要探索 codebase、判斷哪些訊號重要、知道何時打擾開發者、何時提出草稿、何時追問、何時保持沉默。這種能力在文章中被稱為 insight policy。
為了建立評估基礎，Google 團隊提出用真實 bug-fixing history 作為 ground truth。他們觀察到，工程師在短時間內提交和修復多個相關 bug 時，這些 bug 往往指向同一個更高層次工程目標。例如多個 sandbox timeout、broker config 和 network isolation 問題，可能共同指向「提升 sandbox 執行可靠性」這類 aspirational goal。
在初步 benchmark 中，團隊使用 705 個 bugs 和 1,178 個 CLs，將歷史 bug 聚類為較高層次目標，然後把 codebase 回復到修復前狀態，讓 agent 在有限探索輪數內提出 final insights。之後再用 LLM judge 把 agent 的洞察與 ground truth 對照，按相關程度和 Hit@K 衡量表現。
初步結果顯示，單輪探索已能產生平均 4.5/5 的高相關洞察，對簡單問題能抓住主要訊號。但對複雜、多面向問題，探索預算很重要。文章提到將 exploration budget 由兩輪提升至三輪後，Hit@5 由 33% 回升到 57%，說明 agent 需要足夠時間和上下文去發現次要但關鍵的訊號。
這項研究的價值不只是為 Jules 建立指標，而是指出 AI coding agent 的產品方向。未來 agent 不一定只是在 issue 被指派後執行任務，它可能在開發過程中主動找出模式、風險和改進目標。但這也帶來新的 UX 問題：如果 agent 太常提醒，會打擾開發者；如果太安靜，又失去主動價值。
對工程管理來說，這篇文章提供了一個更成熟的評估框架。評估 coding agent 不應只看 pass rate 或 patch 是否通過測試，也要看它是否能找到真正值得人類注意的工程訊號，是否有證據支持，是否在合適時間介入。AI coding 的競爭正由「會不會寫 code」走向「是否懂得何時提出有用判斷」。
