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.

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."

Here's what I watch for in strong teams now, and none of it is "writes more code":

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?