What GitHub's Octoverse 2026 Can—and Cannot—Prove About Agentic Engineering

GitHub's Octoverse figures show a sharp rise in software activity: 220 million merged pull requests per month, 7.38 billion commits per month, and 30.3 million new repositories per month in 2026. They do not show how much coding agents contributed to that growth, or whether engineering teams got better results because of them. ¹

That distinction matters for anyone deciding whether to expand agent use. The numbers justify a closer look. They don't make the business case for you.

What did GitHub Octoverse 2026 actually measure?

At GitHub Universe on October 28, 2026, GitHub EVP Jay Parikh presented that year's Octoverse figures: merged pull requests tripled in less than a year to 220 million a month, commits more than tripled to 7.38 billion a month, and the new-repository rate doubled that year to 30.3 million a month. ¹

These are activity counts on GitHub's platform. They don't measure how many coding-agent sessions ran, how much work agents completed, or what share of the activity involved agents. GitHub described the growth as evidence of agentic engineering's impact, but the account provides no method for attributing the increase to agents specifically. ¹

Before a board relies on these numbers, it should ask:

• What time window does “the Octoverse year” cover?
• What were the baseline counts before the reported tripling and doubling?
• Do the headline counts include private repositories?
• How were the three headline metrics calculated and checked?

The available account doesn't answer these questions. ¹

The report's other methodology notes don't close that gap. Country rankings summed pushes to public repositories across the Octoverse year and used profile information to determine location. To adjust for bias from VPN usage, an LLM classified user profiles to extract country codes. ¹ Industry categories were assigned to public repositories created from 2022 to 2026 using a fine-tuned multilingual embedding model and samples from each year. ¹ Both methods are specific and documented. Neither tells you how agent involvement was measured in the three headline totals.

Do higher commit and pull-request counts show coding agent productivity?

Not on their own. More commits, pull requests, and repositories show increased activity—not that delivery got faster, quality improved, reliability held, or costs fell. ¹

Analysis: Activity counts measure volume, not outcomes. A team producing more pull requests still needs to know cycle time to production, how much rework and review each change demands, and whether the pace is creating operational risk. The Octoverse account doesn't answer those questions for companies running coding agents. For a related discussion of why more generated code doesn't automatically mean more finished work, see More AI-Generated Code, No Matching Increase in Completed Work.

The timing is suggestive, not proof. Most of the commit growth landed in the second half of 2026, according to the report. ¹ That's worth lining up against your own agent-adoption timeline. It isn't a causal test: the account describes no control group or method for separating agent-driven activity from other changes in GitHub usage. ¹

Analysis: Treat commits and pull requests as a signal to investigate, not proof of productivity. Rising activity is consistent with faster delivery. It's also consistent with more churn, automated noise, or rework; the account doesn't establish which explanation applies.

How strong is the evidence for agentic engineering adoption at companies?

Platform-wide activity on GitHub is not the same as adoption at your company. The account doesn't say whether the headline figures include private repositories, how representative they are of enterprise teams, or what share of the activity involved coding agents. ¹

The public-repository methods answer narrower questions. Country rankings rely on pushes to public repositories and profile location. Industry categories come from classifying public-repository information. ¹ Those methods can describe parts of GitHub's public activity, but they don't tell a CTO how many engineers at a particular company use coding agents, on what tasks, or with what results.

The same limit applies to the report's count of repositories related to interoperability or reverse engineering. The stated method counts public repositories created each year when their names, descriptions, topics, or READMEs mention those areas or related terms, such as clean-room implementations, drop-in replacements, or protocol re-implementations. ¹ That is a text-based counting method, not a measure of agent use or engineering outcomes.

Analysis: Before treating platform-wide activity as evidence of enterprise adoption, ask for a precise definition of agent use, the population the data covers, a baseline for comparison, and outcome measures. Without them, the report shows a change in software activity but leaves the company-level decision unanswered.

What can leaders reasonably infer from the report?

The defensible reading: GitHub reported a sharp rise in development activity during 2026 and linked that rise, in its presentation, to agentic engineering. ¹ That's reason enough to investigate whether coding agents are changing how your teams work. It is not evidence that agents caused the reported growth.

