What changed: AI broke the volume metrics
If you have ever watched Claude Code or Cursor produce a two-thousand-line scaffold from a one-line prompt, you already know why this list needed rewriting. Every volume-based metric assumed that more code meant more work, and that assumption quietly held the whole measurement stack together. This section covers what that break means before we rank anything.
Quick Answer
The code metrics that matter in 2026 are the ones that survive AI-generated code: change failure rate, rework and churn ratio, review depth, time from first commit to shipped, scope of change per period, and output per unit of effort (leverage). The ones that lie are the classics: lines of code, commit counts, contribution streaks, and story-point velocity, because an agent can inflate every one of them in seconds. The test for any metric is simple. Ask what it would cost to fake it. Below: the test itself, the metrics that pass, the ones that fail, and how to track the good ones without turning your week into surveillance theatre.
Lines of code, diff size, commit frequency, and green-square density were always weak proxies, but they were weak in a stable way: a prolific week usually did look busier in the repo. Agents severed that link. A huge diff can take forty seconds of prompting, and a one-line fix can follow two hours of reading and thinking that leaves no trace. Volume now measures how the work was batched, not how it was done.
This is why the useful question shifted from "how much code" to "what did the code do." Metrics that read outcomes (did it ship, did it break, did it get rewritten) still work, because outcomes are expensive to fake regardless of who or what typed the characters. Metrics that read activity are now the cheapest thing in the world to inflate.
The one-question test for any code metric
Most developers meet a new dashboard by asking what it shows. The better question, and the one this whole page hangs on, is what it would take to game it. Run every metric through one filter: could an agent, a script, or a motivated intern inflate this number without doing real work?
If the answer is yes, the metric is a claim. If the answer is no, or "only at the cost of actually doing the work," the metric is closer to proof. Commit counts fail instantly (an agent can commit hourly). Change failure rate passes, because the only way to fake "my changes do not break production" is to ship changes that do not break production. What separates a vanity metric from a working one is that the cost of faking it equals the cost of doing it.
The code metrics that matter
You are probably tracking three of these already without calling them metrics. Here is the short list that passes the test, and what each one is genuinely good for. The table gives the verdict; the notes below give the nuance.
| Metric | What it tells you | Can it be gamed? | Best for |
|---|---|---|---|
| Change failure rate | How often your changes break things | Only by shipping less or shipping better | Quality over time |
| Rework / churn ratio | How much new code gets rewritten within weeks | Hard; rewrites are visible in the diff history | Spotting rushed or AI-slop code |
| Review depth | Whether changes get real scrutiny or rubber stamps | Partly; needs review-time context | Team health |
| First commit to shipped | How long work takes to reach users | Hard; timestamps are in the repo | Momentum, delivery |
| Scope of change | What shipped in a window | Hard to fake, easy to verify | Proof, invoices, updates |
| Leverage (output per effort) | What you shipped relative to time spent | Requires real activity data | Individual improvement |
Change failure rate. The percentage of your deployments or merged changes that cause a failure needing a fix. It comes from DORA research and it survived the AI era untouched, because it measures consequences, not activity. In practice this is the first number worth watching on any team, solo projects included: your hotfix-to-feature ratio is the same signal wearing casual clothes.
Rework and churn ratio. The share of recently written code that gets rewritten or deleted within a few weeks. GitClear built a research niche on this, and their data made the metric famous for a reason: it is the clearest fingerprint of AI-generated code that looked fine and was not. If a third of what shipped last month is already gone, volume metrics were lying about last month. If you are evaluating tools in this space, the DevClocked vs GitClear comparison covers where diff-quality analytics stop and proof-of-work starts.
Review depth. Are changes getting substantive comments and revisions, or instant approvals? Depth matters more than review count. Almost always, a team drowning in agent-generated pull requests shows the same pattern first, review turning into a formality. The metric is imperfect and needs context, but a falling review depth alongside rising diff volume is the most reliable early warning the industry currently has.
Time from first commit to shipped. How long a unit of work takes to reach users, read straight from timestamps. This is a momentum metric, not an effort metric, and that is exactly why it holds up. It does not care whether an agent wrote the code. It cares whether the thing shipped, which is the part users and clients care about too.
Scope of change. What shipped in a given window: features touched, modules created, endpoints added, tests written. Tied to a date range, this is the backbone of a changelog, an invoice, or a standup that says something concrete. You will often see this dismissed as "not a real metric" because it is not a single number. That dismissal has it backwards. Scope is the metric everything else is trying to approximate.
Leverage: output per unit of effort. The ratio of what shipped to the time spent shipping it. This is the metric AI made both possible and necessary. If an agent does the scaffolding, your leverage should be visibly rising, and if it is not, the tooling is not paying for itself. Measuring it honestly requires knowing real time spent, which commit timestamps alone cannot give you. The guide to measuring AI coding productivity goes deep on why, and this is where telemetry-based tracking earns its keep.
The metrics that lie (retire these)
If you have ever felt vaguely judged by a contribution graph, this section is the permission slip to stop. These metrics are not just weak now, they are actively misleading, and the more AI you use, the more they mislead.
Lines of code and diff size. An agent writes thousands of lines in seconds. Enough said, but the corollary matters: small diffs now often carry the most human judgment. Ranking work by size inverts reality.
Commit counts and streaks. Batching artifacts. Agent workflows produce fewer, larger commits or a burst of tiny ones depending on configuration, not effort. The breakdown of why commit graphs mislead covers how these numbers get gamed and misread by everyone from recruiters to your own brain.
Story-point velocity. Self-reported estimates aggregated into a self-referential number. It measured negotiation skill before AI; now it also measures how aggressively a team lets agents inflate ticket throughput. Cross-team velocity comparisons were always astrology.
Hours inferred from commit gaps. Clustering commit timestamps to estimate hours was a decent approximation for a decade. In an agent-heavy workflow the gaps stop meaning "thinking" and the bursts stop meaning "typing," so the estimate drifts most for the developers using AI most. Git is a baseline, not a clock.
How to track the good ones
Most developers hit a wall here. The metrics that matter are exactly the ones a single dashboard query cannot produce. This section covers the practical stack, cheapest first.
- Start with what the repo gives you free: first-commit-to-shipped times, scope per window, and a rough churn read from
git log --stator any git analytics tool. Ten minutes a month is enough. - Add failure tracking: tag hotfixes and reverts consistently (a commit convention is fine) so change failure rate becomes a grep, not a project.
- For rework depth, use a purpose-built diff analyser if the stakes justify it. GitClear is the research leader; Waydev aims at manager-level DORA reporting, and if its enterprise pricing does not fit a small team, there are lighter Waydev alternatives.
- For leverage, you need real activity data, not inferred time. This means lightweight telemetry: an editor extension or CLI tracker that observes work as it happens, including agent sessions, and reconciles it against the git record.
- Publish a small set. Three metrics you check monthly beat eleven you check never. Your coding stats only compound if the underlying numbers are ones you trust.
Where DevClocked fits
If all you want is team-level DORA reporting for a platform initiative, an engineering-intelligence suite like Waydev or a hand-rolled dashboard on your CI data is the better call, and a solo hobbyist who just wants churn insight can get most of it from free git analysis scripts. DevClocked sits in a different spot. It is built for the individual developer's version of this problem. It combines a git baseline with editor and CLI telemetry, learns the relationship between the two, and turns it into the metrics this page argues for: real time spent, leverage (output per unit of effort), AI-versus-human attribution across Claude Code, Cursor, and Codex sessions, and a shipped record that is audited to source rather than self-reported. Full disclosure: I build DevClocked. The honest pitch is that the metrics that matter are the ones you can defend, and defending them requires evidence gathered while the work happened, not reconstructed afterwards.
Common mistakes with code metrics
Measuring people instead of systems. The moment a metric becomes a target for individuals, it gets gamed, and the gaming is now agent-assisted. Use metrics to interrogate your own workflow, not to rank humans.
Adopting eleven metrics at once. In practice, every metrics initiative that starts with a wall of dashboards ends with nobody looking at any of them. Start with change failure rate and one more.
Trusting a number you cannot trace. If a dashboard says "34 productive hours" and cannot show you the underlying events, it is an estimate wearing a suit. Traceability back to source is what makes a metric evidence instead of a claim.
Ignoring the denominator. Output without effort context rewards whoever ran the most agents. Effort without output context rewards whoever looked busiest. The interesting number is always the ratio.
