GitHub merged 518.7 million pull requests in the year through August 2025, up 29% from the year before, and its own Copilot coding agent alone produced more than a million of them in a single five-month window. Ask GitHub's own team what that growth actually bought engineering organizations and the answer isn't "faster shipping." In a post published this February, GitHub's own content team wrote that "the amount of time it takes to review the additional suggestions has risen faster than the number of maintainers." Coding agents didn't remove the bottleneck in shipping software. They moved it from writing code to reading it.
What GitHub's own numbers say
GitHub's Octoverse report, covering September 2024 through August 2025, is not a survey of developer sentiment. It is a count of what actually happened on the platform: 43.2 million pull requests merged on average each month, a 23% year-over-year rise, adding up to a record 518.7 million across public repositories for the full year, up 29%. Layered on top of that baseline, the report gives what it calls "a first glimpse of coding agent" activity: more than a million pull requests created between May and September 2025 through Copilot's agentic tools, a channel that barely existed the year before. Eighty percent of new developers on GitHub now use Copilot within their first week on the platform. None of that is a projection. It is what a few hundred million repositories actually logged.
The bottleneck GitHub named in its own words
Three months after publishing those numbers, GitHub put out a separate post on what to expect for open source in 2026, written by its own senior content writer, Dylan Birtolo. It is less a data release than an admission. About 60% of the platform's top-growing projects in 2025 were AI-focused, and the review queue behind them didn't grow to match: "in a lot of cases, the amount of time it takes to review the additional suggestions has risen faster than the number of maintainers." Even setting aside the low-quality contributions the post calls AI slop, Birtolo writes, "the sheer volume of contributions has grown, potentially to unmanageable levels. It can feel like a denial of service attack on human attention."
That is GitHub, the company that sells the tools generating the volume, describing the review side of its own platform as under a denial-of-service-shaped strain. Worth sitting with before assuming the fix is a better agent.
Why 72.6% satisfied reviewers doesn't cancel the queue
The same Octoverse report also found that 72.6% of developers who use Copilot's code review feature said it improved their effectiveness. That number is real and it is not the contradiction it looks like. A reviewer can genuinely work faster per pull request, feel the tool is helping, and still watch the total queue grow, because the rate new pull requests arrive rose faster than the rate any one reviewer's throughput improved. Google's DORA team found the same shape of split in its own 2025 research on AI's amplifier effect: roughly 85% of developers reported AI raised their own productivity, while about 30% said they trust the code it produces only a little or not at all, and teams with higher AI adoption logged higher delivery instability alongside higher throughput. Individual effectiveness and aggregate capacity are different measurements, and a company that tracks only the first one won't see the second one slipping until it shows up as a missed release or an incident nobody can explain in the first ten minutes of triage.
The same math runs inside a private repository
GitHub's numbers are about open source, where anonymous contributors and unpaid maintainers make the mismatch visible fastest. A funded company's engineering org isn't fielding pull requests from strangers, but the arithmetic underneath is identical: an agent's capacity to open pull requests scales with a subscription tier, a senior engineer's capacity to actually read and stand behind one doesn't scale with anything except headcount and hours in the day. Whoever was the fastest reviewer on the team before the rollout is now, by default, the reviewer of record for a volume of code that didn't exist a year ago, on top of whatever they were already reviewing. That's not a tooling problem a better model fixes. It's a capacity problem that was there before the tool and is now easier to see, because the tool made the authoring side of the equation cheap while leaving the review side exactly as expensive as a senior engineer's time has always been.
A worked example
Picture a 35-person Series A product company that gave its four senior engineers access to an agentic coding tool at the start of a quarter, with no other change to how pull requests get assigned or reviewed. For the first three weeks, the roadmap looks ahead of schedule: more branches open, more PRs merged, a burndown chart the team is proud to show in the Monday standup. By week five, one senior engineer, the fastest reviewer on the team and therefore the default approver for anything urgent, is spending most mornings clearing a review queue instead of writing the two features that were the actual reason they were hired. Nothing about the agent's output was defective enough to reject outright. It was defective enough, often enough, that skimming it wasn't safe, and skimming was the only way the queue was going to move at the old headcount.
What actually closes the gap
Assigning review capacity as its own staffing line, rather than an assumed byproduct of the coding-agent subscription, is the fix GitHub's own data points toward: someone whose job explicitly includes reading what an agent wrote, at a volume that used to require several extra authors and now only requires one senior reviewer with real time budgeted for it. Bringing in a senior engineer through staff augmentation, specifically to absorb that queue while the existing team keeps shipping the roadmap, is a strong fit for exactly this shape of gap, the same one our piece on GitClear's 2026 maintainability data found showing up as disappearing refactoring rather than a review backlog. It's a weaker fit if the real problem is a policy nobody has written: what an agent is allowed to auto-merge without a human reading it first, and how large a pull request it's allowed to open before size alone should trigger a second look. Those are calls only your own engineering leadership can make, the same distinction JetBrains' latest adoption numbers make relevant, since the specific tool your team standardizes on changes what that policy needs to say.
If your team's velocity chart looks better than it did in January and nobody has checked how long a pull request now sits before someone actually reads it, that's worth finding out before it becomes a missed release instead of a metric. Our Silicon Valley team can look at where your own review queue sits against the volume your engineers are now authoring, and tell us what you're building if a senior engineer dedicated to closing that gap, rather than opening another one, is the shape of help that fits.
Sources
- GitHub: Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1 (published October 28, 2025, updated February 28, 2026; measurement window September 1, 2024 through August 31, 2025)
- GitHub: What to expect for open source in 2026 by Dylan Birtolo (published February 18, 2026)