I Measured My Software Factory: 36 Million Lines in 10 Months

Nobody believes me

When I tell people I run a software factory out of my house — a fleet of 150+ containers, a dispatch ladder of AI agents, ~200 self-testing quality gates, a debt ledger that converts defects into permanent checks — I get the polite nod. The one people give you when they've decided you're exaggerating.

So I stopped describing it and measured it. Not vibes, not "it feels like a team." Git history. Every repo, every drive, every commit, ten months.

This post is the methodology and the numbers — including the unflattering parts, because a measurement without its caveats is just marketing.

The methodology

Bragging with git log is easy to do badly, so here are the rules I enforced before trusting a single number:

Every repo, deduped. I swept three drives and found 35 checkouts. Same repo mirrored across drives, worktrees sharing one history, migration leftovers. Deduping by root commit hash — the one identity a clone can't fake — collapsed 35 paths into 13 unique repositories.

Only our commits. One of those repos is an upstream open-source clone. Its thousands of contributor commits would be free padding, so every count is author-filtered to me and my agents. Upstream history contributes zero.

No lockfiles, no vendored code, no generated bulk. package-lock.json, node_modules, dist/, minified bundles, sourcemaps, generated mirrors, SVGs, CSV/JSONL data dumps, model tokenizer blobs — all excluded before counting. If a filter argument would flatter the number, it was applied against the number.

Both directions counted. Added and deleted, because churn without deletion is a landfill, not a factory.

And the whole thing is a tool, not a spreadsheet. The measurement ships in the repo as a script with a --self-test that builds a synthetic git history and proves every filter actually bites. That self-test paid for itself on its first run: the initial version's author filter used | alternation, which git log --author treats as a literal character in its default basic-regex mode — so the filter silently matched nothing and the tool was confidently measuring zero. A measurement pipeline that can't fail its own test is just a story with numbers in it.

The numbers

Ten months, 2025-10-14 to 2026-08-14, as reproduced by the tool:

For scale: the Linux kernel — thousands of contributors, one of the highest-throughput software projects on earth — adds roughly 3–4 million lines a year. This operation added 36 million in ten months. On raw churn, one person plus a fleet of agents out-produced the entire kernel community by an order of magnitude.

The monthly curve tells the growth story — the peaks are the months the factory stopped being "me using AI tools" and became agents building while I slept:

The multiplier question

A solid professional engineer sustains maybe 50–150 shipped lines a day over a year — the classic software-engineering studies say even less. Against that baseline, the median daily figure here is nominally ~1000x.

I don't believe that number, and neither should you — not as stated. Lines of code was a bad productivity metric before AI agents and it's worse now. A large share of that volume is scaffolding, docs, YAML, test harnesses, and revision churn. The honest framing isn't "I am a 1000x engineer." It's:

I'm a 1x engineering director running a ~100x organization. The fleet is the workforce. The dispatch ladder routes work to agents. The quality gates — about 200 checkers, every one with a --self-test proving it can still fail — are the review org. The debt ledger converts every repeated failure into a permanent machine-enforced invariant. My actual job is keeping that machine pointed in one direction. The leverage number measures the machine, and I built the machine.

Even the net retained figure — 23.3M lines after deletions — is the raw output of a mid-size engineering org. Call it 100–300 engineers at industry rates. The deleted-to-added ratio (~0.30) is the healthiest signal in the data: the factory revises, it doesn't just accrete.

The harder question: what survived?

Anyone can generate lines. The skeptic's correct follow-up is: how much of it is still alive? So I ran the query nobody runs on their own bragging: git blame across the current tree, every surviving line attributed to the month it was written, divided by the lines added that month. Big files blamed exhaustively, the long tail estimated from a random stratified sample.

And the measurement immediately tried to lie to me. The first table said April 2026 had 94% survival — suspiciously heroic. Digging into the big-file stratum found the culprit: two 1.2-million-line tokenizer.json blobs and a pile of mirrored API docs, write-once data masquerading as durable code. I subtracted every blob from both sides of the division. What's left is the honest, code-only table (monorepo, mainline history):

Overall: 48.7%. Of 16.7 million code-ish lines added to the monorepo's mainline in ten months, 8.2 million are alive in HEAD right now.

Two honest readings of that table. First: early-months survival is brutal — October's scaffolding is 99.8% gone, and the first quarter runs ~25%. That's not waste; that's what building a factory looks like — you spend the early material on the machine that makes the later material, and the machine then replaces its own scaffolding. Second: the trend line is the real story. Survival climbs almost monotonically from 0.2% to ~100% as the quality gates came online — every month of code is more durable than the month before it, because an increasing share of it is checkers, contracts, and self-tests: code whose job is to keep the rest of the code honest, written behind gates that refuse to let it regress.

What "software factory" actually means

The number people fixate on is the wrong one. The factory isn't the 36M lines — it's the properties of the system that produced them:

• Work is dispatched, not typed. A ladder routes every task: platform agents first, direct service APIs second, local subagents offline. Multiple Claude sessions commit to the same repo concurrently, every 2–5 minutes, with lease-based coordination so they don't destroy each other's work.
• Defects become checks, not tickets. The standing rule: a mechanically-detectable defect must become a checker with a self-test, not a TODO. That's how ~200 gates accumulated — each one is a failure that can never silently recur.
• The fleet self-heals. Watchdogs restart wedged services, gates probe live capabilities every 4 hours, and an undelivered page is itself a gated failure condition.
• It runs while I sleep. The busiest single day in the dataset — 5.3M lines — wasn't me at a keyboard. It was the machine doing a migration.

Is it AGI? It's a system that takes goals, decomposes them, writes and reviews and deploys its own code, measures its own failures, and converts them into permanent improvements — at the throughput of a mid-size company, in my house, supervised by one person. Argue the definition all you want. I'm going to keep shipping.

Run it on your own repos

The whole measurement is a few lines of shell. Dedupe your checkouts by root commit, filter authors, strip the lockfiles, and be honest about the bulk days:

git log --since="10 months ago" --numstat --pretty=format:'C|%ad' --date=short \
  | awk -F'\t' '/^C\|/{split($0,a,"|");d=a[2];next}
      NF==3 && $1!="-" && $3 !~ /lock|node_modules|dist|min\.js|generated/ \
      {add[d]+=$1} END{for(x in add) print x, add[x]}' | sort

Then run the blame pass and see what survived. If the answer embarrasses you, good — now you know what your factory actually produces. Mine measured out fine. That's why I published it.