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

A new study has uncovered a paradox: 70% of developers consider AI code insecure, but 30% of them deploy it to production anyway, without additional checks.

Numbers without the sensation

The survey covered developers who actively use AI assistants such as GitHub Copilot, ChatGPT, Claude and other tools. The picture is consistent: most people are aware of the risks, but deadline pressure and an illusion of reliability win out.

70% admit that AI consistently produces code with vulnerabilities, logic errors, outdated security patterns or outright poor architecture. One in three of them deploys such code to live environments, without review, without static analysis, and sometimes without tests. These are not isolated cases of negligence but a symptom of a systemic problem.

The author of a column on Habr, a veteran of the PVS-Studio team, says bluntly that this is not a revelation for him. He was already talking about inflated expectations of AI tools a year ago. What is new is that the industry has suddenly started discussing the problem as if it were unexpected.

Why AI code looks reliable

The root of the problem lies in the nature of language models themselves. AI generates code with confidence and without caveats. The syntax is correct, the structure is familiar, the linter stays silent. The developer sees a result that "looks like it works" and relaxes their critical judgment. This is a well-studied psychological phenomenon: the more authoritative the source, the weaker the skepticism.

AI delivers results instantly, which adds to the feeling that "the model has already checked everything." In practice, it has not.

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

code, just as there is in text in general."

A language model does not know the business logic of a specific system and does not understand what data will arrive in real-world operation. It can reproduce vulnerable patterns, such as SQL injections, insecure defaults and missing input validation, simply because those patterns appeared often in its training corpus. Hallucinations in code are not rare; they are the norm.

The tools' own progress makes things worse. Developers see improvements from month to month and tend to extrapolate: "it used to make mistakes, now it's noticeably better." But "better" does not mean "safe," and that gap is where incidents originate.

Questions that should have been asked sooner

The industry is now going through a belated rethink. Teams are asking questions that should have been raised when AI assistants were first adopted:

• Is a separate checklist needed for reviewing AI-generated code?
• How should CI/CD be configured to automatically catch typical generator errors?
• How do you train juniors who are already used 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" does not mean "ready to deploy"?

Most teams are feeling their way to answers by trial and error, sometimes at the cost of real production incidents.

What this means

The problem is not AI as a technology. The problem is positioning: the tools are sold as a replacement for developers, but work as a draft that needs checking. Until teams build a culture of mandatory review of AI code, the statistics will only get worse.

The solution is old and boring: static analysis, mandatory code review, test coverage and a clear understanding that generation speed does not equal quality of results. The tools for this have existed for a long time. The question is the discipline of applying them.