Sign in Subscribe
10 min read

Public Code Pushes on GitHub Grew 78% in a Year

Vibe coding
Agentic Engineering - Photo by Daniil Komov / Unsplash

July 2026

GitHub's own data shows public code pushes growing 78 per cent in the year to March 2026, after four years of decline in the growth rate. What that means for the code reaching production is a harder question, and less well evidenced than the confident numbers being quoted about it.

Eighty per cent of new developers on GitHub use Copilot within their first week. No one reports what share of them run any security check at all.

The first half of that is measurable and I have measured it. Public code pushes to GitHub grew 78.4 per cent in the year to March 2026, against 6.6 per cent two years earlier. The second half, what happens to that code before it reaches production, is not something anyone appears to be measuring.

The capability side of this has been covered well. Models got better at building things, the barrier to shipping fell, and more people started shipping. What follows is what that did to the volume.

The figures come from the GitHub Innovation Graph, GitHub's own quarterly dataset of public activity, published under CC0. The data version, the hashes and the code producing every number are published, so this can be checked rather than taken on trust. It shows volume. It does not say whether the code was written by a person or generated by a model.

What happened to software production between 2024 and 2026

Growth in public code pushes bottomed out at 6.6 per cent year on year in early 2024 and reached 78.4 per cent by the first quarter of 2026. Volume more than doubled in two years after four years of near-stagnation.

Developer accounts moved the same way. Growth had decayed steadily from 33.7 per cent in 2021 to a trough of 20.3 per cent in early 2025, then reversed to 30.6 per cent. Quarterly inflow went from roughly 4.4 million new accounts through 2021 to 15.7 million in the first quarter of 2026. A maturing platform's growth rate does not normally reverse.

Organisation counts have grown between 16 and 20 per cent a year since 2022 with no comparable acceleration. The surge is in individual accounts and in activity.

Testing whether the growth is real

GitHub made Copilot free in December 2024 and attributes a step-change in sign-ups to it. If millions registered accounts to get a free tool and never built anything, the totals rise and nothing has happened.

Public pushes per developer account fell for four years, from 1.87 in early 2020 to a trough of 1.18 in late 2024, then reversed to 1.73, its highest in five years. Dormant sign-ups would have pushed that ratio further down, and the denominator counts every private-only and inactive account GitHub holds.

Repositories per developer fell over the same period, from 2.68 to 2.21. Fewer new projects per account, more work going into the existing ones.

The limits of this measurement

The data covers public repositories only. GitHub puts private repositories at 81.5 per cent of all contributions, growing faster than public ones. These figures describe the other fifth.

The figures are a floor, because GitHub excludes accounts whose volume exceeds what can reasonably be attributed to a person, and agentic tools push under their operator's account at exactly such volumes.

GitHub is not the population. Replit, Lovable, Bolt and their equivalents let people ship without touching a git host, and their users skew towards the newcomers this argument is about. That makes these figures an undercount.

Nothing in the data distinguishes code written by a person from code generated by a model.

One check is available. Over the window GitHub's own Octoverse covers, my aggregation gives public push growth of 24.7 per cent against their published 26.4 per cent.

What could explain an increase this size

More people alone does not account for it, because pushes per account rose at the same time.

Agentic tools pushing under human accounts would, and there is no direct evidence for it. Cherny, who built Claude Code, wrote in January 2026 that "pretty much 100%" of their code is now written by it. Running several agents in parallel means one account producing several commit streams at once, which would raise pushes per account as observed. That is consistent with the data. It is not evidence for it.

A push is an upload event, not a quantity of code, and GitHub's datasheet is explicit that one push may carry many commits. If agentic workflows push more often with less code each time, 78 per cent more pushes does not mean 78 per cent more code.

I cannot close that from public data. The figure counts upload events, and the volume of code behind them is not published anywhere. Anyone who owns a repository has the data and can check for themselves.

What has been published, and how it was measured

Because the dataset cannot tell a person's code from a model's, I cannot test the link between AI and the volume. What has been published instead:

Claim Source Method
20% to 30% of the code in Microsoft's repositories is written by software Nadella, LlamaCon, April 2025 None stated
More than 30% of Google's new code is AI-generated Pichai, Alphabet earnings call, April 2025 None stated
4% of public GitHub commits are authored by Claude Code SemiAnalysis, February 2026 None stated
Its best developers have not written code since December Spotify, via TechCrunch, February 2026 None stated
275 million commits a week Daigle, GitHub COO, April 2026 Scope not stated

They all point the same way. None explains how the figure was produced, so none can be checked or set against the others. Daigle's figure does not say whether it counts private repositories.

What happens to the code after it is pushed

Over Octoverse's reporting year, pushes rose 26.4 per cent and pull requests created rose 20.3 per cent, while comments on issues and pull requests rose 0.35 per cent. Normalised for the growth in things to comment on, commentary per unit of proposed work fell about 15 per cent. That last figure is my calculation from GitHub's published numbers.

