Developers are using AI more than ever. And trusting it less than ever. 🤦‍♂️

According to Stack Overflow’s 2025 Developer Survey, 84% of developers now use or plan to use AI tools in their workflows. That’s up from 76% last year. But trust in AI accuracy? It’s collapsed from 43% in 2024 to just 33% this year. Nearly half (46%) actively distrust what these tools produce.

The tools got better. The code got faster. And trust fell off a cliff.

That’s not a contradiction. It’s a reckoning.

The “Almost Right” Problem

The number one frustration developers cite isn’t that AI fails spectacularly. It’s that AI fails almost imperceptibly.

66% of developers say their biggest pain point is AI solutions that are “almost right, but not quite.” The code compiles. The tests pass. The feature works. Until it doesn’t. And then you’re debugging someone else’s logic that you never wrote and don’t fully understand.

45% of developers report that debugging AI-generated code takes longer than they expected. Not faster. Longer.

This is the hidden cost of velocity. You’re not saving time if you spend it hunting bugs you didn’t create in code you didn’t write.

The Security Time Bomb

Speed without quality is a liability. Speed without security is a lawsuit waiting to happen.

Veracode’s 2025 GenAI Code Security Report analysed code from over 100 LLMs across 80 real-world coding tasks. The results were brutal:

• 45% of AI-generated code contained security vulnerabilities

• Java had a 72% security failure rate—the highest of any language tested

• 86% of code samples failed to defend against cross-site scripting

• 88% were vulnerable to log injection attacks

The kicker? Bigger models didn’t perform better. Newer models didn’t perform better. Security performance stayed flat regardless of model size or training sophistication.

This isn’t a scaling problem. It’s a systemic one. The models aren’t learning to write secure code. They’re learning to write code that looks secure.

Why This Keeps Happening

The explanation is straightforward, if uncomfortable: LLMs are trained on the internet’s code, and the internet’s code isn’t secure.

As Endor Labs’ analysis puts it, training data includes “good code: popular libraries, clean examples, best practices” alongside “bad code: outdated APIs, inefficient algorithms, poorly documented.” The models don’t discriminate. They learn both.

By default, AI-generated code frequently omits input validation unless explicitly prompted. Authentication? Hard-coded secrets? Unrestricted backend access? All common patterns in AI output, because they’re common patterns in training data.

The models reproduce what they’ve seen. What they’ve seen is decades of shortcuts, technical debt, and “we’ll fix it later” decisions that never got fixed.

The Vibe Coding Trap

This matters more now because “vibe coding” has gone mainstream, and 72% of professional developers say it’s not part of their workflow.

That stat cuts two ways. On one hand, most professionals haven’t abandoned code review. On the other, 28% have embraced generating code they don’t review. And in organisations where non-technical users are building internal tools? The percentage is higher.

Gartner doesn’t mince words: they recommend companies “limit [vibe coding] to a controlled, safe sandbox for execution” and warn that “by 2027, at least 30% of application security exposures will result from usage of vibe coding practices.”

The democratisation of software development is real. So is the democratisation of security vulnerabilities.

Trust Isn’t a Feature. It’s Infrastructure.

The instinct is to treat this as a prompting problem. “Just tell the model to write secure code.”

Doesn’t work.

Veracode tested this. A generic security reminder improved secure code output from 56% to 66%. Better, but still a coin flip. And that’s with explicit security prompting—something most developers don’t do, and vibe coders definitely don’t do.

The models can’t be trusted to enforce what they weren’t trained to prioritise. Security has to be enforced around the model, not by the model.

That means:

Automated security scanning on every commit. Not optional. Not “when we have time.” Every commit, every PR, every deployment. Tools like SAST and DAST need to be as automatic as linting.

Guardrails at the infrastructure level. Don’t rely on developers (or models) to remember security constraints. Encode them in the platform. Block deployments that fail security checks. Make insecure code physically unable to reach production.

Observability that traces AI-generated code. When something breaks, you need to know whether it was human-written or AI-generated. The debugging approaches are different. The remediation patterns are different.

Explicit separation between “works” and “production-ready.” AI excels at getting things to work. It’s mediocre at making things robust. Build your workflow around that reality.

The Real Problem Isn’t AI. It’s the Absence of Systems.

Here’s what the trust numbers actually reveal: developers aren’t disillusioned with AI. They’re disillusioned with unsupervised AI.

The same survey shows that 69% of developers using AI agents agree productivity is improving. They’re not abandoning the tools. They’re learning that the tools need guardrails.

The organisations that will thrive aren’t the ones that reject AI. They’re the ones that build systems to make AI trustworthy—scanning, validation, enforcement, and observability as first-class infrastructure concerns.

Trust isn’t restored by better prompts. It’s restored by better systems.

The Bottom Line

84% adoption with 33% trust isn’t sustainable. Something has to give.

Either the models get dramatically better at security (they’re not), developers get dramatically better at reviewing AI output (they won’t, that defeats the point), or organisations build infrastructure that enforces quality regardless of who—or what—wrote the code.

The trust reckoning isn’t coming. It’s here. The question is whether you build systems to address it, or wait until the breach forces the conversation.

We’re building for the former.

Ready to enforce trust at the infrastructure level?

Sign up to see how Ardor builds security, observability, and quality enforcement into the full agentic SDLC.