AI Coding Assistants and the Trust Gap

Two numbers that should not both be true

Here is where it gets interesting. Adoption of AI coding tools has never been higher, and trust in what those tools produce has never been lower, at least not since anyone started measuring it carefully. Stack Overflow’s 2025 Developer Survey put usage at 84 percent, up from 76 percent the year before. The same survey put trust in AI accuracy at 29 percent, down from 40 percent the year before. Positive overall favorability toward AI dropped from 72 percent to 60 percent year over year. None of these numbers are close to each other moving in the same direction, and that is the whole point. Developers are not becoming more confident as they use these tools more. They are becoming more fluent at using something they do not fully believe.

The problem runs deeper than a simple honeymoon ending. Experienced developers, the people who have shipped the most production code and presumably know what good output looks like, report the lowest highly trust rate in the whole survey at 2.6 percent, and the highest highly distrust rate at 20 percent. That is not a junior developer problem. It is the opposite. The people with the most reps have the least faith, which suggests the distrust is earned rather than inherited from unfamiliarity.

The almost right problem

Ask developers what actually frustrates them and the answer is rarely a dramatic failure. The top complaint, cited by 45 to 66 percent of respondents depending on which 2026 survey you read, is code that is almost right but not quite. That phrase shows up constantly in this research because it names something specific. A completely wrong answer gets caught immediately. An answer that is 90 percent correct slides past a tired reviewer, compiles, passes a shallow test, and then breaks something three weeks later in a code path nobody thought to check. Developers describe spending more time verifying AI output than they expected to save by generating it in the first place, which is the mechanism behind the trust gap rather than just a symptom of it.

What the security data actually shows

Distrust would be an overreaction if it were just about developer feelings. It is not. The security research backs up the discomfort with numbers that are hard to argue with.

Vulnerabilities baked into the output

The hallucinated package finding deserves a closer look because it created an entirely new attack category. Researchers generated 2.23 million code samples across 16 popular code generating models and found 440,445 of them, 19.7 percent, referenced at least one software package that does not exist. Open source models hallucinated packages at an average rate of 21.7 percent, commercial models at 5.2 percent, and some CodeLlama configurations exceeded 33 percent. An attacker who registers one of these fake but plausible package names under the real name developers keep asking for gets a working piece of malware installed by anyone who trusts the AI’s suggestion. Security researchers named this slopsquatting, a play on the older term typosquatting, and the persistence numbers make it worse than a one time fluke. When researchers reran 500 prompts that had previously hallucinated a package, 43 percent produced the same hallucination in all 10 reruns, and 58 percent produced it in more than one. The AI is not randomly wrong. It is consistently wrong in ways an attacker can predict and exploit.

What is happening to the codebase over time

GitClear’s longitudinal analysis adds a slower moving but arguably more worrying pattern. Comparing code changes from 2020 through the first half of 2026, the share of new code that is copy and pasted rather than reused through a function call climbed from 8.3 percent to 15.7 percent, while the share of code that gets moved or refactored, the sign of someone actually restructuring a codebase rather than just adding to it, fell from roughly 25 percent to 3.8 percent. Cross file function calls, a rough proxy for genuine code reuse, are down 35 percent from recent years. Two week code churn, meaning code that gets rewritten again almost immediately after it was written, is up 15 percent year over year in the 2026 data. None of this means AI written code is useless. Heavy AI users still out produce non users by four to ten times in raw volume. But GitClear’s own analysis found that most of that productivity gap predates AI adoption entirely, and the actual velocity gain for a developer compared to their own past output is closer to 25 percent. The codebase is growing faster and getting less maintainable at the same time, which is exactly the kind of technical debt that does not show up on a burndown chart until it does.

Why the gap keeps widening instead of closing

