One Developer, About 16× the Benchmark: How I Normalized October

I didn't believe my own October numbers. So I tried to shrink them.

2:38

More films, including the earlier numbers, are on the playbook's videos page.

This piece is the method behind the film: what I compared against, why the raw count is wrong, how I normalized it, and what is left when I'm done.

TL;DR

• The benchmark is DX's Q1 2026 data: daily Cursor users merge a median of 4.1 pull requests a week. It is a per-developer number, so I compare one developer's account: mine.
• Counted raw, October is 119× that median. I don't trust it: PRs got much smaller, and about half of them were pipeline repair PRs.
• Anchored on September and scaled by two measures that PR packaging can't inflate (commits and code lines per day), October lands at 16.0× and 16.1×.
• It is a volume comparison against a dated cohort. Not productivity, not accepted value, and not a forecast.

The benchmark

DX published AI tooling benchmarks for Q1 2026 on January 21, 2026, drawn from 64,680 developers across 219 companies. It reports merged pull requests by tool and by how often developers use it:

I compare against the daily Cursor cohort, the highest daily-user figure in the report. A higher bar makes my multiple smaller, which is the direction I want to err in.

The comparison is per developer on both sides. DX reports a median per developer; I count the pull requests authored by one GitHub account, my own. It is not a team total divided by a headcount.

The raw count: 119×

In October my account opened 2,269 pull requests and merged 2,155; 58 closed without merging.

2,155 merged PRs over 31 days is 486.6 a week. Divided by 4.1, that is 118.7×.

I don't trust that number, for three reasons:

1. PRs got smaller. The median merged PR was 788 lines in September and 139 in October (GitHub additions plus deletions).
2. About half were repair PRs. 1,047 of the 2,155 were merged into task branches by our pipeline while it fixed its own work. Leave them out and the raw multiple is still 61×, but they are not 1,047 units of work.
3. Commits per PR collapsed. Each merged PR carried 14.9 non-merge commits in September and 2.0 in October. Merge commits went from 10.6% of all commits to 34.2%.

A PR count measures how work is packaged as much as how much work there is. When the packaging changes, the count stops being comparable with itself, let alone with someone else's median.

Normalizing: two measures, one answer

I anchored on September. It is the last month before the packaging changed: no PRs went into task branches in September, and 1,047 did in October. September measured 8.76× the benchmark (154 merged PRs in 30 days).

Then I scaled that by how much more October produced per calendar day on measures that splitting work into smaller PRs cannot inflate:

Two different measures land in the same place. That agreement is the main reason I believe the result isn't an artifact of one counter.

Lines exclude lockfiles, build output and binaries, and drop rebased copies of the same commit. Commits count distinct hashes by author date. Weekends are included in every per-day figure.

What the number is not

It is a volume comparison against a dated cohort, not a productivity score. Commits and code lines are activity. They say nothing about whether the work was the right work, and agents can make both cheap.

It is not accepted value. A merged PR is not a customer outcome.

It is not a forecast, and it is not the 20× in my playbook's title. That is a different measure, and this piece doesn't claim it.

And it depends on where a product is in its life. We are building a lot of new features, and that makes tasks plentiful. DX's cohort spans companies at every stage, including teams maintaining mature systems where a week's most valuable change might be ten lines. So this is not a verdict on anyone's team. It is a bar I'm setting for myself.

What it took to merge without breaking things

Volume only matters if it holds up. Between a task and production, the work goes through layers:

• More than 20,000 automated tests in the backend (24,558 test cases declared in the backend repository on October 31; a count of declared cases, not of CI runs).
• API tests across our endpoints, and qualitative tests.
• A peer reviewer, and an independent one.
• AI testing the product layer by layer: from the backend, to clicking through our UI, to acting as a customer through our MCP server and SDK.

Not every change passed every layer. In an audit of merged task units from October 1 to 19, 213 of 275 were reviewed with passing tests, and the first deep review returned "do not merge" on about one in five. The reviews are not decoration: they block work.

We also started work we never had room for before: a security audit and hardening. Started, not finished.

The flow, measured like a sprint board

The same month, in the terms a team would use:

• 895 tasks finished, epics excluded.
• Filed to done: a median of 2.6 days; 85% within 8.8 days.
• PR to merge: a median of about 15 minutes across all 2,155 merged PRs; about an hour (69 minutes) leaving out the pipeline's repair PRs.
• First-attempt acceptance: 72% of tasks passed with no fix round (471 of 656 with a ledger record).
• The backlog grew faster than we closed it: 1,444 tasks filed, 544 open at month end.

What it cost

Two subscriptions: $200 for Claude and $100 for Codex, monthly. At list API prices, the same usage would have cost $11,168. That figure is API-equivalent at the prices configured in my dashboard, not an invoice, and it excludes infrastructure. About a fifth of it ran in headless agents with no session open. Per finished task, that is $12.48 at list prices.

What changed

Not a tool. What changed was execution. One team memory shared by every AI session, from October 3. Agents that prepare a task, build it and review it, each with its own job. And benchmarking ourselves every month to see how far it scales. The playbook has the practices and the costs behind them.

The biggest lesson is where the effort went. Agents widened the middle of the work, and the hard part moved to asking the right questions: what to build, how to split it, and how to tell when it's done.

Run it on your own account

The method is small enough to repeat:

1. Count merged PRs authored by one account in a month, by merge date. Multiple = merged PRs per calendar day × 7 / 4.1.
2. Pick a baseline month whose PR packaging you trust.
3. For a later month, multiply the baseline multiple by the ratio of non-merge commits per day, and again by the ratio of code lines changed per day. If the two readings disagree, find out why before you quote either.

If you run it, I'd like to see what you get.