Stack Overflow's 2025 Developer Survey collected responses from more than 49,000 developers across 177 countries, fielded May 29 through June 23, 2025, and it found a split most vendor decks don't show. 84% of respondents already use AI tools or plan to. Only about a third say they trust what those tools produce, and fewer than one in thirty say they trust it highly. For a VP of Engineering deciding how much of the roadmap to route through a smaller team plus AI, that gap is the actual constraint, not the model's benchmark score.
The number every roadmap already assumes
Adoption isn't a live question anymore; the survey settles it. Of the 49,000-plus respondents, 47.1% use AI tools daily, another 17.7% use them weekly, and 13.7% more use them monthly or occasionally. Add the 5.3% who plan to start soon and 84% of the developer population is somewhere on the adoption curve already. Only 16.2% say they have no plans to use AI tools at all. Whatever decision a funded product company is still debating, "should engineers use AI to write code," has already been made by the market. The question that's actually still open is what happens to the code after it's written, and that's the question the same survey answers less comfortably.
Trust didn't follow adoption up the same curve
Favorable sentiment toward AI tools ran above 70% in both 2023 and 2024. In the 2025 survey it dropped to 60%, with professional developers somewhat more favorable (61%) than people still learning to code (53%). On the sharper question of whether developers actually trust the accuracy of what these tools output, the numbers split further apart: 3.1% say they highly trust it, 29.6% somewhat trust it, 26.1% somewhat distrust it, and 19.6% highly distrust it. Combined, distrust (45.7%) outweighs trust (32.7%) by a wide margin, and the group you'd expect to have made peace with the tool by now, developers with the most years of experience, are the most skeptical of anyone the survey asked: only 2.6% of them say they highly trust it. Stack Overflow's own follow-up post on the finding, published February 18, 2026, names the mechanism directly: AI output is probabilistic where an engineer expects deterministic, so the same prompt can return a different answer twice, and a tool that occasionally invents an API that doesn't exist trains a careful reader to stop assuming the next output is safe by default.
"Almost right" is the expensive failure mode
Ask developers what actually bothers them and the answer isn't "it doesn't work." It's the opposite problem. 66% of respondents named "the solution is almost right, but not quite" as their top frustration with AI coding tools, ahead of every other complaint the survey measured, and 45.2% separately said debugging AI-generated code eats real time. A function that's obviously broken fails in CI before anyone has to think about it. A function that's almost right compiles, passes the existing test suite because nobody wrote a test for the case it gets wrong, and reads cleanly enough in a pull request that a reviewer skimming for style has no reason to slow down. That's a verification cost, not a typing cost, and it doesn't show up on the same dashboard that tracks how many tickets closed this sprint.
What this means for your review process
If code review capacity didn't grow at the same rate adoption did, the bottleneck didn't disappear, it moved. The GitClear data on where AI-era code quality is actually heading shows the same shift from the structure side: refactoring collapsing while duplication climbs, which is exactly what happens when the people who'd normally catch "almost right" code are too busy shipping to go looking for it. The fix isn't slowing adoption down, since 84% already means that ship sailed. It's treating AI-authored code the way a careful team already treats a pull request from someone new to the codebase: worth reading in full, not worth a rubber stamp because the diff looks tidy, and worth the same evaluation discipline we've written about for AI features generally applied to the code review step itself, with a real test for the case that got it wrong last time rather than trusting it won't happen again.
A worked example
Picture a 60-person Series B product company two sprints into a team-wide AI coding tool rollout. Velocity is up, the standup is full of green checkmarks, and nobody's complaining. Then a support ticket traces back to a rate-limiting function an engineer shipped the week before: it works for every case the existing tests cover and silently allows a second request through when a specific header is missing, a case nobody wrote a test for because nobody thought to. The pull request that introduced it was twelve lines, read cleanly, and got approved in four minutes by a reviewer who, per the same survey, is statistically more likely than not to distrust the tool's output in the abstract and still didn't slow down for this particular diff. That's the almost-right problem, not a security team's imagined threat model. It's what 66% of developers are already telling researchers happens to them.
Where a senior hire fits, and where it doesn't
The finding here isn't "AI tools are unreliable," it's "the humans using them already know that and the process hasn't caught up." A senior engineer brought in through staff augmentation closes a specific version of this gap well: someone experienced enough to read an AI-authored diff the way the survey's most skeptical cohort already does, and to own the review discipline a fast-shipping team hasn't had the slack to build for itself. It's a weaker fit if the real problem is that no one has decided review time gets to compete with the next feature on the roadmap. Adding a senior engineer to a team that hasn't made that call just gives the same pressure a new person to consume, and that's a prioritization decision for whoever owns the roadmap, not something a contractor should quietly absorb.
If your team's adoption curve looks like the 84% and your review process hasn't caught up to it yet, that's a specific, scoped conversation, not a platform overhaul. Our Silicon Valley team has it with engineering leaders regularly, and telling us what your stack actually looks like gets you a straight answer on whether the gap is a headcount problem or a decision your team hasn't made yet.
Sources
- Stack Overflow: 2025 Developer Survey (fielded May 29 to June 23, 2025; 49,000+ responses, 177 countries, 62 questions)
- Stack Overflow: Mind the gap: Closing the AI trust gap for developers (published February 18, 2026)