Why Commit Count Is Dead: New Engineering Metrics for the AI Era
An engineer with Cursor can generate 50 commits in an afternoon. None of them may ship. Here's what to measure instead.
A year ago, if someone told you their team shipped 300 commits last sprint, you'd have a rough sense of their output. Today, that number tells you almost nothing.
An engineer with Cursor or Claude Code can generate 50 commits in an afternoon. Most of them will be AI-generated boilerplate, configuration scaffolding, or auto-completed utility functions. The code exists — but did anything actually ship? Did any business problem get solved?
This is not an edge case. It's the new normal.
The old metrics are broken
Let's walk through the traditional engineering metrics and what AI has done to each:
| Metric | What it used to mean | What it means now |
|---|---|---|
| Commits / day | Output velocity | AI can generate commits faster than humans can review them |
| Lines of code | Scope of work | AI writes hundreds of lines in seconds — most of it noise |
| PR count | Feature throughput | AI-generated PRs often contain dead code, duplicates, or unnecessary abstractions |
| Cycle time | Delivery efficiency | Faster PRs mean nothing if they don't merge, or if they merge broken code |
None of these metrics distinguish between "an engineer who used AI to ship a critical feature in half the time" and "an engineer who used AI to generate 40 PRs that all got rejected." From the outside, the numbers look the same. Actually — the second engineer looks more productive.
The signal has moved
In the pre-AI era, output volume was a reasonable proxy for impact because every line of code required human effort. The constraint was typing speed and mental bandwidth.
AI removes that constraint. The new constraint is judgment.
- Knowing what to build
- Knowing what not to build
- Knowing when AI-generated code is actually correct
- Knowing how to review, test, and integrate AI output
These are invisible to commit counters. But they're everything in terms of real delivery.
What to measure instead
If volume is dead, what survives? Three categories:
1. Merge rate
Not "how many PRs were opened?" but "how many PRs merged, and what did they actually contain?"
An AI-heavy engineer might open 40 PRs but merge 3. Another might open 8 and merge 7. The second engineer is shipping.
2. Quality signals
Rollback rate, defect density, review rejection patterns. If AI code is slipping through with bugs, it doesn't matter how fast it arrived.
3. Business logic density
This is the hardest to measure but the most important. Of the code that merged, how much was meaningful feature work vs. scaffolding, config, or boilerplate? AI is very good at the latter. Humans should be measured on the former.
The new evaluation framework
This is why we built the Developer Impact Index (DII) at Deveval. It combines:
- Code Quality — architecture, maintainability, defect risk, review signal
- Delivery Capability — business logic shipped, feature completeness
- Engineering Efficiency — cycle time, first-pass merge rate, productive AI adoption
- Contribution Breadth — cross-repo ownership, review contributions, team leverage
Each dimension gets weighted into a single 0–100 score. No commit counting. No line counting. Just outcomes.
The bottom line
If you're still evaluating engineers by commit count or lines of code in 2025, you're optimizing for AI output — not human impact. The metric is dead. Time to upgrade.