Do not manage AI adoption by counting lines generated, suggestions accepted or prompts sent. When a measure becomes a target, people optimize the measure. Track outcomes such as lead time, change fail rate and escaped defects instead, and use usage numbers only to find who needs help.
The principle
DORA's guidance names the pattern when it warns that setting metrics as goals invites teams to game the numbers, and it cites Goodhart's law. Martin Fowler says the same about coverage: if you make a certain level a target, people will try to attain it, and tests can be weak while the number looks fine.
AI tools make this worse because output is cheap. Anything countable can be inflated with little effort.
Metrics that mislead
- Share of code written by AI. It says nothing about whether the code is good or needed.
- Suggestion acceptance rate. A high rate can mean good suggestions or careless accepting.
- Lines or pull requests per developer. Bigger is not better, and large pull requests are harder to review.
- Prompts or tokens per person. This measures activity, and activity is not impact.
- Coverage percentage on its own. See the post on coverage targets.
Metrics worth tracking
- Change lead time and deployment frequency for speed.
- Change fail rate, failed deployment recovery time and rework rate for stability.
- Reviewer rework rounds and time to first review.
- Escaped defects traced to recently changed code.
- Developer survey answers about friction and trust, as context.
How to use usage data without damage
Usage numbers can answer one fair question: who has not tried the tool and might want help? Use them for enablement, not for ranking. Keep them at team level, and say so up front.
DORA also advises against competing: the metrics are meant to guide improvement over time, not to rank teams or organizations. And it advises sharing ownership of metrics, because assigning them to separate teams can cause friction and blame.
A healthy tension
Pick metrics that pull against each other. DORA suggests relying on several, with some healthy tension between them. Speed against stability is the classic pair. If a team improves one by hurting the other, the pair shows it.
What to tell leadership
Offer a short dashboard with outcome metrics and a note on what you chose not to track, and why. Leaders usually accept that when it is framed as protecting the numbers from gaming.
A conversation starter
Bring one question to your next team meeting: what would we do differently if this number were being used to judge us? The answers usually reveal how a metric could be gamed, and what a better measure would be.
Quick check
Is AI suggestion acceptance rate a good success metric?
Not on its own. A high rate may reflect quality or careless accepting, so pair it with outcome metrics.
What does Goodhart's law say?
When a measure becomes a target, it stops being a good measure, because people optimize for it.
Sources
Last reviewed: 19 October 2026.
