Measure Autonomous Work by Surface and Outcome
On July 28, 2026, GitHub expanded Copilot app usage metrics across report rollups. The changelog adds new fields: used_copilot_app, totals_by_copilot_app, a copilot_app feature value folded into the standard breakdowns, and code-activity, lines-of-code, and daily_active_users totals that now include Copilot app work. The changes are backward compatible and available in enterprise-user and organization-user 1-day and 28-day reports.
For agent-driven development, the announcement is not product news — it is a measurement-infrastructure change that makes a previously invisible surface visible. The lesson worth drawing is what to do when a new surface becomes measurable: gate on outcome, not on adoption.
Adoption Is a Lead, Not a Verdict
Usage metrics tell you that someone interacted with a tool. They do not tell you whether the interaction produced accepted, verified work. A session count is a lead; an accepted change rate is a verdict. When a new surface like the Copilot app enters the rollups, the first instinct is often to celebrate adoption growth. The better instinct is to ask what that adoption produced.
The backward-compatible design of the new fields matters here. Users and entities with no Copilot app activity omit the new sections and produce no breakdown entries. The old signals keep their shape while the new signal is additive — so the new surface can be compared against existing ones using the same fields already consumed for IDE, chat, code review, and coding-agent surfaces.
Map Each Field to an Outcome Question
The changelog lists specific fields. Each should become a question about outcome, not a dashboard trophy.
used_copilot_app— was the surface active, and for what task class?totals_by_copilot_appwithsession_count,request_count, andprompt_count— how much input did the surface consume, and what did it return?- The
token_usagebreakdown — what did the surface cost per unit of output, and did the output pass validation? - Code activity, lines added, and lines deleted — did the surface produce changes that were accepted, or changes that were reverted?
Principle: A metric that counts activity is a hypothesis. A metric that counts accepted, verified, reviewed work is evidence. Promote a surface only when the second class exists.
Compare Surfaces on the Same Axis
The value of folding Copilot app activity into the standard rollups is that the app surface can be compared against the IDE, chat, code review, and coding-agent surfaces using the same fields. That comparison is where outcome discipline lives. If the Copilot app produces more lines of code but a lower acceptance rate, the surface is generating rework, not leverage. If it produces fewer sessions but a higher accepted-change rate, the surface is efficient even if its adoption looks modest.
The same principle applies across models and languages. The totals_by_model_feature and totals_by_language_model rollups let you ask whether a particular model in the Copilot app is actually better for a particular task class, or whether it just generates more tokens. Family names do not transfer evidence between variants; each exact model route needs its own outcome receipt.
Gate on Accepted Work, Not on Activity
Agent hours vs human hours is an outcome metric. It improves when agent work is accepted, not when agent work is merely produced. The new usage fields give more granular input to that ratio: which surface generated the work, which model produced it, which language it was in, and how many tokens it cost. But the denominator that matters is human minutes saved on accepted work, not human minutes spent reviewing rejected work.
This is why instrumenting the boundary between generation and acceptance matters. The usage metrics API now tells you what was generated. It does not tell you what was accepted, what was reverted, what failed review, or what required two rounds of correction. Those signals live in your own review and merge records. Connecting the two — surface activity to acceptance outcome — is the measurement work that makes the new fields useful rather than merely visible.
Sources
Edoworks — a software factory.