Here is the paradox in one sentence: more developers than ever are using AI to write code, and fewer of them than last year actually trust what it produces. That isn't a contradiction born of bad survey design. It's what happens when a tool becomes indispensable before it becomes reliable.
Most explanations of AI coding tools assume trust and adoption move together: people use what they trust, and stop using what they don't. The 2025 data breaks that assumption cleanly in half.
What the numbers actually say
Stack Overflow's 2025 Developer Survey is the clearest single data point on this. According to Stack Overflow's 2025 Developer Survey, 84% of developers now use or plan to use AI tools, up from 76% the year before. That's the adoption side of the story, and it's the one most coverage stops at.
Read those two numbers side by side and the shape of the paradox is obvious. Trust fell by 11 percentage points in a single year, exactly as usage climbed. Whatever is driving adoption, it isn't confidence in the output.
GitHub's own numbers support the adoption half of this. GitHub's Octoverse 2025 report recorded 180 million developers on the platform, with 80% of new developers using GitHub Copilot within their first week, and AI-tagged repositories nearly doubling to 4.3 million over the year. Copilot, or something like it, is now close to a default rather than a choice.
The part that makes this a paradox, not just a trend
If it stopped there, this would be a simple story: developers use a tool they don't fully trust because it saves time, and they compensate by checking its work more carefully. That's a rational trade-off, not a paradox. The paradox appears once you look at how developers rate their own use of the tool, rather than the tool in the abstract.
Reporting on Snyk's AI code security research found that 75.8% of developers believe AI-generated code is more secure than human-written code. That's not a modest edge in confidence. Three in four developers think the machine's output is safer than their own team's, in direct tension with the 29% who say they trust AI output's accuracy in general terms. The same research found more than 56% of those developers separately admitted that AI-generated code had, in their own experience, sometimes or frequently introduced security issues, and roughly 80% admitted bypassing security policy at least occasionally when working with AI-generated code.
That's the actual contradiction: distrust of AI code as a category, alongside confidence in the specific AI code sitting in front of them right now. People don't evaluate "AI output" as an abstract concept when they're staring at a pull request that compiles and passes the tests they thought to write. They evaluate the thing in front of them, and the thing in front of them looks fine, because looking fine is exactly what AI-generated code is good at.
Why looking fine isn't the same as being fine
This gap between perceived and actual security isn't a new discovery specific to 2025 tooling. Stanford researchers Neil Perry, Megha Srivastava, Deepak Kumar and Dan Boneh documented the same effect years earlier in a controlled study, "Do Users Write More Insecure Code with AI Assistants?" Participants with access to an AI coding assistant wrote less secure code than a control group without one, on four of five programming tasks. At the same time, those same participants were more likely to believe their code was secure than the control group was.
Participants who had access to an AI assistant were more likely to believe they had written secure code than those without access to one, even though their code was measurably less secure. Perry, Srivastava, Kumar & Boneh, Stanford, arXiv:2211.03622
That's the mechanism behind the paradox, not just a description of it. AI-generated code doesn't just introduce vulnerabilities; it introduces a specific, measurable overconfidence in the person reviewing it. You can't self-correct for a blind spot you don't know you have, and the Stanford result suggests using the assistant actively deepens the blind spot rather than merely coexisting with it.
Put the three data points together and the pattern resolves. Developers distrust "AI code" as an abstract category (Stack Overflow), because they've seen or heard about it going wrong somewhere. But they trust the specific code an assistant just handed them (Snyk), because it's fluent, plausible and passes the checks they thought to run. And the reason it passes those checks isn't that it's actually secure: it's that the tool that wrote it also biased the reviewer, however experienced, toward believing it's fine (Stanford). Rising adoption and falling trust aren't contradictory. They're two symptoms of the same underlying problem: nobody involved has a reliable way to tell good AI-generated code from bad AI-generated code by looking at it.
The fix isn't more scepticism. It's a second set of eyes that isn't guessing.
An engineer reviewing your repository against known failure patterns, not just reading it and hoping it looks right, is what closes the gap between "this feels secure" and "this is secure."
See how engineer review works →Do developers trust AI-generated code?
Not especially, and less than they used to. Stack Overflow's 2025 Developer Survey found only 29% of developers trust AI output to be accurate, down from 40% in 2024, even as 84% now use AI tools regularly.
Why do developers keep using AI tools they don't trust?
Because distrust of AI code as a general category doesn't stop someone from trusting the specific output they're looking at right now. Research on AI code security found 75.8% of developers believe AI-generated code is more secure than human-written code, even while expressing broader distrust of AI accuracy in surveys.
Does using an AI coding assistant make developers overconfident?
Yes, according to controlled research. A Stanford study found developers using an AI assistant wrote less secure code on four of five tasks than a control group, while being more likely to believe their code was secure than that same control group.