The headline counters are real — here's where each one comes from. They split into two tiers:
the business (the products that ship to customers) and the mechanism (the AI org built to ship them).
What each is composed of, which system it was counted in, and the honest caveats behind it. None of these are a
single repo's figure.
Tier 1 — the business
The products that ship to customers — and how much of the work in them is one person's.
150 merged PRs · 59%
The majority of all product change — shipped solo.
150 reviewed, gated merges across the seven product codebases (the six production
tools + the legacy survey frontend they replace) in the window — 59% of every PR merged to them by
anyone. The rest of the team shipped the other 41%.
Per-repo, the share runs from a third to nearly all — e.g. 69 of 73 on the new survey
frontend, 20 of 45 on the tool backend. Six tools only, it's 147 / 61.5%; the seven-repo cut (incl. the
legacy frontend the rebuild replaces) is the one quoted.
measured fromeach product repo's merged-PR history, filtered to one author and the AI era.
201 · 74created · shipped
Real product delivery, with a roadmap behind it.
201 product work-items created, 74 shipped to Done — the visible ~75. The
remaining ~127 are mapped future phases, not vapor: a real product roadmap. Production-migration
work is counted as product here — it ships to production; stated, not hidden.
measured fromthe issue tracker, product projects, grouped by completion state.
445 → 175squad → his
The honest split — what the team shipped vs. what's his.
445 items are the whole squad's Done-since-April output — not one person's. Of those,
Matthew personally created 321 and shipped 175, and authored 59% of all product PRs: the majority of
product change, shipped solo alongside the team.
This corrects an earlier draft that read the big number as one person's — it never was.
175 shipped and 59% of product PRs is the honest personal figure.
measured fromthe issue tracker, whole-team completions vs. one author's.
Tier 2 — the mechanism
The AI org built to ship the products above — 100% one engineer's.
~2months old
From an empty repo to a working AI org.
The orchestrator's first commit lands 25 Apr 2026; the knowledge vault's, 2 May.
Two months from nothing to the system that ships everything in Tier 1.
measured fromeach repo's first commit date.
331merged PRs
The PRs that built the org itself.
112 in the orchestrator + 219 in the knowledge vault — the two system repos
that build the org, separate from the product PRs in Tier 1. 100% Matthew on the mainline.
Mainline figure. A handful of the AI's own commits live on pre-squash feature branches (the
weekly auto-doc runner); the vault squash-merges, so what's actually in the repo is one author's.
measured fromboth system repos' merged-PR history.
120 · 101created · shipped
The tooling and documentation work-items behind the org.
120 tooling/doc work-items created, 101 shipped — the auto-documentation system, the
knowledge-base adoption program, and the system tickets that keep the org running.
measured fromthe issue tracker, the tooling/doc projects, grouped by state.
dozensof tickets, one day
A whole product revamp, structured in a single session — planning, not delivery.
Five feature epics, dozens of feature tickets, and full testing layers — all created in a single session.
This is the verified figure — planning the roadmap, not shipped work; what actually shipped is the product delivery in Tier 1.
measured fromthe tracker's per-epic breakdown and creation dates.
Six templates and four navigation files are excluded — that's why the parts sum cleanly to 224.
A naive .md count gives 234; the 10-file gap is scaffolding, not content.
measured fromthe vault's file listing, grouped by folder.
100% · 100%one author, mainline
Genuinely one engineer's leverage.
100% of the orchestrator's mainline commits (195) and 100% of the vault's (269) are
Matthew's. The AI's own direct commits exist only on pre-squash feature branches that merge under his name — so
what's actually in the repos is one author's, counted honestly, not hidden.
measured fromeach repo's per-author mainline commit history.
What one of those tickets looks like up close
A number is only as honest as the work beneath it. Take one ticket whose fix
spanned three of the six codebases
— the kind of cross-repo work a per-repo assistant can't see all at once.
Before — AI, one repo at a time
Most of the time goes to finding the flow.
One actor, visiting each repo in turn — tracing how the data crosses them before a line changes, and losing
context at every hop.
After — the org
Traced, fixed, documented in one pass.
The orchestrator fans the work across all three repos at once, then converges — and the investigation lands
in the vault, reused on related issues later.
Before · one-repo AI
After · the org
sees the flow
one repo at a time
all repos at once
the work
hand-trace, then change
routed & fixed in one pass
time
more than a day
one sitting
after it's done
knowledge leaves with you
saved to the vault, reused
And some of the count never existed before
Part of what's counted above is work that would not have happened at
all the old way.
The auto-documentation system and the
knowledge vault — a chunk of those 331 PRs and 224 notes — aren't "the same work, faster." They simply
wouldn't exist with a per-repo assistant: nothing would be coordinating across the codebases to
document, and there'd be nowhere shared to keep it. The org doesn't just speed the old work up; it produces new
kinds of work entirely.
Honest framing: the before/after uses rough ranges, not invented precision; the composition
figures are exact and traceable. Everything here comes from git, the issue tracker, or the vault. In all,
481 PRs were authored in the window — 150 to the products, 331 to the system that ships them.
Figures current as of 25 June 2026.