Does AI-generated code introduce security vulnerabilities, or is the real failure point earlier, in how developers evaluate the suggestions before any of it reaches a commit? A new study put 100 developers in front of AI-generated code suggestions that varied deliberately in security, then asked them to pick, edit, and ship. They picked the secure option about as often as the insecure one. Only 22% of what they finally submitted was fully secure, according to a 100-developer study of AI-generated code suggestions. The developers in this study had the secure version and the insecure version sitting side by side, in a choice they made themselves, and still couldn't tell them apart under normal conditions.
What the study actually tested
Researchers ran a remote observational study with 100 developers working through four C tasks, all built around linked lists. For each task, participants saw five AI-generated suggestions deliberately varied in security and functionality, chose one, edited it if they wanted, then submitted final code. After the coding sessions, the team ran a survey and followed up with 23 participants for in-depth interviews on how they'd actually made their choices.
Linked lists in C are a deliberate choice of ground. Memory management bugs there are well-documented, well-understood failure modes, not exotic edge cases. If developers were going to catch a security problem anywhere, this is close to the easiest terrain to catch it on.
Developers couldn't reliably pick the secure suggestion
Given a menu ranging from most to least secure, developers chose the most-secure option 37.7% of the time and the least-secure option 35.0% of the time. That gap isn't statistically significant. Developers were, in effect, choosing close to at random when security was the variable on the table.
The paper's regression model adds a stranger detail: suggestions with some vulnerabilities, neither the cleanest nor the worst option, got picked at a higher rate than either extreme. A suggestion doesn't need to look secure to win a developer's attention. It just needs to not look obviously broken, which is a far lower bar, and one an AI suggestion can clear by accident.
How that showed up in the final code
Selection behavior is one measure. What actually shipped is the one that matters more. Of 400 total submissions across the study, only 88, 22%, were fully secure. Only 5% of participants produced secure code across all four tasks.
The worst single task, adding an item to the linked list, produced insecure submissions 92% of the time, averaging 2.9 vulnerabilities per submission. That's not a task most developers would call hard, which is the uncomfortable part. The study didn't observe anyone working alongside teammates or a dedicated security review, so it can't tell you how often this survives a real team's process.
Why developers missed the vulnerabilities
The interviews explain the selection numbers better than the numbers alone can. Developers spent an average of 37 seconds reviewing each suggestion before choosing. Sixteen of the 23 people interviewed said they took no explicit step aimed at security when looking at a suggestion. Security wasn't a checklist item. At best, it was a background hope.
When developers did think about security, most reached for the wrong signal. Eighteen of the 23 interviewees said they used visible edge-case handling in the code as their proxy for whether it was secure. Code that checks for null pointers and bounds errors reads as careful, so it gets treated as safe. The paper's own data undercuts that heuristic: suggestions with plenty of visible edge-case handling still carried real vulnerabilities, and developers relying on that cue had no way to tell the difference in 37 seconds.
The trust gap between belief and outcome
The survey results point at a confidence problem sitting underneath the behavior problem. Sixty-one percent of developers believed that using AI generally improves code security. Ask the more specific version of that question and the number drops hard: only 39% agreed that developers who use AI write more secure code. People will endorse a comforting generality about AI and security while doubting it applies to the actual behavior of actual developers, themselves included.
None of that dented adoption. Eighty-nine percent of participants said they intend to keep using AI regardless. Nobody in this study is proposing to stop using AI suggestions. The open question is what happens between the suggestion appearing on screen and the code getting merged, and right now the answer is: not much.
What this does and doesn't prove
Read the headline number and it's tempting to conclude AI-generated code is inherently insecure. That's not what this study shows, and the limits are worth stating plainly.
This was a controlled lab study, not a production codebase under real deadline pressure with real teammates reviewing the work. The four tasks were all memory-safety-heavy C linked-list problems, chosen because vulnerabilities there are well-characterized, not because they represent the average day of a backend or frontend engineer. The five suggestions per task were researcher-curated, built to vary deliberately in security and functionality, not pulled live from Copilot, Cursor, or Claude completions in normal IDE use. And it's a preprint: it has been accepted to IEEE Security & Privacy '27 and went through that conference's review, but it hasn't appeared in the proceedings yet.
What the study does support is narrower and more useful: when developers evaluate AI code suggestions under normal time pressure, without an explicit, structured security-checking step, they don't reliably separate secure from insecure options, even when the choice is put in front of them directly. That's a claim about developer evaluation behavior, not a verdict on AI-generated code as a category. The paper itself recommends treating security review of AI suggestions as a deliberate, separate step, not something folded into a same-glance judgment call during normal code review.
That's the practical takeaway for a review process, too. If "look over the AI suggestion before accepting it" is the entire policy, this study is evidence that policy doesn't work, not because developers are careless, but because 37 seconds and a vague impression of tidiness aren't enough to catch a memory-safety bug even when someone is actively trying. A security-specific review step, with its own checklist and its own time budget, separate from the general "does this look right" pass, is the change the data actually points to.
This sits next to the AI-speed research showing that AI's speed gains are real but task-dependent, and it complicates the simple version of that story: speed on a bounded task says nothing about whether the resulting code is secure, and how AI tool use affects ramp time is a separate question from whether a faster ramp produces code a security-conscious team can trust without a dedicated check. It's also why spotting security issues in AI-generated code and separating engineering judgment from AI-generated code show up as explicit skills to screen for rather than assumptions to make about anyone who's used a coding assistant, and why reviewing a pull request for a security vulnerability is a live-session exercise worth running on any senior backend candidate, AI-assisted or not.
Frequently asked questions
Does this study prove AI-generated code is less secure than human-written code?
No. It didn't compare AI-generated code against a human-written baseline. It studied how developers evaluate and choose among AI-generated suggestions of varying security, and found they couldn't reliably tell the secure ones from the insecure ones in the time they gave themselves.
How long did developers spend reviewing each AI suggestion?
About 37 seconds on average per suggestion. Sixteen of the 23 interviewed participants said they had no explicit security-checking step at all during that time.
What's the single biggest risk this study flags for engineering teams?
Two things compound each other: most developers reviewing an AI suggestion don't have an explicit security step, and the ones who do check often rely on a weak signal, visible edge-case handling, that the study shows doesn't reliably indicate secure code. A general "review the suggestion" policy addresses neither problem.
Is this study peer-reviewed?
It's a preprint, posted in September 2026 and accepted to IEEE Security & Privacy '27, so it has been through that conference's review but is not yet published in the proceedings. The tasks were also small, memory-safety-heavy C exercises with researcher-curated suggestions rather than live completions from tools like Copilot or Cursor, so the specific numbers shouldn't be extrapolated directly onto a different language or a production codebase.