Commit counts are easy to measure. PR velocity, story points closed, lines added per sprint: all of these are readily available from the tools most engineering teams already use, and they produce numbers that look like productivity data.

The problem is that they measure activity, not output. A developer who writes 2,000 lines that churn within two weeks has been very active and produced very little. A developer who writes 400 lines that hold up for six months has been less active and produced considerably more. Activity metrics don’t distinguish between them.

This distinction matters more now than it did two years ago, because AI assistance raises activity metrics without necessarily raising output.

What activity metrics tell you

Commit counts and lines added per sprint tell you how much work is happening. That’s not nothing: a sudden drop in commit velocity is a signal worth investigating, and teams with very low PR throughput probably have a process problem.

The limitation is that activity metrics can’t tell you what the work is worth. They’re agnostic to quality. A codebase filling up with duplicated, high-churn AI-assisted code will show strong activity metrics right up until the maintenance burden becomes visible.

What output metrics tell you instead

Output metrics describe what accumulates in the codebase rather than what passes through it.

Net lines measure the code that survives. High gross output with low net output means a lot of code is being written and rewritten. The difference is churn: activity that consumes engineering time without producing lasting capability.

Churn rate expresses the ratio of code rewritten shortly after being written to total code written. A churn rate of 1.0 means every line survives. A churn rate of 2.0 means, roughly, that for every line that survives, another was written and had to be replaced. GitClear’s research puts AI-assisted commits at approximately 2× the churn rate of human-authored commits on average.

Duplication rate measures how much of the new code being added already exists elsewhere in the codebase. Code that passes review, works correctly, and duplicates existing logic is still a liability: it multiplies the places that need to change when requirements shift.

Why the distinction matters for how you manage

Managers who work from activity metrics tend to optimise for the wrong things. Velocity becomes the goal rather than quality. Teams learn that high commit frequency is rewarded, which creates pressure toward smaller, less considered commits. AI assistance fits into this easily: it generates output fast, and the quality signals don’t show up in the metrics the team is already watching.

Managers who work from output metrics have a different frame. They’re asking whether the code being produced is going to survive and compound, or whether it’s going to generate future work. That question is answerable from git history; it just requires looking at different numbers.

The practical shift

Switching from activity metrics to output metrics doesn’t require abandoning velocity as a signal. Velocity matters. The point is to look at both: how much is shipping, and how much of what ships is accumulating into lasting capability rather than future rework.

Teams that track net lines alongside gross output, and churn rate alongside commit count, are measuring what their engineering capacity is actually producing rather than how hard it looks like people are working.

Scryable measures net lines, churn rate, and duplication from your git history, with before/after comparisons to your pre-AI baseline. Get early access.