AI Now Writes 75% of Google's New Code. 46% of Developers Don't Trust the Output. Nobody Wants to Talk About the Second Number.
Somewhere around 2024, "AI will replace programmers" stopped being a prediction and became a hiring plan. I keep meeting engineering leaders who say a version of the same sentence: the code is solved, so what am I paying humans for?
Then I ask one follow-up question: what happened to your churn?
That's when the room goes quiet, because the industry's own numbers tell a story the replacement narrative can't survive. Google has been its own receipt: more than 30 percent of its new code was machine-written by spring 2025, and by spring 2026 the company put the share at 75 percent. The measurement work that tracked the surge also tracked what came with it: GitClear's analysis of 623 million changed lines found duplicated code blocks at a record 73 per million, up 81 percent since 2023, and code churn, meaning lines reverted or substantially rewritten within two weeks of merging, doubled from 3.3 to 7.1 percent. The sentiment went the same direction: Stack Overflow's 2025 developer survey had favorable views of AI tools above 70 percent in 2023 and 2024, down to about 60 percent in 2025, and the share of developers who distrust the accuracy of the output jumped from 31 to 46 percent in a single year. More code, more rework, less trust. That's not a replacement curve. That's a supervision curve.
What's Actually Being Replaced
So let's be precise about what's actually being replaced: undifferentiated code. The CRUD endpoint, the boilerplate, the fifth implementation of retry logic, the code where the requirements are unambiguous and the cost of being wrong is small. AI is genuinely excellent at that layer, better than most skeptics predicted, and the wins are real. Nobody misses writing their fortieth DTO mapper.
But the maintenance numbers are the tell for where the remaining value lives. High-churn code means the expensive part moved downstream of generation: into review, into integration, into understanding what the code does when it's wrong at 3 a.m., and deciding whether it should exist at all. The engineer who could write the endpoint in twenty minutes was never being paid for the typing. The typing was the cheapest part of the job that happened to be visible. What they were paid for, and still are, is everything the typing was attached to: the spec, the tradeoff, the "don't build this here, build it there," and the accountability when a customer calls.
Put bluntly: AI is replacing the part of the job that was already commoditized, and it's revealing how much of the job was never typing in the first place. If your value was undifferentiated code, the warning was never about AI, it was about the word "undifferentiated."
What I Watch for in Strong Teams
Here's what I watch for in strong teams now, and none of it is "writes more code":
- Writing specs that a machine can't misread. The prompt is the new interface contract. Engineers who write precise requirements get dramatically better output than engineers who write hopeful ones.
- Review as a first-class skill. Reading generated code fast and finding the buried assumption is the new writing.
- Owning outcomes, not output. "The model wrote it" is the new "it compiled." It was never a defense for a human, and it isn't one now.
- Taste about what not to generate. The endpoint that shouldn't exist is the cheapest one to maintain.
The Concession
I'll concede the real point inside the fear: the job is changing, headcounts in some layers are genuinely shrinking, and an engineer whose entire value was turning tickets into boilerplate is in real trouble. That's not the same claim as "programmers are over." It's the claim that the role is consolidating around judgment, and the volume-based definition of productivity, lines per day, is finally dead. Good riddance.
The question I'd put to the "replace them all" camp: when the generated code is wrong, and churn says it often is, who is the person that notices? Because if your answer is "the model," you're describing the same self-review echo chamber that fails 64.5 percent of the time without external verification, per the self-correction blind spot study. If your answer is "a human," congratulations, you've just argued for keeping programmers. You just called them something else.
So: has AI replaced part of your job yet, and which part turned out to be the part that mattered?
References
- Pichai on more than 30% of Google's new code being AI-generated (Moneycontrol, April 2025)
- Google says 75% of its new code is AI-generated (Business Insider, April 2026)
- GitClear, The Maintainability Gap: 2026 AI Code Quality Research
- Stack Overflow 2025 Developer Survey, AI section
- Uncovering and Addressing the Self-Correction Blind Spot in LLMs (arXiv 2507.02778)
Top comments (4)
The churn stat is the one that got me, 3.3 to 7.1 percent in two years is brutal. Fast output means fast reverts, and review time never shows up in any of these numbers. Curious what counts as AI-written at Google though, an accepted autocomplete line or a whole feature?
This is from Gemini (I tried asking a Google product)
"Publicly, Google has never broken down the precise telemetry behind how they calculate that "75% of new code is AI-generated." Sundar Pichai and other executives drop the statistic in earnings calls and letters, but the underlying methodology remains an internal black box."
Your question is spot on, from my workplace, we do track (I forget the exact metric) - suggestions shown vs. accepted, we have aggregates at team / org level, week/month. Session data is not available, metric aside, in our case, we are often counting the whole commit as AI written if AI harness signature shows up in the commit message. A PR is entirely AI written if any of the commits has that AI signature. Its not accurate. AI harnesses do not always put signature and Claude will do usually if developer is using Claude for code authoring/assist and also create PR/commit in the same harness. We have not graduated to the point where I can look at a Feature in JIRA, track back to all PRs and calculate what % of the feature was developed using AI. I want to, but I feel its a bit advanced for now.
Curious, how are you seeing this implemented or calculated or reported out in your area?
I think the problem is, we've all been rushing to inject AI everywhere, when AI itself is usually a sub-optimal solution.
Take boilerplate code for instance, sure, you can have AI write it and it will make mistakes and correct them... But you could also build a framework that write that boilerplate perfectly every single time, using code generators, like Roslyn?
Or you can write a Claude.md file and hope it sticks to it, vs explicit gated architecture that prevents it from being non-compliant permanently and explicitly?
If you tell AI 'dont do this' and then you compact the context, it'll have forgotten that... Which means, it'll just do it again... Ok, commit a memory, that it self-references and you bloat your prompts, system instruction is the same bloat. Or, you can simply gate it from ever doing it again at the tool level, now it's impossible for it to be non-compliant?
The fact that 46% dont trust the output, is a result of not knowing what prevents it from writing clean code. AI is trained on datasets, which in turn form parameters and when you ask it to describe an apple, it's answer will be 'the most common description I was trained on for 'describe an apple' is:...' Not, empirical proof, training data frequency. And lets face it, all the code it's been fed had some sort of anti-pattern in it... Which is why AI are rapidly improving, because more people are using it and when those anti-patterns surface, we tell it to correct it, which means 'try the 2nd most frequent match', which helps refine it. But that refinement will never get to 100%, unless you ask it verbatim to write exactly what it was taught, exactly how it was taught it. Which wont happen... So we need quality gating outside of a model, that forces rigid frameworks that prevent errors. Think about writing an endpoint, if 1 in 1000 endpoints AI writes, is off, that's a vulnerability. Vs, if you give it a template for an endpoint and it just feeds it parameters, it's 100% correct every single time (tool calls in essence). Sure it can use the wrong template, but each template is perfect for it's job. That's 1 way to gate quality, by having primitives and letting AI just play lego with them.
There are many ways to gate quality and improve AI outputs, far too many infact to fit into a comment, but you get the idea. Those 46%, are mostly right, but often driven by naivety as opposed to empirical proof. They dont trust, because they dont know, not because they know it's wrong.
All great points. I will TLDR this as - "Grandparents have left the retirement planning to the infant grandchild born this year". We are all hopeful as the astrologer said, this wonderkid will do awesome stuff!
Now get ready for the bumpy ride!