GitHub reports that roughly 51% of the code committed across its platform in early 2026 was AI-generated or substantially assisted. It is a bigger, more sweeping version of the figure I took apart earlier this week, when Airbnb said AI writes 60% of its new code. The Airbnb number was one company’s claim. This one is presented as a fact about software itself. It deserves the same deconstruction, and it fails in the same places.
”Assisted” is doing enormous work
Start with the word, because the word is where the number is made. “AI-generated or substantially assisted” is a category so wide it is hard to land outside it. A tab-completion you accepted is assisted. A function an agent wrote end to end is assisted. A Stack Overflow answer you pasted from a Chat window is assisted. A variable name a model suggested and you kept is assisted. These are not the same act, they do not carry the same risk, and they do not represent the same amount of machine authorship — but they all collapse into the same 51%. A number that counts a kept autocomplete and an autonomously written service as the same event is not measuring what its headline implies. It is measuring contact with an AI tool, which in 2026 is nearly universal, and then presenting that near-universality as a productivity result.
The denominator nobody states
Every claim like this turns on a denominator, and the public version of the 51% almost never gives you one. Fifty-one percent of what? Code committed to public repositories, or all repositories including private? All commits, or commits weighted by line count? Does a generated lockfile count the same as a hand-written algorithm? Are merge commits and vendored dependencies in or out? These are not pedantic questions. The answer moves the number by tens of points, and the fact that the headline travels without the denominator is the tell that the headline is the product and the denominator is the inconvenient detail. I did the same check on the 10x-faster claim and the 60% claim, and the pattern holds: the more impressive the number, the less likely it ships with the definition that would let you evaluate it.
It says nothing about what shipped
Here is the gap that matters most, and it is identical to the one in the 60% piece. The 51% measures code that was written. It says nothing about code that shipped to users and stayed shipped. It does not tell you how much of that AI-assisted code was reverted within a week, how much was rewritten in review, how much shipped a bug that a human then spent two days finding. “Written” is the cheap part of software and always has been. The expensive part is “correct, reviewed, and still standing a month later,” and a percentage of authorship is silent on every word of that. The supervision tax — the human time spent reading, correcting, and occasionally undoing the assisted output — is invisible in the number, which is convenient, because the supervision tax is exactly the cost the number is implicitly claiming to have eliminated.
Who the number is for
Ask who the ambiguity serves and the shape of the number explains itself. A high authorship percentage is useful to a tool vendor selling adoption, to an executive justifying the license spend, and to a platform showing that its bet on AI is paying off. None of those audiences is served by a denominator, because the denominator is where the number gets smaller and more honest. The people the figure does not serve are the engineers who maintain the code it describes — and they are the ones who could actually use a defensible number. A statistic that flatters everyone except the people closest to the work is not a measurement; it is a marketing artifact wearing a measurement’s clothes. The 51% travels precisely because it is large and undefined, and large and undefined is what gets quoted.
What the week has been about
This is the close of an arc, so let me connect it. Parallel agents push the volume of AI-authored code up, because one developer now drives many agents at once. Leaking config shows that the infrastructure underneath that volume is less trustworthy than the volume implies. And the 51% is the topline that sits on top of both, smoothing them into a single triumphant statistic. More code is being generated, the systems generating it are leaking credentials, and the headline metric reports only the first of those facts and frames it as progress. The number is not lying, exactly. It is doing something quieter and more durable: it is answering a question nobody should be asking — how much code did the machine touch — and letting that stand in for the question that matters, which is whether the software is better, safer, and cheaper to own than it was.
The number worth tracking instead
If you run a team and you want a metric that cannot be gamed by counting autocompletes, stop measuring authorship share and start measuring outcomes. Track the proportion of AI-authored pull requests that ship without a revert inside two weeks. Track the change in review time per AI-assisted PR against your pre-AI baseline. Track whether your juniors and your seniors show the same defect rate on assisted code or wildly different ones. Those numbers are harder to collect and far less flattering to put in a keynote, which is precisely why they are the ones worth having — they measure whether the assistance helped, not whether it happened.
