Generative AI can produce a working function from a sentence. Developers are using it everywhere, and the speed is not imaginary. Neither is the cost.
The same tools that make a team four times faster are quietly shipping insecure code at a rate the industry is only now measuring, and most of that measurement is bad news.
The belt never slows for the empty booth. AI ships code at speed, and the security review it skips is exactly where the cost waits.
The data is not close
Veracode tested more than 100 large language models across Java, JavaScript, Python, and C# for its 2025 GenAI Code Security Report. Forty-five percent of the AI-generated samples introduced an OWASP Top 10 vulnerability, and the pass rate did not improve across testing cycles from 2025 into early 2026. Newer models released through late 2025 showed no meaningful security gains. Some categories were worse than the average suggests. Cross-site scripting failed 86 percent of the time, and AI-generated Java failed on security 72 percent of the time.
The pattern holds outside one vendor's lab. Apiiro's research across large enterprises found CVSS 7.0-and-above vulnerabilities showing up about 2.5 times more often in AI-generated code, and by June 2025 that code was adding more than 10,000 new security findings a month, a tenfold jump from December 2024. Incidents per pull request rose roughly 23.5 percent year over year while review cycles ran about twice as long. The booth in the cartoon is empty for a reason. The velocity is real, and it does not eliminate the work. It moves it downstream into review, security, and incident response, where it costs more.
Why it comes out broken
The models learned to write code the way most code on the internet is written, which is to say without a threat model. They optimize for something that runs and looks plausible, not something that resists an attacker. They do not reliably add input validation, enforce least privilege, or implement security-critical logic correctly, because nothing in the objective rewards that.
The more dangerous problem is human. A controlled study found that developers using an AI assistant wrote less secure code and were more confident it was secure, rating flawed solutions as safe. The tool produces a false sense of assurance that suppresses exactly the scrutiny the output needs. Reviewers tend to trust a confident AI suggestion more than a junior engineer's first draft, which is the opposite of how the risk actually distributes.
This is not theoretical anymore. CVE-2025-48757 traced to the AI coding platform Lovable generating database schemas without row-level security, exposing data across applications built on it. Georgia Tech's Vibe Security Radar project tracked 35 CVEs in a single month, March 2026, tied directly to AI coding tools, and estimated the real count is five to ten times higher across open source.
The attack you didn't see last year
There is a newer risk that has nothing to do with the quality of the code and everything to do with what the AI invents. Models hallucinate software packages. They confidently recommend importing a library that does not exist. In one study, about 20 percent of AI-generated samples referenced at least one package that was not real, and these were not random. More than 58 percent of the fake names showed up again across multiple runs, and 43 percent appeared consistently across ten attempts with the same prompt.
That predictability is the whole attack. Security researcher Seth Larson named it slopsquatting. An attacker watches which package names the models tend to invent, registers those names in a public repository with malicious code inside, and waits. A developer asks the AI for code, gets a phantom dependency, installs it, and runs the attacker's payload. This has already happened at scale: confirmed malicious packages exploiting this vector have racked up tens of thousands of downloads, and in one documented case a hallucinated package accumulated over 30,000 downloads in three months after the bogus install command made its way into trusted public documentation. Traditional typosquatting bets on human typos. Slopsquatting bets on machine confidence, which is far more consistent.
The part worth arguing about
Here is the editorial. AI coding tools are a productivity multiplier and a defect multiplier in the same motion, and pretending otherwise is how organizations get hurt. The gain is genuine. The bill is just deferred, and it comes due in code review, in audits, and eventually in breach notifications.
The model does not sign your SOC 2. It does not answer to the auditor. It does not sit in the room after an incident. Ownership of every shipped line stays with the organization that shipped it, regardless of who or what typed it. Treat AI output like a contribution from a fast, confident contractor you have never vetted: useful, and never merged unread.
The defenses are old and boring, which is good news, because boring is repeatable. Review AI code at least as hard as human code. Pin and verify dependencies. Confirm every recommended package against the registry and check its publish date before adoption. Run software composition analysis, secrets scanning, and least-privilege defaults. None of this is new. AI changed the volume, not the fundamentals. Put the inspector back on the line.
Risk does not disappear because a machine wrote the code. The only real choice is whether you assess it on purpose or accept it by default through not looking.