What the AI coding assistant security study actually found

The headline "AI makes code less secure" is too coarse to guide engineering practice. The more consequential result is that security and confidence moved in opposite directions. A developer who feels certain about a plausible implementation has less reason to interrogate it, exactly when it deserves more scrutiny.

Perry, Srivastava, Kumar, and Boneh report the result in Do Users Write More Insecure Code with AI Assistants?. The study had 47 participants after exclusions: 33 with access to an AI assistant and 14 without. The assistant was built on codex-davinci-002, a 2022 model. Those rates must not be presented as a measurement of any 2026 coding assistant.

The claim that survives the model change is narrower. An assistant can alter both the code a developer writes and the developer's assessment of that code. When confidence rises faster than security, ordinary review habits stop being a reliable control.

What did the AI coding assistant study test?

Whether access to an assistant changed security outcomes and users' beliefs about those outcomes. Participants completed five security-related programming tasks in Python, JavaScript, and C, and the experiment compared assistant access against a control group without it.

Participants with assistant access wrote significantly less secure code than participants without access. They were also more likely to believe they had written secure code, which is the central separation between actual and perceived security.

The design is not a general audit of every coding assistant. It is evidence about one interaction between developers, tasks, prompts, and a 2022 model. A modern system may well produce better code on the same task. That improvement would not, by itself, remove the risk that a developer's confidence exceeds the evidence in the implementation.

Why is the confidence gap more dangerous than insecure output alone?

Because perceived safety determines how much review the code receives. Insecure output on its own invites suspicion; insecure output paired with increased confidence can reduce it. The security failure then occurs in the review process as well as in the generated code.

A plausible answer is easy to accept when it compiles, matches the requested interface, and resembles familiar code. Security defects often sit in assumptions that functional testing never challenges: what an input can contain, which identity is authorized, what a path resolves to, or how a query is constructed.

Review is supposed to allocate attention according to uncertainty and consequence. If assistant-written code feels more trustworthy than it is, that allocation rule breaks, and the reviewer spends less effort precisely because the artifact appears finished.

How large was the security difference in the study?

Assistant users had lower secure-solution rates on signing, file access, and SQL. Participants with assistant access also wrote insecure solutions more often than the control group on four of the five tasks.

Those figures establish what happened in this experiment. They do not establish a universal failure rate for current assistants, languages, repositories, or developer populations. With 47 participants and a 2022 model, the per-task percentages are historical evidence about a specific setup, and the practical conclusion drawn from them is simply to preserve independent security review even when an assistant-generated change looks conventional.

What does the study say about developers who got better results?

It found better security outcomes among participants who trusted the AI less and engaged more with the language and format of their prompts. That points toward a review posture: assistant output is safer to treat as a proposal requiring examination than as an authority that has already performed the examination.

Prompt engagement is not itself a security guarantee. A detailed prompt can still omit an authorization boundary or encode a defective threat model. The useful signal is critical involvement, not prompt length.

Nor does the paper show that refusing all assistants is the only safe policy. It shows that trust and security outcomes were related in the observed setting, which suggests making skepticism procedural rather than dependent on a developer's momentary feeling. As a planning-stage control, reviewing the agent's plan before code is written can expose dangerous assumptions before a generated implementation makes them look settled.

How should developers review assistant-written security code?

Against explicit security questions, rather than by judging whether the code looks plausible. Review intensity should follow the consequence of a defect, not the confidence produced by the assistant's explanation.

Four questions work for each assistant-generated change:

• What input or state does this code trust?
• Which identity or authority is allowed to perform the operation?
• What security property must hold if the input is hostile or unexpected?
• What test or inspection would reveal a violation of that property?

Assess what the code does, then assess separately whether the security property holds. Do not let the assistant's explanation or a passing test answer both questions. These questions extend the study's task categories into an engineering control; they are not claims that the paper tested each checklist item, and the exact checklist has to fit the application.

Does a newer coding assistant remove this risk?

A newer assistant can improve generated code without removing the confidence-gap risk. Model progress changes the quality of suggestions. It does not guarantee that a developer will calibrate confidence to the quality of each suggestion, and a reviewer can still accept code because the response is fluent, coherent, and familiar.

The portable claim is about direction, not rate. The study observed less secure code alongside greater belief in its security. That combination deserves a control that survives better models: require security review to run independently of perceived answer quality. A useful rule is that confidence is not evidence — the assistant may produce an implementation, explain a choice, or suggest a test, but the reviewer remains responsible for checking the security property against the system's actual boundary and threat model.

Assistant features also change the attack surface beyond generated code. Teams evaluating agentic tools should separately account for skill-supply-chain risks in agentic coding tools and treat the tool list as an attack surface. Those concerns are distinct from this study's finding, and neither substitutes for the other.