At some point in early 2026, GitHub crossed a line.
More than half of all code committed to the platform — the largest code repository in human history, hosting roughly 420 million repositories — was written, or substantially written, by AI.
There was no announcement. No milestone tweet. No confetti. The GitHub blog did not publish "WE DID IT: AI Writes More Code Than Humans Now 🎉." We just crossed it, quietly, like passing a mile marker on the highway at 2am. And then everyone kept driving.
That silence is, honestly, the most interesting part.
The Number You're Not Sitting With
Let's do this properly. In 2023, GitHub reported that Copilot was writing 46% of code in Copilot-enabled projects. Note the qualifier — that was only for users who had Copilot turned on, in repos where it was active.
In early 2026, the number is 51%, and it's across the entire platform.
Two years. We went from "developers who opted in to AI assistance wrote nearly half their code with AI" to "the majority of all commits on the world's largest code host have AI fingerprints." That's not a trend line. That's a phase transition.
84% of developers are now using AI coding tools. The remaining 16% are not purists on principle — they're just swimming against a current that gets stronger every quarter.
The Question Nobody Is Asking Out Loud
I want to ask the uncomfortable thing, and I'm going to ask it without a PR-friendly hedge around it.
What happens to the open source ecosystem when most of the code wasn't fully understood by the person who committed it?
That's not doom-saying. The productivity gains from AI-assisted development are real and significant — solo developers are shipping applications that would have taken a team, enterprise orgs are cutting development cycles in half. I'm not arguing against any of that.
But there's a different question underneath the productivity story. When you write code, even mediocre code, you have a mental model of what it does. You know why you made the tradeoffs you made. You could, if pressed, defend any line in a code review.
When an AI writes code and you review it, you have a partial mental model. You know what it's supposed to do. You checked that the output looks reasonable. But the reasoning path — why it chose that algorithm, why it structured the data that way, what edge cases it quietly ignored — lives in a model you can't inspect. And the deeper problem: CodeRabbit analysis found that AI co-authored code has 1.7x more "major" issues and a 2.74x higher security vulnerability rate than human-authored code. The code looks fine. It often isn't.
The Provenance Loop Nobody Has Clean Answers For
Here's the part that gives me a low-grade headache when I think about it too long.
AI models were trained on GitHub code. That trained model now writes GitHub code. The new code goes back into GitHub. Future models train on that code — including the AI-written stuff. The output trains the input. We've entered a provenance loop, and nobody in a position of authority has published a clean answer for what that does to software quality over a multi-year horizon.
There are also open legal questions that haven't been resolved. When AI-generated code gets committed under an open source license, who owns it? When a model trained on GPL code generates code that ends up in a commercial product, what are the obligations? Courts are still working through the basics. The code is outpacing the law by a comfortable margin.
I'm not saying the sky is falling. I'm saying these are real questions, we're running the experiment live on the world's software infrastructure, and the celebratory takes about productivity gains tend to skip right past them.
What This Changes About How You Review Code
The practical implication that actually matters day-to-day: code review has to change.
The traditional model of code review is that a human reads another human's code and checks for mistakes the author might have missed. The reviewer's mental model is calibrated to human error patterns — missing a null check, forgetting to handle an edge case, a logic bug in a conditional.
AI error patterns are different. AI code looks correct. It often is correct for the happy path. The failures tend to be in places where the model had to make an assumption about your system's context — something it couldn't know from the code alone. Silent failures. Wrong library versions. Hallucinated function signatures that compile but don't do what you think.
Reviewing AI-generated code means asking different questions than reviewing human-written code. Not "did the author make a mistake here" but "what would the model have had to assume to produce this, and is that assumption valid in our system?"
That is a non-trivial cognitive shift. Most engineering teams haven't made it yet.
The Productive Way to Think About This
Here's what I'd actually do with this information:
- Treat AI output like code from a very fast, very confident junior dev who knows general patterns but not your system. They'll get 80% right. The 20% they get wrong will look plausible. Review accordingly.
- Audit your highest-risk code for AI fingerprints. Security-critical paths, payment handling, auth logic — if AI touched it, it needs a human who actually understands the domain, not just a reviewer checking syntax.
- Build your team's review instincts for AI patterns. What does a hallucinated dependency look like? What does an AI-generated auth flow miss that a human would have caught? These are learnable patterns. Teach them explicitly.
- Stop treating AI adoption as binary. "We use AI tools" isn't a policy. Knowing where you use them, how output gets verified, and who's accountable for what ships — that's a policy. At some point in early 2026, we crossed the majority threshold for AI-written code on GitHub. No announcement, no confetti, no retrospective.
The least we can do is notice.