In short
It is safe to ship when it has been reviewed, tested and understood by a person who could have written it, and unsafe when it has not. Studies have found AI assistants produce code with security vulnerabilities at rates similar to or higher than developers writing unaided, and that developers using assistants tend to trust the output more than it deserves. The recurring problems are outdated or hallucinated dependencies, missing input validation, insecure defaults, subtle logic errors that pass superficial tests, and licence contamination. Treat generated code as a confident junior's pull request.
What the research found
Studies of AI coding assistants since 2021 have reached a consistent set of findings. A meaningful share of generated code contains security weaknesses, with estimates in various studies ranging from a quarter to over forty percent of samples for security-relevant tasks, concentrated in the classic categories: injection, weak cryptography, hard-coded secrets, path traversal, missing authorisation. Developers using assistants have been found to write less secure code than those without, while believing they had written more secure code. And the assistants' output quality tracks the quality of the code they were trained on, which is the public internet, where the median example is not good.
None of this makes the tools unusable. It makes them a source of code that needs the same scrutiny as any other source, and slightly more, because it arrives looking finished.
Why plausible is the dangerous property
Generated code compiles, runs, passes the obvious test, and reads well. A junior developer's mistakes tend to be visible; a model's mistakes tend to be idiomatic. The function that validates input on every path but one, the SQL query that is parameterised except for the sort column, the authentication check that is present in the handler but absent in the helper called from another route. These are the errors that survive a glance, and a glance is what generated code tends to receive because it looks like it does not need more.
The related risk is vibe coding: accepting output without reading it because it works. It works until the input nobody tried, and then nobody on the team knows how the code that failed was supposed to behave.
The five recurring failure modes
1. Dependencies that are outdated, wrong, or do not exist. Models suggest libraries and versions from their training data, which may be years old, deprecated, or vulnerable. They also invent package names, which attackers have registered with malicious code in anticipation. Every dependency a model suggests must be checked against the real registry and its current advisories.
2. Missing validation and authorisation. Generated handlers frequently trust input and skip the check that the current user is allowed to act on the resource. The code for the happy path is complete; the code for the adversarial path is absent. This is where injection and broken access control come from.
3. Insecure defaults and secrets. Example credentials, permissive CORS, debug flags left on, tokens in source, TLS verification disabled to make a test pass. Models reproduce the shortcuts that appear in tutorials.
4. Logic that is subtly wrong. Off-by-one boundaries, time-zone handling, currency rounding, race conditions, error paths that swallow failures. These pass the tests the model also wrote, because the tests encode the same misunderstanding.
5. Licence contamination. Models can reproduce substantial passages of copyrighted or copyleft code. For most application code the risk is small; for anything distributed or open-sourced, it deserves a check.
The discipline that makes it safe
Read it. Every line, by someone who could have written it. If nobody on the team can evaluate the code, the team should not be shipping it, generated or not.
Review it like an external contribution. The code review standard for a pull request from a stranger: what does it do, what could go wrong, what did the author not consider. Generated code is a pull request from a stranger with excellent manners.
Test the adversarial path. Wrong input, missing input, another user's ID, a request out of order. The model tested the path it was asked for; the reviewer tests the path an attacker would try.
Verify every dependency. Name, version, maintenance status, known vulnerabilities, licence. Automated scanning catches most of it; a human catches the invented package.
Run the security tooling. Static analysis, dependency audit, secret scanning, in CI, on every change. These catch the categories models get wrong most often and cost nothing to run.
Keep humans on the design. Use the assistant for implementation within an architecture a person decided, not for deciding the architecture. Models are good at filling in a well-specified function and poor at noticing that the function should not exist.
Document what was generated. In the commit or the review, so that when it fails, the next person knows to look harder.
What this means for teams
Used this way, AI assistants make a competent team faster without making it less safe, and we use them daily. Used as a substitute for competence, they produce codebases that work until they do not and that nobody understands when they fail. The difference is not the tool; it is whether the review step was kept. A team that would not merge a colleague's code unread should not merge a model's.
If you have inherited a codebase built largely by AI and want to know what is in it, book a call; a pre-launch security review is the usual starting point.
Common questions
Is AI-generated code secure?
Not by default. Studies have found security vulnerabilities in a substantial share of AI-generated code for security-relevant tasks, in the classic categories of injection, weak cryptography, hard-coded secrets and missing authorisation, and developers using assistants have been found to over-trust the output. It becomes secure through the same review, testing and scanning any code needs.
What are the risks of using AI to write code?
Outdated or invented dependencies, missing input validation and authorisation checks, insecure defaults copied from tutorials, subtle logic errors that pass the tests the model also wrote, and occasional reproduction of copyrighted code. The common thread is that the output looks finished and receives less scrutiny than it needs.
Can I use AI-generated code in a commercial product?
Yes, and most software teams now do. The obligations are the same as for any code: review it, test it, verify its dependencies and licences, and ensure someone on the team understands it. Check your assistant's terms regarding ownership of output and, for anything you distribute or open-source, screen for reproduced licensed code.
How do I review AI-generated code?
As you would a pull request from an unfamiliar contributor: read every line, ask what each part does and what input would break it, test the adversarial paths the model was not asked about, verify every dependency exists and is maintained, run static analysis and secret scanning, and confirm the design decision was a human's.
Does AI-generated code have copyright problems?
Occasionally. Models can reproduce substantial passages from training data, including copyleft-licensed code, and the copyright status of purely generated code is unsettled in many jurisdictions. For typical application code the practical risk is low; for distributed software or open-source releases, run a licence scan and check your assistant's terms on output ownership.
