● From writing the code → directing an AI engineering org
Six production tools, shipping faster with no new headcount — run by one person directing an AI engineering org. The business case first, then how.
150 merged PRs across our product codebases — the six tools plus the legacy survey frontend they replace — in ~2 months — 59% of every change to them, shipped solo — up from 8% the two months before the orchestrator.
● How a change flows · on the record
It isn't just code. Pick-up to close-out runs through the same tracked pipeline a team would use — so every change is traceable, accountable, and nothing lives only in one person's head.
main.The payoff: a cross-repo fix ships from one person in one sitting — reviewed and gated — and every one leaves a traceable record and a lesson the next change inherits.
The situation
A research squad ships real software — survey tools, dashboards, reporting — living in six separate codebases a codebase is the folder where one app's code lives. Keeping six of them moving, coordinated, and documented is normally a team's job.
The old way wasn't no AI. It was AI one repo at a time an in-editor assistant like Cursor — sharp inside a single codebase, but with no shared memory across them. A change touching three codebases still meant three contexts held in one head at once — and the reason you merge a certain way, which branch deploys where, what broke last time still evaporated the moment a task was done, to be re-learned the expensive way next time.
The complication → the question
And it all lands on one person. One revamp fans into dozens of tickets across six codebases — six contexts to hold at once, with no one to hand any of them to.
So what if he didn't have to hold it alone? What if one engineer could stand up an entire engineering org — team leads, a project manager, a database specialist, an archivist — and direct it, without hiring a soul?
The resolution
Matthew designed an AI engineering org a set of specialized AI roles he configured and directs and sits at the top as its CTO — he never writes most of the code himself. He understands the ask, breaks it into scope, hands each piece to the specialist that owns that area, and reviews and gates everything that comes back.
Watch it work
The proof
The business — the products
main. Speed as discipline, not a spike.
a PR is one reviewed batch of changes before it joins the codebaseIn plain terms: more than half of every improvement to our products, by one person — the team did the rest, and we added no new headcount.
Before → after: that 59% is one engineer's share of all merged product PRs — measured the same way on both sides, back-to-back two-month windows: 8% → 59% (his own count 16 → 150, ~9×), while the team's total output still grew 32%.
The engine — the AI system that made it possible
What this means: he didn't just use a tool — he built the whole AI system that does this, from scratch.
A different axis · planning, not delivery
Plus whole programs of its own — the team's knowledge-base adoption, a self-documentation system — stood up as fully structured projects.
Every number traces to git, Linear, or the vault — filtered to one author, the AI era, product repos. Figures current as of 16 July 2026.
Go deeper — the numbers, decodedMemory + automation
A 288-note knowledge base the vault — the team's shared, written-down memory holds architecture decisions, auto-written code docs, and a navigation guide written for the AI to read — so the org never learns the same lesson twice. 104 of those notes document all seven codebases — which had no documentation before — and 184 are lessons the org banked as it worked.
The org finds sources — talks, articles, PDFs — distills them in NotebookLM, and files them as notes the AI reads back later. Claude studies, and keeps remembering what it studied.
Two cases ran on this very loop: the knowledge-base setup itself, and this award case — its storytelling sources were ingested the same way, then read back while building this page.
What this means: the org never forgets — knowledge stays even when people move on.
Two scheduled runs each week document the work automatically, with no human in the loop: one scans the week's merged changes and writes the docs; the other drives a live browser walk of the product to document its UI — each under a $20/week budget, merging its own docs.
The takeaway
Before the orchestrator, one engineer authored 8% of every change to these products; now it's 59% — the majority, shipped solo. A cross-repo fix ships from one person in one sitting, the squad moves faster without adding headcount, and its hard-won knowledge compounds instead of leaking.
The judgment was the work. The org runs the legwork — finding where to look, the syntax, the
investigation. The engineering stayed human: how to wire a CTO-style delegation hierarchy, what
is worth memorizing, when to delegate versus do it himself, and the guardrails that keep it honest —
review-and-gate every change, per-repo merge rules, nothing straight to main. The system is the
engine; the design calls were Matthew's.
One honest line, said plainly because it makes the case stronger: this "org" is a metaphor — these are AI roles one engineer designed and directs. The leverage is real and the headcount is exactly one; the numbers above are exactly as good as they are, and they still read like a team's. That's the whole point.