Latest in AI
GitHub Octoverse 2026: AI Agent Adoption and What the Numbers Actually Measure
GitHub reports a sharp increase in development activity, but more commits are not the same thing as more useful software.
GitHub released Octoverse 2026 on October 28, reporting that agents started more than 40% of pull requests in September, up from 17% in March. The report makes AI-assisted development harder to dismiss as an experiment, while leaving an important question open: how much of that activity becomes useful software?
The important Octoverse 2026 numbers
The official report covers October 1, 2025 through September 30, 2026. Unless specified otherwise, its totals include public and private repositories.
| Measure | Reported result |
|---|---|
| Commits during the reporting year | 34.3 billion |
| Merged pull requests during the reporting year | 1.3 billion |
| Developers on GitHub | More than 225 million |
| India developer community | 32 million |
| US developer community | 38.3 million |
GitHub also reports that 61% of Copilot users who explicitly selected models used more than one in September. That denominator excludes automatic model selection. It should not be read as a measure of every developer's model preferences.
Why comparisons with older reports need care
GitHub changed the reporting window and recalculated prior-year figures using the new definitions. Copying a number from the 2025 report and comparing it directly with this year's total can therefore create a misleading growth claim.
Activity is not a productivity experiment. A commit records a change, not whether that change solved a valuable problem. More pull requests can mean more shipped improvements, more exploratory work, or more changes that reviewers need to inspect. Aggregate platform totals cannot tell an individual team which of those explanations applies to it.
That is why these figures are useful for understanding adoption, but insufficient for deciding whether a company's AI spending is paying back. The report is a platform-level observation, not a controlled test of what the same developers would have delivered without agents.
What engineering teams should measure next
A useful internal comparison starts with the outcome the team cares about. For a maintenance team, that might be the time between a confirmed bug and a verified fix. For a product team, it might be whether a requested feature reaches users without creating another support problem.
Then look at where work accumulates. If implementation gets faster while review becomes slower, counting generated changes alone hides the new constraint. The right response may be better tests, smaller changes or clearer acceptance criteria rather than another increase in generation capacity.
There is a distribution implication too. Technical products now need explanations that help people judge a result, not only instructions for producing one. A launch demo can show a successful run. Documentation needs to help a developer recognize an unsuccessful one.
What the report leaves open
GitHub's dataset is valuable because it reflects activity on a major development platform. It still does not represent all software work, and its adoption signals should not be turned into a universal claim about engineering quality or job requirements.
The next useful metric is not simply how much more code agents can produce. It is how reliably teams can turn that larger flow of changes into software they are willing to maintain.
I’m Paras. I work at the intersection of AI, engineering and distribution.
I help technical founders explain what their products change in real developer workflows, through clear technical content and founder-led distribution.