English 
Português
Artificial intelligence has changed how fast development teams ship software. What hasn’t changed at the same pace is the security of what’s actually being shipped. According to the Veracode 2025 GenAI Code Security Report, which tested more than 100 language models across over 80 coding tasks, 45% of AI-generated code samples failed security tests based on the OWASP Top 10. In other words, nearly half of the code produced by AI today carries some kind of known vulnerability.
That number isn’t an isolated warning. It’s a pattern that keeps repeating, study after study, from the earliest tests on GitHub Copilot to the newest “vibe coding” tools. And it’s precisely this pattern that most code copilots, traditional scanners, and even AI vendors themselves aren’t making clear to the people who make decisions inside companies.
Why AI-generated code carries vulnerabilities by default
Code generation models are trained on billions of lines of public code. That public code inevitably includes insecure patterns, outdated libraries, and implementations that should never have made it to production. When a model learns to “write the way the internet writes,” it also learns to repeat the mistakes scattered across it.
One of the first studies to measure this systematically was the study from NYU and the University of Calgary on GitHub Copilot: roughly 40% of the programs generated in security-relevant scenarios contained vulnerabilities. But the problem isn’t only in the model. A Stanford University study, published at ACM CCS, found that developers with access to an AI assistant wrote significantly less secure code than those without it; worse, those same developers believed they had written more secure code than they actually had. It’s the combination of two failures: the AI introduces the risk, and the team’s overconfidence keeps it from being caught in time.
The numbers your AI tool isn’t showing you
Veracode’s report didn’t stop at the 45% failure rate. It also showed that security performance varies significantly by language: Java code failed 72% of tests, while classic Cross-Site Scripting flaws (CWE-80) weren’t properly handled in 86% of relevant samples. In a Spring 2026 update published by Veracode, the company reinforced that, while syntactically correct code rose from about 50% to 95% since 2023, the security pass rate remained flat, hovering between 45% and 55%, regardless of model size or generation. Newer, larger models got better at writing code that works; they didn’t get better at writing code that’s safe.
There’s also a data point that tends to surprise technical leadership: asking AI to “review and improve” its own code doesn’t always reduce risk, sometimes it increases it. A study published in the IEEE-ISTAS 2025 proceedings, cited in a Kaspersky analysis of vibe coding risks, found that after five rounds of AI-assisted refinement on the same piece of code, the number of critical vulnerabilities grew by 37.6%. That challenges a common assumption among teams using AI daily: that more iteration necessarily means more quality.
Outside the lab, the impact shows up in production data too. A Wiz Research report on applications built with vibe coding platforms found that 20% of them had critical vulnerabilities or serious misconfigurations, including client-side authentication, hardcoded secrets, and improperly exposed sensitive data. And the Vibe Security Radar project, run by Georgia Tech’s Systems Software & Security Lab, tracks real (not hypothetical) flaws already logged in public vulnerability databases and directly attributed to AI-generated code: the count jumped from 6 CVEs in January 2026 to 35 in March of the same year. The curve isn’t leveling off, it’s accelerating.
One concrete example of how this slips past even the most widely used tools: CVE-2025-53773 exploited prompt injection hidden in pull request descriptions to achieve remote code execution through GitHub Copilot, with a CVSS score of 9.6, one of the highest on the scale. That wasn’t a syntax error. It was a structural flaw, the kind traditional scanners weren’t built to catch.
The most common vulnerabilities in AI-generated code
Regardless of the tool (Copilot, ChatGPT, Cursor, Claude Code, or anything else), a few failure patterns show up with alarming frequency:
- SQL injection and insufficient sanitization of user input.
- Secrets and API keys hardcoded directly into the code.
- Authorization flaws, such as permission checks performed only on the frontend, or record access by ID without validating resource ownership (IDOR).
- Outdated, malicious, or never-audited dependencies suggested automatically by the AI.
- Missing or insufficient security logging, which makes it harder to detect an incident after the fact.
Any one of these five points, on its own, would justify a process audit. Together, they form exactly the kind of technical debt that doesn’t show up in a functional test, only when someone exploits the gap.
Why scanners and copilots don’t solve this on their own
It’s tempting to think the problem gets solved with “one more tool”: an extra security plugin in the IDE, an automated scanner in the pipeline. It helps, but it isn’t enough. Static analysis tools catch known patterns; they don’t have context about system architecture, business rules, or the sensitive data that a specific piece of code will handle. An AI copilot, meanwhile, was optimized to produce a plausible, functional answer to a prompt, not to question whether that answer is the most secure option for your environment.
The result is a responsibility gap: the tool assumes someone, somewhere in the process, will review the output thoroughly; the team, under deadline pressure, assumes the tool already took care of it. Neither side is entirely wrong on its own. The problem is structural: what’s missing is a methodology that treats AI-generated code like third-party code, with all the rigor that requires, without slowing down the speed AI is supposed to deliver.
What changes when there’s a methodology behind the AI
That’s exactly the gap NextFlow AI, NextAge’s development methodology, was built to close. Instead of treating AI and security as separate tracks (one for speed, one for containing risk afterward), NextFlow AI starts from a Zero Trust principle from the first line of code: no sensitive data is exposed during AI use in the development process, and every access is authenticated, monitored, and restricted to the minimum necessary, by default, not through manual configuration after something has already gone wrong.
What’s called Vibe Coding inside NextFlow AI doesn’t mean letting the AI write without oversight. It’s the structured application of the market’s best AI tools to code development, with senior tech leads at NextAge reviewing every delivery, which speeds up the pace without giving up technical quality. While the market reports failure rates as high as 45% in AI-generated code, squads operating with one-click validation, real-time risk dashboards, and a knowledge base that automatically documents every technical decision can address that risk at the source, not after it’s already become an incident.
If you lead a technology team and are evaluating how to scale AI use in development without inheriting this kind of security debt, it’s worth understanding how NextFlow AI applies to your context.
Checklist: how to tell if your AI development process is actually secure
Before scaling AI use on critical projects, it’s worth confirming whether your operation already covers the following:
- All AI-generated code goes through automated security analysis before reaching production, no exceptions.
- There’s structured human review, done by someone senior, not just a surface-level read of what “looks” like it works.
- Dependencies suggested by the AI are audited before entering the main repository.
- Secrets and credentials are never exposed in code, not even in test environments.
- There’s traceability: it’s possible to know who (or which AI) introduced each piece of code, and why.
- Security requirements are explicit in prompts (authentication, input validation, access control), not left for the AI to decide on its own.
- The team treats AI-generated code as third-party code: read, questioned, and tested, never accepted by default.
- Technical risk is visible in real time to decision-makers, not just to the people writing code.
Frequently asked questions
Is AI-generated code safe for production?
It can be, as long as it goes through structured review and specific security testing before deployment. Without that process, the data shows nearly half of AI-generated code carries some kind of vulnerability, according to Veracode’s report.
What are the most common vulnerabilities in AI-generated code?
SQL injection, exposed secrets and API keys, authorization flaws, outdated dependencies, and missing security logs are among the most recurring, according to research from Veracode and Wiz Research.
Are automated scanners enough to review AI-generated code?
They help, but they don’t replace human review with business context. Scanners catch known patterns; they don’t evaluate architectural decisions or what that specific code is meant to protect.
What is vibe coding, and why does it increase security risk?
It’s the practice of building applications from natural-language prompts, with little to no line-by-line code review. The risk increases because generation speed outpaces manual review capacity, and Wiz Research’s findings show that 20% of applications built this way have critical flaws.
How can a company scale AI use in development without increasing risk?
By combining AI with methodology: senior squads overseeing every delivery, Zero Trust by default, and structured validation at every stage of the cycle, exactly the model applied by NextFlow AI.
Conclusion
Shipping faster with AI isn’t the problem. The problem is shipping faster without a methodology that accounts for the risk that speed brings with it. The numbers are clear: between 40% and 45% of AI-generated code today carries known vulnerabilities, and the curve of real incidents attributed to these tools keeps climbing month over month. The question for anyone leading a technology team isn’t whether they’ll use AI in development, that’s already practically inevitable, but under what process that AI will be used.
Want to understand where your development cycle is losing both security and speed at the same time, and how NextFlow AI solves that in practice? Learn more about NextAge’s methodology.
