70% of developers know AI writes buggy code — and deploy it to production anyway

70% of Developers Know AI Writes Leaky Code — And Still Deploy It to Prod

New research reveals a paradox: 70% of developers consider AI code insecure, but 30% of them still deploy it to production — without additional checks.

Numbers Without Sensation

The survey covered developers actively using AI assistants — GitHub Copilot, ChatGPT, Claude, and other tools. The picture is consistent: most recognize the risks, but deadline pressure and the illusion of reliability take their toll. 70% admit that AI consistently produces code with vulnerabilities, logic errors, outdated security patterns, or outright bad architecture.

Every third one of them deploys such code to combat environments — without review, without static analysis, sometimes without tests. This is not isolated cases of negligence — this is a symptom of a systemic problem. The author of a Habr column, an alumnus of the PVS-Studio team, speaks directly: for him this is not a discovery.

He was having conversations about inflated expectations of AI tools a year ago. What's new is that the industry suddenly began discussing the problem as something unexpected.

Why AI Code Seems Reliable

The root of the problem lies in the very nature of language models. AI generates code confidently, without caveats. The syntax is correct, the structure is familiar, the linter is silent. The developer sees a "looks like it works" result — and lowers the critical perception. This is a well-studied psychological phenomenon: the more authoritative the source, the weaker the skepticism. AI produces results instantly — which additionally creates the impression that "the model already checked everything." In practice, this is not the case.

"Expectations are inflated, and there is excessive trust in generated

code — just as with texts in general."

A language model does not know the business logic of a particular system, does not understand what data will come in during real operation. It can reproduce vulnerable patterns — SQL injections, unsafe defaults, lack of input validation — simply because they appeared frequently in the training corpus. Hallucinations in code are not rare but a natural consequence. The problem is compounded by the progress of the tools themselves. Developers observe improvements month after month and are inclined to extrapolate: "used to make mistakes, now noticeably better." But "better" does not equal "secure" — this very gap becomes the source of incidents.

Questions That Should Have Been Asked Earlier

Now the industry is undergoing belated reconsideration. Teams are asking questions that should have been raised when AI assistants were first deployed:

• Is a separate checklist for reviewing AI-generated code needed?
• How to configure CI/CD to automatically catch typical generator errors?
• How do you teach juniors who have already grown accustomed to trusting autocomplete?
• What role should static analyzers play in a pipeline with AI?
• How do you explain to management that "generated in 10 seconds" is not the same as "ready for deployment"?

Most teams are groping for answers through trial and error — sometimes at the cost of real production incidents.

What This Means

The problem is not with AI as a technology. The problem is with positioning: the tools are sold as a replacement for a developer, but they work like a draft requiring verification. Until teams develop a culture of mandatory AI code review — the statistics will only worsen. The solution is old and boring: static analysis, mandatory code review, test coverage, and a clear understanding that generation speed does not equal result quality. The tools for this have existed for a long time. The question is in the discipline of their application.