Two Weeks, 253 Pull Requests

On August 11, I created an empty repository called SRD_Combat. The goal: a turn-based tactical combat game built on the D&D 5.2.1 SRD, a party of four, levels 1 through 5, a full tactical grid with cover and opportunity attacks and concentration, a persistent thirty-fight gauntlet with XP, levelling, and loot. Combat only, but complete combat, extracted faithfully from the 364-page rules PDF.

Today is August 25. Fourteen days later, the repository contains:

I did not write this code. Claude did, essentially all of it. I recently asked an independent AI reviewer to look at the repository and estimate what this output would cost in human engineering labor. Their central estimate: around 1,000 hours of engineering work in two weeks, or roughly 500–550 human-equivalent engineering hours per week. Me plus eight to fifteen full-time engineers.

That number sounds absurd. I want to walk through why I think it's roughly right, what it actually took from me, and, because this is the part most AI-productivity discourse skips, what almost went wrong.

This is not autocomplete

The reviewer made a point I think is the crux of the whole thing: the published productivity studies aren't measuring this workflow.

METR's widely-cited early-2025 randomized study found that experienced open-source developers were actually 19% slower with then-current AI tools on mature repositories. But their February 2026 follow-up walked that back in an interesting way: later data showed signs of real speedup, developers increasingly refused to participate if AI was disabled, and, the detail that matters here, developers running multiple AI agents concurrently broke their method of measuring developer time entirely. METR now believes developers are probably more accelerated than their original experiment showed, but can't reliably quantify it.

The reason those studies don't transfer is that they measure AI as a typing accelerant. Copilot-style autocomplete makes the marginal line of code cheaper. That's not what happens in this repository.

What happens in this repository looks like this: I say, in effect, "here is the behavior I want, investigate it, design the change, implement it, write the regression tests, run the gates, have another agent adversarially review it, fix what the reviewer finds, update the docs the change invalidated, and merge the PR when CI is green." Twenty minutes of my attention becomes several hours of engineering labor. And crucially, several of those workstreams run at once. The hours don't have to pass through me sequentially anymore. That's the thing the studies couldn't measure, it isn't a multiplier on my typing speed, it's a change in what my attention is for.

What the work actually is

It would be fair to be suspicious of "253 merged PRs", plenty of repos inflate PR counts with typo fixes. Some of these are small; a documentation correction is a five-minute PR. But the median is real work, and the top end is work I would comfortably budget one to three days of senior engineer time for. A recent example, picked because it's fresh: the occupancy series, which made multi-square creatures (an Ogre occupies four squares, not one) a first-class concept. That one arc involved multi-square geometry, pathfinding changes so a route must admit the largest body traveling it, spawn legality, connectivity algorithms so terrain generation can't produce a board where deployment zones are cut off, property tests over generated boards, deterministic replay verification, and rebase handling across three stacked PRs. Nothing about that is boilerplate.

Or take the extraction pipeline, which is the part of the project I'd least want to hand a contractor. The SRD PDF is typographically hostile: the typeface differs by chapter, font weight differs within a single table, class pages mix two-column body text with full-width tables that a naive column pass slices into the surrounding prose, and one wrapped spell-list line silently dropped 39 of 339 spells for months of an earlier project's life while a lazy count >= 300 test stayed green. The pipeline that handles all of this, with validators that assert the shape of what should have been found, not just its quantity, is about 7,000 lines, plus a 3,300-test characterization harness. That subsystem alone is weeks of human work.

The part I can't delegate, and the week I proved it

Here's where I want to push back on my own headline number, because the gross figure hides the structure of the work.