The figures do not show teams delivering faster, software getting more reliable, or engineering costs dropping. The headline numbers are activity counts; the available account reports no results for those outcomes. ¹

Analysis: The report can justify funding a controlled test—it flags a shift worth examining. It can't justify an unconditional rollout on the claim that agents have already proven their value. Expanding access without team-level evidence risks adding activity without knowing whether cycle time, quality, reliability, or cost changed.

This is a call about evidence, not a verdict on agents. The report's limits mean one thing: build your own numbers instead of borrowing a platform-wide trend to stand in for them.

What should an engineering team measure before expanding coding-agent use?

Start by defining the intervention: which teams use agents, for which tasks, at what level of autonomy, and over what period. That lets you distinguish agent-assisted work from other work—a distinction the Octoverse account doesn't make. ¹

Then track outcomes next to activity:

• Time from work start to merge, and time spent in review.
• Rework: changes that need substantial correction after the fact.
• Change failures, incidents, and rollbacks.
• Engineering effort per accepted change.
• Commits and pull requests—read as activity, not as proof of productivity.

These are measures to collect yourself. The Octoverse account doesn't show whether its activity increases moved delivery speed, quality, reliability, or cost in either direction. ¹

Set a baseline and a comparison: before-and-after on your own teams, or teams that adopt at different times. Track changes in work type, staffing, repository mix, and release policy alongside the comparison, so you don't credit the agent with every shift in the numbers. The report provides none of these controls; this is a design you build yourself. ¹

Analysis: Attributing agent use to teams and tasks is easier when model traffic runs through one place. An enterprise AI gateway with usage analytics, budgets, and audit logs is one way to get that record across providers, though the outcome measures above still have to come from your own delivery data.

Decide the threshold before you see the results: what improvement in delivery, quality, reliability, or cost would justify expanding, and what risk would make the result unacceptable regardless. The threshold should come from your own priorities; the report doesn't supply one. ¹

What evidence should a board request before approving a rollout?

Ask for the definitions behind the headline figures: the Octoverse time window, baseline counts, repository scope, treatment of private repositories, and how each reported increase was calculated. ¹ Ask separately how GitHub defined agentic engineering, how it identified agent use, and what share of the measured activity involved agents. The available account doesn't provide that information. ¹

Then ask for outcomes: delivery speed, defect and reliability measures, review burden, and cost. The activity counts don't establish whether any of these changed. ¹ The same discipline applies to any specific agent product you evaluate; GPT-6.1 Sol in CodeRabbit's Security Agent: What Buyers Need to Verify is one example of that kind of checklist.

Approve a staged evaluation with a named owner, a baseline, and a scheduled review—not a rollout justified by GitHub-wide growth. Have engineering leadership report the results alongside the limits of the comparison. Expand only when your own evidence clears the threshold you set before measuring.

Frequently asked questions

What did GitHub's Octoverse 2026 report say about agentic engineering?

It reported 220 million merged pull requests per month, 7.38 billion commits per month, and 30.3 million new repositories per month, presenting the growth as an indication of agentic engineering's impact. ¹

Did GitHub prove that coding agents caused the growth?

No. The supplied source says the report did not explain how much of the change was caused by coding agents or provide a method for attributing the figures to them. ¹

Do the Octoverse figures show that coding agents improved productivity?

Not by themselves. The source reports activity volumes but does not show changes in delivery speed, software quality, reliability, or engineering cost. ¹

Are the figures representative of enterprise engineering teams?

That is not established in the supplied source. It raises questions about private-repository coverage and representativeness; its detailed methodology includes public-repository rankings and classifications, but does not resolve the enterprise question. ¹

What should companies measure before expanding coding-agent use?

They should define agent use, establish a baseline, compare adoption periods or teams, and measure delivery speed, rework, quality, reliability, and cost alongside commits and pull requests. These are recommended evaluation measures because the report does not provide them. ¹

Source

¹ Simon Willison, “GitHub Octoverse 2026,” October 28, 2026. https://simonwillison.net/2026/Oct/28/github-octoverse-2026/