At almost one in the morning, I was reading four years of my own work history on a phone. I had a simple question in front of me: what had the new helper actually changed?
The record I was reading is called git. It is just a dated list of saved changes, a little like a notebook that records every time someone puts a new version of a recipe on the kitchen counter. I was not looking for a grand theory. I wanted to know whether the feeling that things had sped up was real.
My first answer had been the easy one. I said we were faster.
That answer did not work. It was too loose to tell me what had improved, what had not, or what to do next. It also cost me a late night, because I had to go back and find a better answer instead of trusting the story I had already been telling myself.
So I counted the saved changes, year by year. Before the helper arrived, my own total had stayed close to 900 a year. In the first six months after it arrived, it was 1,105. That points to roughly 2,200 over a full year, more than twice the old pace.
The count was not only higher for me. Work that had once appeared only now and then was showing up more often. One person who had previously made only seven saved changes had made 106 in six months. A project that I would once have expected to take months went from first idea to live use in about eight weeks. Of the 30 saved changes behind it, only one was mine.
Those numbers made the word “faster” look too small.
The bigger change was where work had been waiting. For years, hard questions tended to come back to me for a look. Visual work tended to wait until someone could describe the idea, discuss it, and then turn it into something real. That is like having two checkout lines in a small grocery store. It does not matter how quickly people fill their baskets if everyone has to stand in the same two lines at the end.
The helper changed that shape. Instead of waiting to explain an idea in a meeting, we could make a rough version first. Instead of asking for a design in the abstract, we could put something visible on the table and talk about that. Instead of my evenings disappearing into tiny adjustments to how a screen looked, more of that work could move without coming back to me.
Nothing about this meant that every saved change was good. A count can tell you that more things moved. It cannot tell you whether each one was useful, large, or carefully made. In fact, the helper encouraged smaller, more frequent changes, so the count naturally rose for that reason too. Some changes recorded under my name also came from sessions where the helper did much of the drafting.
That caution matters. Numbers are useful when they stop us from guessing. They are less useful when we treat them like a report card.
The most important number went the other way. The notes left during review had tripled. They had gone from about two notes on a piece of work to about five. The helper was not doing those notes. A person was looking closely, asking harder questions, and catching things before they went further.
That made something plain to me. When it becomes easier to produce more work, the thing that gets scarce is not effort. It is judgment. The person who can say, “This is clear,” “This will confuse people,” or “This is not ready,” becomes more important, not less.
I had started with a question about output. The answer was about shape. We were not just getting through a bigger pile. Work was no longer stopping in the same places, and that gave different people room to do work they could not easily do before.
If you try a new helper at work or at home, do not begin by asking whether it made you faster. On Monday, pick one job that has been waiting on the same person, same approval, or same explanation for too long. Ask what would change if you could put a rough, visible version in front of that person first. That question may show you more than a speed test ever could.
AI Skills
Use this lesson with the AI assistant you already use
Four years of git history showed commit volume roughly doubling after adopting an AI coding tool, but the number that actually mattered was a different one: the review notes per change nearly tripled, revealing that the scarce resource had shifted from raw output to judgment.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: 'We're faster now' is a story until you count; the number that mattered wasn't the one that went up
SOURCE: dxdev.com/blog/2026-07-04_numbers-changed-the-story-i-was-telling
WHAT HAPPENED: A late-night check of four years of personal git history, prompted by wanting to verify rather than just assert that AI tooling had sped things up, found commit counts holding near 900 a year before adopting an AI helper and projecting to roughly 2,200 a year in the first six months after, more than double; one teammate's commits went from 7 to 106 in six months, and a project that would once have taken months shipped in about eight weeks with only one of its 30 commits from the primary author. The count alone was explicitly noted as an unreliable proxy for quality, since the tooling also encouraged smaller, more frequent commits that inflate the number for reasons unrelated to actual output, and some commits credited to a person were substantially AI-drafted. The number that actually changed the story was a different one: review notes per piece of work nearly tripled, from about two to about five, meaning a human was looking more closely and catching more, not less, which reframed the finding from "we produce more" to "the constraint moved from waiting on one person's time to needing more careful judgment," since it had become easier to make things visible early, a rough version, rather than waiting to explain an idea in the abstract first.
THE RULE: When a felt impression, "we're faster now," can be checked against real historical data, check it before repeating it, and pair any output metric that can rise for the wrong reasons, smaller commits, more automation-authored changes, with a counter-metric that reveals what's actually improving, since the resource that becomes scarce when output rises easily is judgment, not effort.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Any claim about productivity, velocity, or improvement stated from impression or feeling, "we're faster", "this is working better", without checking it against an available historical record.
2. Any output-volume metric, commit count, ticket count, lines shipped, reported as evidence of improvement without a paired counter-metric that could reveal the volume rose for reasons unrelated to real output, smaller units of work, automation-authored content.
3. Any workflow change credited with raising throughput without checking whether it actually removed a bottleneck or just relocated it to a different, scarcer resource such as review or judgment capacity.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.