Go deeper · the receipts

The numbers,
decoded.

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 from each product repo's merged-PR history, filtered to one author and the AI era.

8% → 59%before → after

The number the orchestrator moved — same yardstick, both sides.

In the two months before the orchestrator, one engineer authored 8% of every merged product PR (16 of 193). In the two months after: 59% (150 of 255) — his own shipped PRs went 16 → 150 (~9×) while the team's total output still grew 32% (193 → 255). So the majority didn't come from the team slowing down: the pie grew, and one person came to author most of it.

Measured the identical way on both sides — the same author-filtered merged-PR query, on back-to-back two-month windows — so it's a fair before/after, not two different yardsticks. Conservative floor: even counting raw commits (not just PRs), the before-share was ~24%.

measured from the same author-filtered merged-PR query on the two-month windows immediately before and after the orchestrator.

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 from the 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 from the 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 from each repo's first commit date.

467merged 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 from both 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 from the 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 from the tracker's per-epic breakdown and creation dates.

12 · 38 · 7

The staff, the playbooks, the tooling.

12 agents = 6 repo leads + 6 shared-service specialists. 38 skills = codified, reusable workflows. 7 tool families = a database connector (four environments), design-to-code, ticketing, a knowledge base, error monitoring, browser automation, and terminal routing.

measured from the system's own configuration.

288notes

The org's written memory.

104 auto-written code docs + 121 architecture decisions + 33 research logs (incl. 8 ingested external sources) + 28 workflow notes + 2 team boards = 288 content notes.

Six templates and four navigation files are excluded — that's why the parts sum cleanly to 288. A naive .md count gives 234; the 10-file gap is scaffolding, not content.

measured from the 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 from each 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 467 PRs and 288 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.