BlogThe Trust Collapse: Why 84% of Developers Use AI Coding Tools Daily but Only 29% Trust Them
AI CodingDeveloper ExperienceIndustryProductivity

The Trust Collapse: Why 84% of Developers Use AI Coding Tools Daily but Only 29% Trust Them

Adoption is near-universal. Trust is in freefall. Developer favourability toward AI coding tools has dropped from 77% in 2023 to 60% today. Something is breaking down — and it's not the models.

June 15, 2026·7 min read·Aira

84% of developers use AI coding tools every day. Only 29% trust what those tools produce.

That gap — between usage and trust — is the defining tension in developer tooling right now. And it's been widening. Developer favourability toward AI coding tools was 77% in 2023. It's 60% today. Trust in AI code accuracy has dropped from 43% to 33% over the same period.

The models are objectively getting better. The trust is objectively getting worse. These two things are happening simultaneously. Understanding why requires looking at what developers are actually experiencing, not what the benchmark numbers say.

The Debugging Tax

63% of developers report having spent more time debugging AI-generated code than writing the original code themselves would have taken. This is the core experience driving the trust collapse — not the quality of individual outputs, but the aggregate cost of integrating AI assistance into real development workflows.

AI coding tools are genuinely good at specific things: boilerplate code, test scaffolding, documentation, standard patterns in well-represented languages and frameworks. They produce working code for these tasks quickly, and the code is usually correct.

They're less good at things that require understanding context beyond the immediate file: business logic that depends on organisational decisions made six months ago, security considerations specific to your threat model, architectural constraints that aren't visible in the code being edited. The output looks correct and often isn't.

Where trust breaks down

AI tools are trusted for boilerplate, test scaffolding, and documentation. They're not trusted for architecture decisions, security review, or business logic — exactly the tasks where a mistake is most costly and hardest to catch in review.

The problem isn't that AI produces bad code. It's that AI produces code that looks good and is subtly wrong in ways that are expensive to find. That experience, repeated enough times, produces warranted scepticism.

The Competence Illusion

There's a pattern that experienced developers describe repeatedly: AI assistance is most dangerous when you're least able to evaluate it. A senior developer reviewing AI-generated code for a domain they know deeply will catch the subtle errors. A junior developer, or a senior developer working in an unfamiliar domain, may not.

The code looks confident. It's syntactically correct, stylistically consistent, and structured in ways that seem reasonable. The error is in the semantics — what it does, not how it looks. And semantic errors are harder to catch in review than syntactic ones.

This creates an asymmetry: AI tools are most useful to experienced developers who can evaluate the output, and most risky to inexperienced developers who can't. That's the opposite of the accessibility narrative that accompanied their launch.

Why Favourability Is Falling Even as Capability Rises

The 2023 cohort of AI coding tool users were early adopters — developers who were enthusiastic about the technology, selected for optimism about AI, and working with a low baseline of expectations. The tools exceeded those expectations for many of them.

By 2026, the user base is essentially the entire developer population. The 84% who use these tools daily include a lot of people who didn't opt in enthusiastically — they adopted because the tools became table stakes, because their employers required it, because not using AI became professionally conspicuous.

That cohort has different experiences and different expectations. They encounter the debugging tax more often. They're less likely to attribute failures to their own inexperience with the tools and more likely to attribute them accurately to the tools' limitations.

  • Early adopters selected for optimism — the 2023 favourability numbers reflect their experience, not the median developer experience
  • Mainstream adoption brings mainstream use cases — including ones where AI tools perform poorly
  • Repeated debugging tax experiences accumulate into warranted scepticism
  • The gap between marketing claims (95% on benchmarks) and daily reality (subtly wrong business logic) is becoming visible to more developers

What Trustworthy AI Coding Actually Looks Like

The trust problem isn't solved by better models alone. It's solved by better integration of AI into development workflows — workflows that don't require developers to trust AI outputs blindly, but provide the scaffolding to verify them efficiently.

The most effective teams using AI coding tools in 2026 have a few things in common. They use AI for generation and humans for review, with clear handoff points. They've identified the task categories where AI is reliable (boilerplate, tests) and the ones where it requires heavy review (security, business logic). They've built review practices that make AI errors cheaper to catch.

The shift Gartner describes — from hands-on coding to AI process orchestration — is real, but it's not about trusting AI more. It's about developing better judgment about when to trust it and when to verify carefully.

The question isn't whether to use AI coding tools. It's whether you've built the review practices that make their failure modes cheap to catch.

The trust numbers will probably continue to fall as adoption reaches saturation. That's not a failure of the technology — it's the predictable outcome of any tool moving from enthusiasts to the general population. The developers who will get the most out of AI coding tools are the ones who've stopped expecting to trust them and started building workflows that make trust unnecessary.

More from the blog