You might expect model improvements to shrink this gap over time, and to some degree they will. Commercial frontier models hallucinate far fewer packages than open source alternatives, 5.2 percent versus 21.7 percent, and the newest coding focused models post meaningfully better OWASP vulnerability rates than models from even a year earlier. But better models are not the whole fix, because a meaningful share of the gap comes from how teams use the tools rather than from the tools themselves. Verification habits have not kept pace with adoption. Only 48 percent of developers report always checking AI assisted code before committing it, which means more than half the time, code that was flagged by its own creators as almost right rather than fully right goes into a codebase without a human confirming it actually is right. Faster generation without matching verification does not close a trust gap. It just moves the point of failure further downstream, from the editor to code review to production to, eventually, an incident report.

There is also a structural reason distrust keeps pace with capability. As models get better at producing code that looks correct, the failures get harder to catch by eye. Early generation tools produced obviously broken syntax that any compiler caught instantly. Current tools produce code that compiles, passes a shallow test suite, follows house style, and still contains a subtle logic error or an injection flaw that only shows up under a specific input a reviewer did not think to try. Better output quality raises the bar for what counts as a caught mistake, which is part of why the most experienced developers, who have the sharpest sense of what a subtle bug looks like, report the least trust rather than the most.

The honest limitations in this picture

Survey data on trust is self reported, and self reported trust does not always predict behavior. Plenty of developers who say they distrust AI output still ship it without a second review, which is a gap between stated caution and actual practice that the surveys cannot fully capture. The vulnerability rate studies also vary by methodology. The AppSec Santa test used 534 samples across six models, a meaningful sample but small enough that model specific rankings could shift with a different prompt set or a newer model version. The slopsquatting research is the most rigorous study in this piece, with 2.23 million generated samples, but it was conducted in 2024 and presented in 2025, and commercial model hallucination rates have likely improved since then even if the underlying dynamic has not gone away. GitClear’s code quality metrics measure correlation, not proof that AI assistance directly causes the decline in refactoring, since the same period saw broader industry pressure toward shipping speed that would push these numbers in a similar direction independent of AI tools. None of these caveats erase the pattern. They just mean the exact percentages should be read as a snapshot of a fast moving situation rather than a permanent verdict on any specific tool.

Conclusion

The trust gap is not a mystery and it is not going to close itself. Developers are using AI coding assistants at record rates because the tools genuinely save time on the work that used to eat a whole afternoon, and they trust the output less than ever because the failures that do slip through are subtler, more consistent, and more exploitable than the failures of three years ago. Both halves of that sentence are backed by real numbers now, not just anecdotes traded in Slack channels.

The deeper shift is that trust in AI coding tools was never going to be a single number that rises steadily as models improve. It was always going to fork into two separate questions, how good is the average output, and how well equipped is the team receiving that output to catch the exceptions. Model quality is improving on measurable axes, lower hallucination rates in commercial models, better OWASP compliance in newer releases. Team verification practice is not improving at the same pace, which is why the gap between adoption and trust keeps widening rather than narrowing even as the tools themselves get better.

This pattern is not unique to coding. Any domain where an AI system produces plausible seeming output faster than a human can independently verify it will develop the same fork, and coding is simply the domain with the clearest data right now because pull requests and repositories are unusually well instrumented compared to, say, AI generated legal drafts or marketing copy. Teams in other fields adopting generative tools should expect a version of this same curve, rising adoption, falling naive trust, and a widening need for structured verification rather than a return to blind confidence.

The realistic path forward is not waiting for a model good enough to trust blindly. It is treating verification as permanent infrastructure rather than a temporary training wheel that better models will eventually let teams remove. Dependency scanning on every AI assisted change, tracked refactor and duplication rates, and a default habit of reviewing before committing are not signs that the tools have failed. They are what responsible use of a genuinely useful but imperfect tool looks like at scale.

The honest closing line is the one several senior developers in this research already reached on their own. The productivity gain from AI coding assistants is real and worth keeping. The trust that gain requires is not going to be handed to teams by the next model release. It has to be built the same way trust in any junior contributor gets built, through consistent verification until the track record earns something better.

Frequently asked questions

Related reading on aitrendblend.com