Do Users Write More Insecure Code with AI Assistants?

Earlier work, including the Copilot study on this site, showed that code assistants often suggest insecure code. But people do not paste every suggestion unchanged: they edit, test and sometimes reject them. This Stanford study asks the question that matters for teams: do people who use an assistant end up with less secure code than people who do not?

The authors built a study app with a code editor and, for the experiment group, a panel for querying an assistant based on OpenAI's codex-davinci-002 with adjustable settings such as temperature. Participants had two hours for five tasks: encrypt and decrypt a string with a symmetric key in Python, sign a message with an ECDSA key in Python, open a file only inside a given directory in Python, insert a row into a SQL table from JavaScript, and format an integer with commas in C. After screening, 47 people remained, 33 with the assistant and 14 without, mostly students with some professionals. Two authors graded every answer for correctness and security, with agreement scores reported.

With the assistant, fewer participants wrote secure answers on four of the five tasks. On encryption, more used trivial ciphers or insecure modes. On signing, 3% wrote a secure solution against 21% without the assistant, mostly because of unsafe randomness from the library the assistant chose. On the directory task, assistant code checked the path's prefix but did not resolve ".." or symbolic links. On SQL, 36% with the assistant wrote code open to injection against 7% without. The C task showed no clear difference.

Participants with the assistant also rated their answers as more secure on every question, and those whose answers were secure tended to trust the assistant less. The authors' prompt analysis found that participants who gave specific instructions, supplied function signatures and edited outputs heavily produced more secure code. The headline claim rests on per-task chi-squared tests; the paper's own logistic regression, corrected for testing five tasks, does not reach significance, a point this page returns to.

The risk is confident acceptance, not just bad suggestions. People with the assistant wrote less secure code and believed it was more secure. When a customer rolls out a coding assistant, plan for that gap: review and scanning have to catch what developers now accept without checking.

The mistakes are specific and predictable. Unsafe randomness and weak cryptography modes, path checks that skip canonicalization, SQL built by string concatenation. These are the patterns to put in linters, code-review checklists and secure helper libraries before rollout.

Experience changed how people used it. Participants with secure answers edited the assistant's output heavily and trusted it less. Pairing assistant rollout with short secure-coding guidance for the specific stack is cheap and aimed at the right people.

Do not overclaim the evidence. With 33 and 14 participants, the paper's adjusted analysis does not reach statistical significance, and our simulation shows a study this size would miss a real 30-versus-50% difference most of the time. The direction is consistent across four tasks, which is worth acting on; it is not a measured effect size to quote in a business case.

Measure it in the customer's setting. Compare scanner findings per change for code written with and without the assistant, by weakness class. That turns a lab result into the customer's own evidence.