Microsoft published its Global AI Diffusion Report on May 7th and led with a striking number: git pushes increased 78% year-over-year globally. The report frames this as evidence that AI is deepening developer productivity. It is not. It is evidence that the measurement has broken.
GitHub COO Kyle Daigle confirmed in April that the platform now processes 275 million commits per week from AI agents, on pace for 14 billion agent commits in 2026. AI agents opened 17 million pull requests in March alone — up from 4 million six months prior. GitHub logged five infrastructure incidents in the first two days of April from the load. The servers are straining not because developers got dramatically more productive, but because a new class of non-human committer showed up at scale and is running continuously, without business hours, across thousands of repositories simultaneously.
When you cite a 78% increase in git pushes as a developer productivity metric in that environment, you are mostly measuring agents.
The Commit Count Problem, Again
Version control activity became a developer productivity proxy by accident. Nobody decided commits were a good measure of output. They became a proxy because they were cheap to measure, correlated with actual work during a period when humans were the only things making commits, and visible in dashboards without any additional instrumentation.
That proxy worked well enough until it broke. It broke the first time when commit count became an explicit KPI and developers optimized for it — committing smaller chunks more frequently, splitting work across branches, preserving meaningful units of code into five tiny commits to hit a number. This didn't make the work worse necessarily, but it made the metric noisier. You could no longer look at commit frequency and confidently infer anything about actual output.
The proxy is breaking a second time now, and the mechanism is different. It is not developers gaming the metric. It is agents making the metric irrelevant. When 275 million commits per week are coming from non-human actors, and that number is growing at a pace that strains GitHub's infrastructure, "commits per developer" is no longer measuring what it was designed to measure. The denominator (developers) is growing slowly. The numerator (commits) is growing at machine speed. The ratio has stopped being a signal.
What Activity Is Not Output
There is a version of the Microsoft finding that is worth taking seriously. Git pushes are up 78%. New repositories are up 45%. Developer employment in the US reached 2.2 million in 2025, up 8.5% year-over-year, a record high. These are real numbers and they collectively suggest something: software demand proved elastic. When AI made building cheaper, organizations didn't build the same amount of software with fewer people — they expanded what they built. That's an interesting economic result.
But "software demand expanded" is different from "developers are 78% more productive." The activity increase is real. Attributing it specifically to human developer productivity is the mistake.
Consider what an AI agent's relationship to GitHub looks like in practice. An agent clones a repository, makes a series of commits across a branch, opens a PR, runs CI, iterates based on failures, and pushes again — all without a human touching the keyboard. That workflow can generate dozens of commits and multiple PRs in the time it takes a developer to context-switch once. The agent does not stop at 6 PM. It does not get interrupted by Slack. It does not spend 30 minutes recovering focus after a meeting.
From GitHub's perspective, this looks like an explosion in developer activity. From the perspective of what the human developer on the other end is actually producing, the relationship is much more complicated. They may be reviewing agent output, redirecting it, catching its mistakes, accepting its PRs with revisions. That is real work, and it produces real value. But it is fundamentally different from the work that generated the commits, and measuring it by the commit count is measuring the wrong actor.
The Proxy Breaks When the Composition Changes
Measurement proxies degrade in predictable ways. The underlying signal (human developer output) becomes increasingly decoupled from the surface measure (commits, pushes, PRs) as the composition of who or what creates those measures shifts.
We saw this with lines of code. For decades, LOC was a plausible coarse proxy for software development activity. It broke when higher-level languages meant the same functional output required 10x fewer lines, when generated code started inflating it artificially, and when minification, transpilation, and code generation pipelines meant the relationship between LOC and human labor became non-linear and context-dependent. The number was still real. What it measured had changed.
Git activity is going through the same transition faster. The composition of GitHub commits in 2023 was overwhelmingly human. In 2026, a meaningful and growing fraction — perhaps a majority by some counts — originates with AI agents running autonomously or semi-autonomously. When the report that cites 78% push growth is published by the company that owns GitHub and sells the AI tools generating those pushes, attributing that growth cleanly to developer productivity is not a neutral analytical act.
The Measurement Problem This Creates
For teams trying to understand whether their developers are actually more productive with AI, version control data has become significantly harder to interpret as a standalone signal. This was already true before the agent flood — the Faros.ai research tracking 22,000 developers found that high-AI-adoption teams merged 98% more pull requests but saw PR review time increase 91% and bugs increase 9% per developer, with no significant correlation between AI adoption and company-level delivery improvements. More PRs, more bugs, slower review, flat business outcomes.
Add agents as direct committers and the interpretation problem compounds. You are now trying to subtract out agent-originated commits, weight human-originated commits by review quality, account for the time developers spent reviewing agent output rather than writing code themselves, and make sense of PR volume that mixes human work, agent work, and human-reviewed agent work in proportions that vary by team and workflow.
This is not impossible, but it requires instrumentation that most teams do not have. Version control data alone cannot tell you how much human time went into a merged PR, whether the PR originated with a human or an agent, or whether the code in it will require rework in two weeks. Those answers live elsewhere.
What Would Actually Measure Developer Productivity
The instrumentation that survives the agent era is session-level human time data. Not "what was committed" but "how long did a developer spend in active focused work, on what tools, and what did that work produce."
This means tracking what developers are actually doing at the system level — active application time, editor sessions, coding focus blocks — and correlating it with output signals like PR cycle time, post-merge bug rate, and closed ticket throughput. The correlation between session data and output gives you something that commit frequency cannot: a ratio of human effort to durable output that does not get contaminated when agents start generating commits autonomously.
This is harder to instrument than counting pushes. GitHub's API will not tell you how long a developer spent in focused flow before making a commit, or how many times they were interrupted by agent review requests during that session. That data lives in the developer's actual workflow — the apps they switched between, the editor time that preceded the push, the review sessions that followed it.
The 78% push increase is a real number. It tells you that GitHub is processing dramatically more code. It does not tell you that the developers behind those repositories are working more effectively, shipping more reliably, or experiencing less friction in their day-to-day work. Those questions require different data — and that data is not getting easier to find in version control.
The Version Control Metrics Era Is Ending
Commit count, PR throughput, repository creation rate: these were the metrics of an era when the only things making commits were developers. That era is over. It ended gradually and then, in Q1 2026, very quickly.
Microsoft's 78% push increase will get cited in productivity decks for the next year. It will look like evidence that AI is working. What it actually shows is that version control metrics have crossed the threshold where they measure platform activity more reliably than they measure developer effectiveness — and that the gap between those two things is now large enough to matter.
The hard work of measuring developer productivity just got harder. The easy metrics broke. The data that would replace them requires instrumentation most teams haven't built, tracking human session activity rather than repository events, and correlating it with outcome signals rather than activity signals. That work is not optional. If you're managing developers and you're still reading commit counts, you're reading GitHub's load graph and calling it a performance review.