a measurement essay · july 2026

I tried to disprove my own AI productivity story.

Everyone in software has a 10× story right now, and almost nobody shows their work. I had a feeling I didn’t fully trust: that the engineering function I run had become the most productive and highest-quality it has ever been. It was an agency once, then a dozen-person team. Today it is two people and an AI. So I did what you should do with a feeling like that:

I spent an evening trying to kill it with data. This page is what survived.

the subject

One platform, five years, every configuration.

The platform runs a school dining service end to end: eight-figure revenue, tens of thousands of meals a week, a dozen-plus states, five years old, four repositories. An agency built the MVP in 2020. A team of up to eight in-house engineers and a rotating bench of contractors ran it through 2023, and the roster wound down after that. For sixteen months I ran the platform alone. This January, a second engineer joined me. The entire engineering function today:

Same codebase across every era, which makes it a rare controlled experiment: you can measure what each configuration of people and tools actually produced, in one history, with no survivorship bias.

the picture

The experiment, drawn.

Every month for five years, stacked by who shipped it: the agency, the contractors, the staff, and me. Only merged work draws the bars; the pull-request pulse runs below. Hover any month for its detail, including work still in development.

monthly lines of merged code, by cohort · me, staff, contractors, agency · counted under the six rules below · axis capped at 65k; the record month breaks the frame, true total labeled
the results

What five years of git history says.

For calibration, I have authored more merged pull requests than anyone in this platform’s history: 753 of its 1,854. The baseline below is my own pre-AI pace, which was not slow. All figures are lines of code changed per active month, measured under the rules in the next section.

≈6× my own pace, versus my career baseline
6.4× across 2026 (20.7k lines a month against a 3.2k baseline), and the last three months ran at 9.4×.
≈5× versus my best year before AI
4.7× against my peak pre-AI twelve months, not my average. That year averaged 4.4k lines a month; 2026 averages 20.5k.
≈8× the function’s per-person pace
Lines shipped per active contributor-month, 2026 versus the dozen-person era of the same codebase.

I expected the audit to embarrass me. I had been calling this year “5–10×” from feel, and the first draft of the measurement only supported 3×. But most of what the stricter rules ended up cutting was noise in my pre-AI numbers: formatter sweeps, migration churn, relocation cleanups. The baseline shrank and the multiplier rose to 6.4×. The count also omits this year’s strategy briefs, produced videos, and internal tooling, since none of that lives in a diff. I publish 6× because it’s the part I can prove.

the method

Six rules that made the number smaller.

A productivity claim built on git is easy to inflate, by accident or on purpose. Every rule below exists because it caught an inflation, usually mine.

01

Count lines changed, not commits.

Commit counts follow workflow more than output: one era squash-merged a month of work into single commits while another committed forty times a day. A squash-merge carries its branch’s entire diff, so lines changed count the same work identically no matter how it landed.

02

Exclude everything generated.

Lockfiles, vendored dependencies, build output, minified bundles, and identified mechanical sweeps. This rule found a committed deploy bundle quietly inflating a single month by 52,000 lines that nobody wrote, a 12,000-line code-formatter commit, and repeatedly regenerated migration and schema files.

03

Exclude repository bootstraps.

A repo’s parentless first commit “authors” its entire imported tree. The largest single deduction of the whole audit was a 136,000-line clone commit. It was mine. So were the 62,000 lines of cleanup that pruned that clone into shape, excluded for the same reason.

04

Run copy detection on everything.

Landed history and unmerged branches alike are measured with full copy detection, so relocated or duplicated code counts only its modifications. This caught 8,600 lines of copy-pasted component tree that looked like fresh authorship until git diff -C -C said otherwise. The same net principle retires temp-and-revert pairs: code that landed and un-landed counts as zero.

05

Credit pull requests to whoever opened them.

Merge clicks aren’t authorship, and squash-merges can reassign credit in both directions. The one signal that holds up across every workflow is who opened the PR.

06

Check that quality held.

The measurable proxy for quality here is the share of shipped lines that are automated tests: 29% this year, 1.3× the team era’s rate, alongside human review and QA on every change. The biggest building month in the platform’s history happened in July, under those gates.

All six rules push my number down. The multipliers above survived every cut I could think of.

what it means

The economics changed.

The function today is two engineers, Claude Code, and a part-time QA, and all three matter: none of this works without judgment about what to build, taste about what to keep, and a human gate before customers see anything. What changed is what one experienced engineer’s month produces, in volume and measurably in quality, when AI is part of every working day.

A small, senior, AI-augmented team now outbuilds the much larger roster this same platform used to require. If you’re sizing an engineering organization in 2026, that’s worth measuring for yourself rather than taking anyone’s word for it, including mine. The harness is about 300 lines of Python over git log. Write your own rules and believe whatever survives them.