The reviewer estimated I'm personally putting 30–60 hours a week into this, and that's about right, but almost none of it is engineering. My hours go to: playing full runs and reporting what actually feels wrong; drawing all the art (agents never touch it, that's a standing rule); making product calls; approving or rejecting before/after batches; and reading, endlessly reading, because the failure mode of this workflow isn't bad code, it's plausible code.

Two examples of what that human layer caught, because they're instructive in opposite directions.

The first: I played a run and told the team, verbatim, that the generated battlefields looked like kindergarten garbage. Every automated measurement said the battlefields were fine, fights resolved, pacing curves held, no stalls. The measurements were all true and the battlefields were still bad, because "does this terrain read as a place" is not a thing any of my instruments measure. That verdict spawned a seven-issue battlefield-generation overhaul, designed and specced by the agents, that no amount of additional AI throughput would have initiated on its own. In this project's rulebook, a played-run complaint formally outranks any measured number. That rule exists because of moments like this.

The second cuts the other way, and it's the one I'd want any AI-productivity optimist to sit with. Early on, a parser read the Goblin Warrior's "plus 2 (1d4) damage if the attack roll had Advantage" as unconditional bonus damage. Nothing failed. Every test passed. The attack looked implemented, and that's precisely what made it dangerous: a partly-structured rule is worse than an unstructured one, because the missing part is invisible. By the time an outside review forced the question, that same bug shape, a printed clause nothing actually read, hidden behind an entry that looked handled, had occurred fourteen times, each instance dutifully patched while the accounting mechanism that kept producing them survived. The fix wasn't a fifteenth patch. It was deleting the mechanism: the project moved to coverage-by-consumption accounting, where every structured extraction must claim the exact characters of source text it consumed, and anything unclaimed surfaces as visible, counted residue. Under that scheme the entire bug class is closed by construction, a clause nothing claims has nowhere left to hide.

Notice what that story is and isn't. It isn't "AI writes buggy code", a human team would have shipped the same bug, and I know that because humans have; conditional-rider bugs are a classic of the genre. What it is: at this volume of output, your process is your product. When code arrives at 500 hours a week, no human review pass scales with it. What scales is machinery, adversarial review as a standing role, honesty accounting computed rather than asserted, trip-wire tests that assert the invariant a parser's reading rests on so the first counter-example forces a decision instead of a silent misread. Most of my real contribution to this project is that machinery, and the irony is that Claude built most of the machinery too, under direction.

The team, because it's stranger than you think

The repository doesn't run on "me and a chatbot." It runs on a seven-agent team with written charters: a steward that owns the issue queue and keeps the docs honest, a designer that owns rules readings and signs off on any divergence from print, an adversarial QC agent that reviews every PR before I see anything, an architect for cross-cutting refactors, an analyst that runs the pacing simulations and keeps the statistics honest, an engineer for well-specified implementation, and an art-tech for the asset pipeline. Different agents run on different model tiers depending on whether the work is judgement or execution.

Two process rules turned out to matter more than any tooling. First: the issue queue is the only work queue, nothing gets worked without an issue with acceptance criteria, which sounds bureaucratic for a solo project and is actually the thing that makes parallel agents composable, because an agent picking up an issue doesn't need the context of the conversation that filed it. Second: three strikes escalates the mechanism, when QC sees the same bug shape a third time, it must file an issue asking whether the abstraction underneath is wrong, and that question can no longer be silently deferred. The Goblin Warrior shape hit fourteen occurrences before we adopted this rule; the rule exists so nothing hits fourteen again.

I also committed to sourcing genuinely independent outside review at two fixed points in the plan, because I learned the hard way that internal adversarial review, even by a separately-prompted agent, only approximates epistemic independence. The one outside critique I've commissioned so far produced the accounting overhaul above and a re-sequencing of the plan. Neither was arriving from inside on its own schedule.

The honest arithmetic

The reviewer's estimate, laid out: 253 merged PRs at a deliberately conservative 3–6 human-hours each gives 760–1,520 hours, central ~1,100. Cross-checked a second way, "what would I quote one competent C# developer to build this repository from scratch to its present state, with comparable rigor?", they landed at 5–10 engineer-months, 800–1,600 hours. Two independent methods, same range. Net of my own 30–60 hours a week of directing, testing, and playing, that's roughly 450–500 hours of engineering labor saved per week, and about 1,000 hours total so far.

Should you discount that? Somewhat, and here's how I'd do it honestly. A real 13-engineer team brings things this workflow doesn't: independent product judgment, specialized expertise, long-term ownership, people who push back on me. The equivalence claim is narrower than it sounds, it's about implementation, test, debug, and review throughput, not about replacing an engineering organization. I'd also discount for the fact that some of those 1,000 hours were spent building guardrails against failure modes that a slower, human-paced project might never have triggered at all. Process overhead scales with throughput; some of the output is the cost of the output.

But even after those discounts, the residual is not a rounding error. It is not 30%. It is not 2x. For this workflow, full-delegation, multi-agent, gate-everything, it is something like an order of magnitude, and the artifact is public: the commit history, the test counts, the pacing baselines are all sitting in the repository for anyone to audit.

One more number, because it reframes the whole discussion. I'm doing this on a $100/month Claude Max subscription, which I drain more or less completely every week. At the reviewer's midpoint estimate, that subscription is buying roughly 2,000 hours a month of otherwise-solo engineering throughput. I am, admittedly, using the account in close to the pathological power-user manner the subscription economics presumably hope most customers don't. But the ratio between what that costs and what it would cost to hire is so far from any historical precedent that I've stopped trying to find a comparison that doesn't sound like advocacy.

What I'd tell you if you wanted to try this

• Delegate outcomes, not code. The unit of work is "the behavior I want, plus how we'll know it's right", never "write this function." Acceptance criteria are the API between you and the agents.
• Build the adversarial layer before you build volume. A reviewing agent that reads every diff before you do, with a standing brief to hunt for silent losses, is worth more than any amount of additional generation.
• Make honesty computable. The best thing in this repository isn't a feature, it's an accounting scheme under which unimplemented rules cannot hide silently, because coverage is computed from what the code actually consumed rather than asserted by whoever wrote the parser. Find the equivalent for your domain.
• Instrument before you tune. Every gameplay change here quotes a 240-run simulation against a same-build baseline. Without that, two weeks of this throughput would have produced two weeks of confident drift.
• Keep the taste human, and give it veto power in writing. The played-run-outranks-measurement rule isn't sentiment. It's the recognition that everything the instruments measure is a proxy, and the human playing the game is the only party in the system who experiences the actual product.
• Expect your bottleneck to move. Mine is no longer engineering capacity. It's my own attention, my own judgment, and my drawing hand. That's a strange and honestly wonderful place for a solo developer's bottleneck to be.

Two weeks in, the strangest part isn't the volume. It's that the repository is more rigorously engineered than anything I would have built alone, not despite the AI doing the work, but because when engineering labor becomes nearly free, you can afford standards that were never economical before: zero warnings as a hard gate, adversarial review of every diff, a simulation baseline for every balance change, documentation that must be corrected in the same commit as the code that invalidated it. Those were always good ideas. They were just never worth their cost. Now they are, and the ~1,000 hours are the least interesting consequence of that.

The repository's productivity numbers in this post, commit counts, PR counts, line counts, test counts, were measured directly from the repository on August 25, 2026. The labor-equivalence estimates are from an independent AI review of the repository and its full PR history; the methodology and its caveats are described inline. METR's studies: the early-2025 experienced-developer RCT, and the February 2026 follow-up revising its design.