Acceptance rate is a vanity metric
Acceptance rate, the share of AI suggestions developers keep, is the metric every vendor dashboard leads with, and the Copilot acceptance rate is probably the number your board has already seen. It measures insertion, not impact. Code was accepted into an editor; whether it survived the session, the review, or the first week in production is a question the metric cannot see. Treating it as evidence that AI improved your delivery is like measuring a sales team by emails sent.
We have sat in more than one steering meeting where a rising acceptance curve was presented as ROI. The uncomfortable question to ask of that chart is simple: accepted, and then what?
What acceptance rate actually measures
Watch a developer work and the metric explains itself. Accepting a suggestion is a keystroke decision made in about a second, and the rational move is often to accept and then edit, because fixing a nearly-right line is faster than typing it from scratch. The metric records a win; the developer rewrote the line. It rises with autocomplete latency improvements, with suggestion length tuning, with developers simply habituating to tab. It varies by language, by boilerplate density, by how much test scaffolding the team writes. None of that is delivery performance, and a vendor can move the number without your codebase getting any better.
There is also a quieter problem: it is the tool grading its own homework. Any metric a vendor can compute without access to your outcomes, your cycle time, your defects, your incidents, is a usage metric wearing an impact costume. Seat activation and daily active users belong to the same family. Useful for adoption tracking, mute on value.
The afterlife of accepted code
Acceptance is the beginning of a life, not the end. Some accepted code is rewritten within the minute. Some dies in review. Some merges and gets reverted. Some ships the bug that becomes Tuesday’s incident. When we trace suggestions through repository history with teams, a meaningful share of accepted code simply does not survive in its accepted form, and the metric counted every one of those as success. A team can post an impressive acceptance rate and a rising defect escape rate in the same quarter with no contradiction at all: the dashboard measures the top of a funnel whose bottom nobody instrumented, and review is usually where the funnel silently narrows.
What correlates with real impact
The metrics that hold up are the unglamorous delivery ones, measured against a baseline. Cycle time from start to merged, because that is where speed either materializes or does not. Time to first review and review depth, because AI shifts load onto reviewers and the shift is invisible in generation metrics. Defect escape rate and change failure rate, because speed that ships bugs is negative speed. Rework rate, the share of changes modified again within days, which is where accept-then-rewrite finally becomes visible.
None of these mean anything without a before picture, which is why we baseline a team’s delivery metrics before any rollout: without it, the debate between believers and skeptics runs on anecdotes forever, and both sides are unfalsifiable. With it, the question "did agents improve delivery" has a boring, factual answer. The full measurement approach is its own note on measuring what AI actually changed in your delivery, and for the budget conversation, cost per delivered change frames the spend honestly in a way per-seat pricing never will.
Keep usage metrics in their place
Acceptance rate is not useless, it is miscast. As an adoption signal it earns its place: a developer at near-zero acceptance three months in either has a configuration problem or has quietly opted out, and a team-by-team usage spread tells you where your enablement effort should go next. That is diagnosis. The mistake is promotion: moving a usage number into the value column of a business case because it was the number the dashboard offered.
A useful habit for any AI metric you are shown: ask what decision it can change. Acceptance rate can change onboarding and training decisions. It cannot tell you whether to expand the rollout, whether quality is holding, or whether the spend is justified, and those are the questions your board is actually asking.
When we run the measurement side of an agentic engineering engagement, the first act is usually retiring the vanity dashboard and standing up the delivery one. Teams are sometimes disappointed by how ordinary the real metrics are. That ordinariness is the point: agents are supposed to change your delivery, so measure your delivery, and let the tab key keep its own score.