Measure outcomes, not output. When AI makes volume nearly free, the metrics that survive are the ones tied to substance: features that landed, weighted by how much they mattered, checked for whether they stayed fixed. Everything countable by the keystroke has stopped meaning anything.
Why the old metrics broke
For twenty years, engineering metrics leaned on proxies: commits, pull requests, lines changed, story points. They were never great, but they correlated loosely with effort, so managers tolerated them. AI assistance cut that correlation entirely. A developer with a good agent can produce fifty tidy pull requests in a week without breaking a sweat, and some of them will even be useful.
Research bears this out. DX, which studies engineering organisations at scale, found AI usage across more than 400 companies rose sharply over fifteen months while median pull-request throughput rose only single digits. The activity went up. The output barely moved. If your dashboard rewards activity, it is now rewarding the wrong thing at industrial scale.
What still works: three principles
1. Score features, not commits
Group work into the features it produced, then score each on two axes: quality (did it work, did it need rescuing, did someone else have to fix it) and importance (was this a critical surface or a nice-to-have). Multiply them. A mediocre feature nets roughly zero. A broken launch on a critical surface should score negative, because it consumed other people's time. Under this model, volume alone cannot climb the board, which is exactly the point.
2. Let leadership declare what matters
Importance should not be guessed after the fact. When leadership tags the quarter's priorities up front and the scoring weights work accordingly, two things happen: the leaderboard starts measuring alignment rather than motion, and engineers can check the weighting before they choose what to build. That transparency is what makes the system fair rather than political.
3. Check durability
The most underrated signal in an AI-heavy team is whether work stays done. Repeated fixes to the same subsystem, reverted merges and pull requests that stall or get superseded form a recognisable pattern: effort that never lands. Any serious measurement system has to detect it, and it has to present the pattern as evidence rather than as a silent penalty, because sometimes there is a good explanation.
The data source question
Git alone cannot tell you most of this. The richest record of how modern engineering actually happens is the coding-agent session itself: what was asked, what the model produced, whether the human checked it, how long the work really took. Teams that measure from session data plus git history get the full picture. Teams that measure from git alone are reading shadows.
Frequently asked questions
Is lines of code still worth tracking at all?
As a curiosity, perhaps. As a performance signal, no. AI assistance makes lines of code nearly free to produce, so the metric now measures how much someone leans on generation, not how much value they create.
Do these ideas punish engineers who use AI heavily?
No. Heavy AI use is fine and usually good. What gets scored is whether the resulting work mattered and survived, which rewards people who steer AI well and validate its output.
How do you stop feature-level scoring being gamed?
Pair it with gaming detection: flag commit splitting, trivial-category padding and rename churn explicitly. Score components stay visible with their evidence, so an inflated entry is easy to challenge.