Illustrative design example. This is not a verified factual account. This article exists to demonstrate the blog's layout and editorial structure. Its narrative and figures have not been fact-checked for publication.
3,296 commits across 148 active days. Three parallel fronts. One uncomfortable question: did AI change my output, or did it only change the amount of code I could produce?
The first answer was precise and wrong. Raw lines of code suggested a 31% change. Filtering for deployed work moved the result to 64%. A metric that doubles when one exclusion changes is not a conclusion. It is a warning.
TL;DR
AI increased the amount of production work I could carry, but no single repository metric proves the size of that increase. The defensible result came from triangulating activity, shipped scope, and replacement cost, then keeping the disagreement between those methods visible.
One number was never enough
Commit counts describe activity. They do not describe difficulty, value, or whether the code reached a user. Lines of code are worse when generated files, migrations, lockfiles, and deleted experiments remain in the sample.
I used three views because each fails differently:
| View | What it can show | What it cannot show |
|---|---|---|
| Git activity | Active days, cadence, and repository breadth | Product value or task difficulty |
| Deployed scope | Work that survived review and reached production | The quality of the decisions behind it |
| Replacement cost | A market-priced comparison for the delivered surface | The exact team that would have produced the same system |
The overlap matters more than any individual estimate. When all three point in the same direction, the claim gets stronger. When they disagree, the disagreement becomes part of the result.
The exclusions changed the answer
The raw sample treated every line as equivalent. It counted generated artifacts beside hand-written application code. It also treated a large deletion as negative output even when removing that code was the correct result.
The filtered sample removed generated files, dependency snapshots, and code that never reached a deployed branch. That moved the estimate from 31% to 64%.
The change did not prove that 64% was correct. It proved that 31% had hidden assumptions.
That distinction is the reason to publish the method. A multiplier without its filters is marketing. A multiplier with the query, exclusions, and alternative calculations is an argument someone can attack.
Output is a system, not a typing speed
AI changed more than implementation speed. It changed how many fronts I could keep coherent at once. That includes research, code, product decisions, verification, and the unglamorous work of closing gaps between them.
The cost also moved. Faster implementation created more review work. More parallel work increased the chance of carrying a wrong assumption across several repositories. The bottleneck shifted from producing code to deciding what deserved to survive.
That is why I do not use accepted completions, generated tokens, or prompt counts as the primary measure. Those describe tool usage. I care about shipped behavior and the cost of maintaining it.
What I changed
The measurement changed how I work in four ways:
- I separate generated activity from deployed work.
- I record active days instead of pretending calendar time is labor time.
- I compare at least two methods before publishing a multiplier.
- I treat review, rework, and deleted code as part of the cost.
The method is slower than taking a screenshot from an AI dashboard. It is also harder to turn into a clean claim. That is the point.
Assumptions & caveats
- Commit history is a proxy: commits can be squashed, split, or moved across repositories. The count describes the available record, not every hour worked.
- Deployed code is not equal to value: a ten-line decision can matter more than a thousand-line feature.
- Replacement cost is directional: team shape, compensation, domain knowledge, and coordination overhead change the estimate.
- The period is not a controlled experiment: product mix, familiarity, and tooling changed during the 148 active days.
The number I trust least is the cleanest one. The useful question is not whether AI made me 31% or 64% more productive. It is which assumptions must be true before either number deserves to leave the spreadsheet.