Developers Are Shipping AI Code They Know Is Broken, and Users Pay the Price

When software fails, the people who pay are rarely the ones who wrote it. They are the users whose passwords leak, whose payment details surface on a criminal forum, whose private messages get scraped by a worm crawling through a poorly maintained dependency. A new report from application security firm Checkmarx puts hard numbers on a problem that privacy advocates have warned about for years: developers increasingly know their code is unsafe, and they ship it anyway.

What happened

Checkmarx surveyed 2,350 developers, CISOs, and application security managers worldwide, continuing an annual study it has run since 2023. This year's sample was 54 percent larger than last year's, which lends some weight to the findings. The headline figure is blunt: 70 percent of developers believe AI-generated code carries more vulnerabilities than human-written code, and 30 percent admit to knowingly pushing vulnerable code into production.

The context makes it worse. Among respondents, roughly half of all production code is now AI-generated. The figure actually dipped slightly from last year, falling from 54 percent to 49 percent, but that is still an enormous share of the software running banks, hospitals, government portals, and the apps on every phone. Layered on top of that, the report estimates open source components make up 59 percent of production code. Much of that open source sits buried in directories like node_modules, pulled in automatically, rarely audited, and sometimes deliberately poisoned. Malicious packages slipped into repositories such as npm and PyPI have become a recurring attack vector, and overstretched maintainers cannot patch flaws as fast as AI tools can discover them.

The outcome is predictable. Ninety-three percent of respondents reported at least one security breach caused by a vulnerable application. That is down from 98 percent the previous year, but it is hardly cause for celebration. Checkmarx sums up the culture in two words: "Risk is normalized."

Why it keeps happening

Developers gave familiar reasons for shipping code they distrust. Pressure to deploy quickly came first. Some vulnerabilities were judged too difficult to fix. Others were waved through on the assumption that some other control, a firewall, a monitoring tool, a scanner, would catch the problem downstream.

This is the part that matters for anyone whose data sits inside these systems. The decision to ship a known flaw is a decision to transfer risk from the company to its users. When an organization calculates that hitting a release date is worth more than closing a security hole, the person whose records get exposed never gets a vote. That asymmetry is exactly what data protection law is supposed to correct.

The AI angle deepens the issue. Large language models are trained largely on public code, which carries its own long history of insecure patterns. A study last year by researchers at the University of Central Florida and Birzeit University in Palestine compared code security across Java, Python, C, and C++ and across several models. They found wide variation, with C producing the most security issues and Python the fewest. One finding stands out: the models "underutilize modern language and compiler features, often favoring outdated practices over more secure alternatives." In plain terms, AI tends to reproduce the bad habits it learned from old code, then hands them back to developers wrapped in fresh confidence. The researchers stressed their results were a "time-stamped view," since models change quickly, but the mechanism is structural and unlikely to vanish.

The legal and compliance stakes

None of this happens in a vacuum. Under the General Data Protection Regulation, organizations handling personal data are required to implement "appropriate technical and organisational measures" and to follow data protection by design and by default, the principles set out in Articles 25 and 32. Knowingly deploying vulnerable code that handles user data sits in direct tension with those obligations. Regulators have repeatedly fined companies not merely for suffering a breach, but for failing to take reasonable steps to prevent one. A developer survey in which 30 percent confess to shipping known vulnerabilities is, from a compliance standpoint, a documented record of that failure happening at scale.

The picture is similar under the California Consumer Privacy Act and its successor, the CPRA, which give consumers a private right of action when their personal information is exposed through a business's failure to maintain reasonable security procedures. "We were under pressure to deploy" is not a defense that holds up well in front of a data protection authority or a court. The Checkmarx finding that organizations generating 81 to 100 percent of their code with AI ship vulnerable code at 3.4 times the rate of those at 1 to 20 percent adoption is precisely the kind of correlation a regulator would seize on when assessing whether a company acted reasonably.

What it means for the people on the other end

For users, the practical message is sobering. The apps you trust with your identity, your health information, and your money are increasingly assembled at speed from machine-generated code resting on a foundation of open source components that few people have read closely. When breaches follow, the consequences land on individuals: account takeovers, identity theft, fraudulent charges, and the slow grind of trying to undo damage you had no hand in causing.

The tools to do better already exist. Checkmarx notes that static analysis and newer AI-driven remediation tools can find and fix many of these flaws. The failure is organizational, not technical. "The tools do the work, but organizations lack in translating this into process," the company reports. Veracode reached a similar conclusion, warning that AI is accelerating development faster than security practices can adapt. The capability is there. The will to slow down and use it is not.

What changes

For companies, the rational response is to treat security review as a non-negotiable gate rather than an optional step that yields to deadline pressure. That means integrating scanning into the pipeline so vulnerable code cannot merge, auditing the open source dependencies that make up the majority of most codebases, and treating AI-generated code with the same scrutiny applied to a new junior hire's first commit, not less. Regulators, for their part, now have survey data showing that insecure deployment is a deliberate choice in a meaningful share of cases, which strengthens the argument for enforcement when breaches occur.

For users, the most useful shift is awareness that "move fast" has a cost, and that cost is often paid in their own exposed data. The pressure that drives developers to ship flawed code is real, but the people absorbing the fallout had no say in the trade. Closing that gap, through stronger enforcement, better defaults, and a culture that stops treating breaches as the price of doing business, is the work that actually protects the public. The numbers in this report are a measure of how far that work still has to go.