GitHub's pull request counter treats a 64-package bump as one unit of demand

Search GitHub for every public pull request created between January 1 and September 1 of 2026 and the page returns 111M results ^[1]. One result on that first page is titled "Bumps the bun-patching group with 64 updates", and its body is a table of package upgrades that begins astro 7.1.3 to 7.2.9 and wrangler 4.113.0 to 4.127.1 ^[2]. Another reads "Removes esbuild. It s no longer used after updating ancestor dependency vite." and moves vite from 5.4.21 to 8.2.2 ^[4]. A third bumps three Flutter packages inside one mobile app directory ^[3].

The window is 243 days long ^[7]. Spread across it, 111 million pull requests average about 457,000 a day, or roughly 19,000 an hour ^[8][9].

The bun-patching entry counts as one of those 111 million and lands 64 version changes in the repository ^[10]. If a Q4 plan has a line reading "PRs opened against our SDK, up N percent", that line is counting objects of this shape.

Ten snippets out of 111 million

Of the ten result snippets on the page, three carry a dependencies label ^[11] and one carries a set of tags including "ai generated", "no release notes" and "type: bug fix" ^[5][12]. Others look like ordinary human work: one closes an issue and follows up on a Windows startup investigation in another, with labels ci:windows and size:extra-large ^[6].

Those ten snippets prove the categories exist and nothing else. The search page reports the total and shows individual results; GitHub does not publish the breakdown by author or by label ^[13]. Ten snippets cannot estimate a share of 111 million, and this record covers a single window, so nothing here measures whether the mix of human and machine authorship moved during the year. A tag is also a claim by whoever labelled the pull request. Counting "ai generated" tags gives a floor on machine-written PRs, never a share.

A rising PR count reads as adoption: more developers picked the thing up and stayed with it. On the evidence of one page, the count contains bug fixes written by people, dependency-group upgrades that fire on a schedule, and at least one PR the receiving project labelled as AI-written ^[5][6][11].

The provenance data is public, in a field GitHub can change

GH Archive records the public GitHub timeline and aggregates it into hourly archives of JSON events as reported by the GitHub API ^[14]. GitHub exposes 15 or more event types, including new commits, fork events, opening tickets, commenting and adding members to a project ^[15]. The whole archive is a public BigQuery dataset, updated every hour ^[16]. Google processes the first terabyte a month free, and the project's own advice is to restrict queries to relevant time ranges to keep the scanned volume down ^[17].

The catch sits in the schema. Because the payload differs per event type and, in GH Archive's words, "may be updated by GitHub at any point", it is stored as a serialised JSON string that you pick apart with functions like JSON_EXTRACT() ^[18]. Anything GitHub sends that the predefined schema does not cover arrives in a catch-all "other" column until and unless the schema is extended ^[19].

For a provenance filter, that is the failure mode to plan for. A JSON_EXTRACT against a renamed or relocated field returns null, the row keeps whatever default your CASE statement gives it, and the dashboard stays green while the classifier quietly stops classifying. The same event stream already powers products: Changelog Nightly ships a report each day at 10pm CT to unearth the hottest new repos on GitHub ^[20].

Depth is a different query

Code search covers 200 million public repositories, filters on language and filepath, and supports regular expressions ^[21]. In his newsletter, Hillel Wayne describes using it to find production uses of Python's graphlib with the query `/(from|import) graphlib/ language:python` ^[22], and then, he wrote, "After that I can sift through the results to separate real-life use cases from false positives and toy problems" ^[23].

Wayne's sentence is the honest job description for a provenance filter. A researcher writing a blog post does the sift by hand; a product team automates 80 percent of it and reviews the rest. Wayne also names the limits: "Just about the only things that don't seem work are group matching and lookarounds like (?!)" ^[24]. A regex hunting simplifiable Python returned, in his account, "like 300 code samples that could be simplified" ^[25]. Filters compose, including path scoping: `/(from|import) hypothesis/ composite language:python path:test_*.py` ^[26].

There is also a code search API. "You could feasibly run a query, dump a hundred matches into files, and then do more complicated filtering and munging before spitting out a courseload's worth of case studies", Wayne wrote ^[27].

A call site inside a test file is a different fact from a pull request event. Someone wrote an import and then wrote a test around it. That sits closer to usage depth than any count of objects created, and it is reachable with the same afternoon of work as the event query.

The editorial channel stops short of a forecast

The alternative most planning decks lean on is editorial. A testimonial published on pragmaticengineer.com says of the Pragmatic Engineer newsletter: "The level of in-depth information and knowledge sharing is out of this world" ^[28]. The person quoted says they have followed Hackernews, Hustle and platform-specific newsletters like Android weekly for almost ten years, and the excerpt does not name them ^[29].

Judgement of that kind is bot-proof. It also produces no denominator. The missing denominator is why the counted proxy ended up in the plan in the first place.

Two questions that decide whether you need the filter

Run each number in the Q4 plan through both:

Can I split this number by author class with a query I can run this week? The inputs are public: hourly archives, an hourly BigQuery dataset, a code search API ^[14][16][27].

Does this number fund something I cannot unwind before January? A hire, a price change, or a deprecation.

Split available, commitment attached: publish the split beside the total, and say which labels and title patterns you used to draw the line.

No split, commitment attached: the number is not ready to carry the decision. Substitute one you can attribute to a named actor, such as call sites and test-file imports found across the 200 million public repositories in code search ^[21].

Split available, nothing riding on it: do the split when it is cheap, then leave it alone.

No split, nothing riding on it: keep it on the dashboard and stop quoting it in reviews.

The classifier itself is unglamorous and mostly string work: match the "Bumps the ... group with N updates" title template, treat a dependencies label as a strong signal, keep an "ai generated" tag count as a floor, and hold every rule in one file you can diff when GitHub moves a field into "other" ^{[2][5][11][19]}. Bound the query to one month and it fits inside the free terabyte ^[17].