Flat commentary does not prove less review. Copilot code review reached general availability in April 2025, so review may have moved to a surface that produces no human comments. I think that is what happened. Review is increasingly performed by the same class of system that wrote the code. I have run several reviewers against one codebase and they are all the same model from different angles. That layer has its own failure modes. On 4 June 2026 Copilot code review failed on an average of 81.6 per cent of requests, peaking at 93.9 per cent, roughly 36,800 reviews in eighty-five minutes. GitHub's own account of the cause is worth reading twice: the review workflow automatically consumed the latest release of a dependency, without compatibility validation, and the new version broke it. The thing checking the code was taken down by an unchecked dependency.

GitHub has named the strain itself. Its Director of Open Source Programs called the contribution surge an Eternal September of open source in February 2026, and the platform's response was to ship maintainers a way to cap the number of open pull requests on a repository.

Broken Access Control overtook Injection as the most common CodeQL alert, flagged in more than 151,000 repositories and up 172 per cent year on year, now leading in Python, Go, Java and C++. GitHub attributes much of it to misconfigured CI/CD permissions and to AI-generated scaffolds that skip authorisation checks. GitHub supplies a caveat with it. New CodeQL coverage for GitHub Actions surfaced misconfigurations that were not previously being detected, so part of the rise is detection rather than incidence.

That defect has a shape Karpathy has a name for. Jagged intelligence is his term for a model that can refactor a hundred-thousand-line codebase or find a zero-day, then fail at something basic. Code that is competent everywhere except the authorisation check is exactly that shape, and it is why he argues the human has to stay in the loop.

Those figures are GitHub's own. The Innovation Graph data can be downloaded and recomputed by anyone.

The gaps in the public record

No published measure exists of:

  • the share of code written by AI, with a stated method
  • defect density in generated code against hand-written code
  • whether the newcomer population ships to production or is still learning
  • what happens inside the 81.5 per cent of contributions that are private
  • package publication volume, where the supply chain surface scales with the same growth
  • what security tooling any of these developers run

Most of these are answerable inside a single organisation, against its own repositories and pipeline. None is answerable across the industry that I could find.

What I think is happening

Of the millions of new developers now pushing code through AI agents, we do not know what security tooling they run, if any. We know precisely how fast the generating tool reaches them. There is no equivalent figure anywhere for the checking tool.

The frontier has already worked this out in public. In February 2025 Karpathy coined vibe coding, describing a practice where he accepted every suggestion, stopped reading the diffs and let the code grow beyond his own comprehension. The term spread widely, and the practice it described is close to the one the people arriving now have picked up.

One year later he set a second term against it, and the distinction he draws is the whole argument. Vibe coding raises the floor, letting almost anyone build software by describing what they want. Agentic engineering raises the ceiling, and he defines it as the professional discipline of coordinating fallible agents while preserving correctness, security, taste and maintainability. On the security half he is blunt: you are not allowed to introduce vulnerabilities because of vibe coding, and you are still responsible for your software. In his own write-up of that talk he sets out what the agentic engineer does instead of blindly accepting generated code:

  • Design specs
  • Supervise plans
  • Inspect diffs
  • Write tests
  • Create evaluation loops
  • Manage permissions
  • Isolate worktrees
  • Preserve quality

Three of those eight are security work.

Inspecting diffs reverses the original definition exactly. Vibe coding was accept all and stop reading the diffs.

Managing permissions means two different things. The first is permissions in the code the agent writes, which is the Broken Access Control problem. The second is permissions of the agent itself, what it may read, reach and execute, which is why every major platform vendor has been building a control plane through 2026. Simon Willison's lethal trifecta names the combination to avoid: private data, untrusted content and external communication. That applies to the agent and the environment it runs in rather than to the code it produces, and the risks it governs include a skill turning hostile inside an agent that already holds the access.

Isolating worktrees is the third, and it is containment: keeping what an agent can touch inside a boundary it cannot cross.

Karpathy's list names all of it.

Jeff Gothelf read the same list and translated it into product management. The mapping mostly holds, and fails on the three that carry security. Diff inspection read as outcome verification will not find a missing authorisation check, because the endpoint returns what was asked for. Managing permissions read as stakeholder alignment is not about who can call that endpoint, or what the agent can reach. Isolating worktrees has no product-management equivalent at all. Code that returns the right answer and never checks who asked passes every product-shaped version of those checks.

His view is that the ceiling for this is very high, and that the old ten-times-engineer idea understates how far ahead people who master it will get. So the floor and the ceiling are moving apart, not together. Vibe coding had a year to spread. Agentic engineering was named in February.

The ceiling is not the unknown here. Karpathy has described the discipline and named what it involves. What nobody has worked out is how any of it reaches the 15.7 million accounts that joined in the first quarter of 2026 alone.

That is the problem to solve: application security and integrity at a scale nobody has run before.

What closes the gap is checks that run without being asked for, sitting in the toolchain from the editor through to the pipeline that builds and tests what ships. Authorisation on the endpoint. Least privilege on the agent. Inventory of what exists. None of those is new. Security pointed the same controls at users, then at devices, and agents are the third turn of it.

What is new is models built to find and repair application flaws, and that work is early. None of it depends on the person who shipped the code knowing the check is there. It needs to be running by default from the first week the account exists, because that is when the code starts arriving.

Subscribe for Updates

References:

Primary data

GitHub

Named sources

Published by:

Shakel Ahmed

Member discussion