Is AI-Generated Code Safe? The Real Risks and What Changes With Review
Date Published
Yes, once a qualified engineer reviews every line, tests it, and checks its dependencies. No, straight from the model. The difference is not the AI. It is whether anyone checked the work before your business depended on it.
That answer is short on purpose, because the question deserves a straight one before anything else. The rest of this guide is the long version: what actually goes wrong when AI-generated code ships unreviewed, what a real review process catches, and what to ask a vendor before you trust them with it. If you landed here from our broader explainer on vibe coding and AI-assisted development, this page is the deep dive that question gets one paragraph in over there.
The Honest Risk List: What Actually Goes Wrong in Unreviewed AI Code
An AI model does not know your business, and it does not carry consequences for getting something wrong. It predicts plausible-looking code from patterns in its training data, and "plausible-looking" is not the same claim as "correct" or "safe." Four failure modes show up again and again in code nobody reviewed.
Security vulnerabilities. Large language models learned from public code, including the mistakes in it. Veracode's 2025 GenAI Code Security Report found that 45% of AI-generated code samples contained known security vulnerabilities: missing input validation, injection-prone database queries, hardcoded credentials sitting in plain text. None of these are exotic bugs. They are the same mistakes junior developers have always made, generated at a pace no human ever matched.
Hallucinated dependencies. Ask an AI model to solve a problem and it will sometimes recommend a software package that does not exist. It looks like a normal import statement, it reads as plausible, and it is fictional. A 2025 USENIX Security study found roughly 5.2% of packages suggested by commercial models were hallucinated, rising to about 21.7% for open-source models. Attackers have caught on: they register real packages under those exact hallucinated names, so the next developer who "fixes" the import error installs malware instead. Security researchers now call this slopsquatting, and unreviewed vibe coding sessions are its natural habitat.
Subtle logic errors. Not every failure announces itself with a crash. A discount calculation that rounds the wrong way on one currency, a date filter that silently drops the last day of the month, a permissions check that works for every role except the one nobody tested: these bugs ship clean, run for weeks, and surface only when a customer notices the total is wrong. An AI model has no stake in catching them, because it already produced an answer that looks finished.
Maintainability debt. Code that nobody understands is a liability even when it works today. AI models regularly duplicate logic instead of reusing it, because each prompt is answered fresh with no memory of what the codebase already contains. Six months in, a small change in one place breaks something unrelated, and the team debugging it has no author to ask why the original code did what it did.
None of this is an argument against AI-written code. Every one of these four problems is exactly what a review step exists to catch, and none of them require exotic tooling to find, just a person who reads the output before it ships.
What Changes When AI-Generated Code Gets Reviewed
Reviewed AI-assisted code is a different product from vibe-coded output, even when the same model wrote both. Two practices do the actual work.
A human engineer reads every line. Not a sample, not the parts that "look risky": every line, before it merges. Architecture decisions, security boundaries, and edge cases stay review decisions, never accepted on the model's word. This single step is what catches the hardcoded key, the missing validation, and the import that points to a package that does not exist. Our own version of this practice, sprint by sprint, is described in full on how we scope, build, and review.
Dependency scanning runs on every build. Every push and pull request triggers automated dependency scanning, Dependabot plus a dependency audit in the CI pipeline, so a package carrying a known moderate-or-higher advisory fails the build rather than reaching production. This is where a hallucinated or compromised dependency gets caught even if a reviewer misses it in the diff.
One thing worth being direct about, because vendors are not always direct about it. We do not offer penetration testing as part of a standard build. If a project needs an independent security assessment, we name that during scoping and help arrange one, the same disclosure our security page makes in full.
That candor is the point. A vendor who tells you exactly which checks run, and which do not, is one whose other claims you can trust. A vendor who waves at "enterprise-grade security" without naming a single practice is asking you to take the same leap of faith an unreviewed AI model already takes on its own output.
How to Evaluate a Vendor's Real Security Practices
Every AI development shop will tell you their code is safe. Few can describe how they know. Bring these questions to a scoping call and listen for specifics, not adjectives.
- Who reads the code, and when? You want a named role (a senior engineer, not "the team") and a stage (before merge, not "eventually"). "Our process reviews it" is not an answer; "an engineer reads every line before it merges" is.
- What tools run on every build, and what do they actually check? Dependency scanning is common and checkable: ask which tool, and whether a failed check blocks a release or just logs a warning.
- What do you not do? A vendor who names their gaps, no penetration testing as standard, no certification held, whatever theirs happen to be, is telling you something true. A vendor with no gaps at all is not being reviewed by anyone, including you.
- Who owns the code once it ships? Security and ownership are related questions. A vendor who assigns you full code ownership has no incentive to hide a shortcut in a codebase they will hand you outright.
- Can I bring my own technical advisor to the call? A vendor confident in their practices welcomes a second set of eyes. One who resists the idea is telling you something too.
We built our own security page around this exact test: state the practices plainly enough that your advisor can check them, and say clearly what we do not do. Put any vendor's claims, including ours, through the same filter.
Red Flags: When a Vendor Cannot Answer These Questions
Some answers are worse than no answer.
"Our AI writes secure code by default." No model does. This claim contradicts the Veracode finding above and every other independent study on the subject. A vendor repeating it either has not read the research or is hoping you have not.
Vague reassurance instead of a named practice. "We take security seriously" and "enterprise-grade protection" describe nothing checkable. Ask what those phrases mean in practice, and watch whether the answer gets more specific or more abstract.
Certifications nobody can produce. "Bank-grade" and "military-grade" are marketing adjectives, not standards. If a vendor claims SOC 2, ISO 27001, or a similar certification, ask to see it. If they cannot produce it, they do not hold it.
No answer to "what do you not do." Every real security practice has a boundary. A vendor who cannot name theirs is not being more secure. They are being less specific, which is a different thing dressed up to look the same.
Silence on who reviews the output. If a vendor cannot describe their review process in one clear sentence, one probably does not exist. That single gap outweighs almost anything else on this list, because it is the practice every other safeguard depends on.
Frequently Asked Questions About AI Code Security
Is AI-generated code safe to use in production?
It can be, once an engineer reviews every line, dependencies are scanned, and the software is tested against real acceptance criteria. It is not safe by default. Unreviewed AI code regularly ships with the exact vulnerabilities the section above describes.
What is the biggest security risk with AI-generated code?
Missing or weak input validation and hardcoded credentials are the most common findings, present in 45% of samples in Veracode's 2025 study. Both are old, well-understood mistakes that any code review process is built to catch.
Can AI-generated code contain fake or hallucinated dependencies?
Yes. Models sometimes recommend software packages that do not exist, a documented issue researchers call package hallucination. Attackers register real packages under those names, so installing the "fix" can install malware. Dependency scanning and review both catch this.
Do automated tools alone make AI-generated code safe?
No single tool guarantees safety. Human review of every line and automated dependency scanning are the practices doing the real work at Globaprom today. Ask any vendor exactly which checks run and which do not, rather than trusting a tool list alone.
How do I know if a software vendor actually reviews AI-generated code?
Ask who reads the code and when, in one sentence. A real answer names a role and a stage: an engineer, before every merge. A vendor who cannot answer that specifically likely has no review step at all.
Is AI-generated code more or less safe than code a human writes from scratch?
Neither, on its own. Safety comes from review and testing, not from who or what typed the first draft. Reviewed AI-generated code and reviewed human-written code both end up safe for the same reason: someone checked.
Ask the Hard Questions Before You Sign
The safest position with any vendor, us included, is to ask exactly who reviews your code and what happens when a check fails. Describe what you need built, and we will answer both questions on the first call, alongside a fixed scope, a fixed price, and a delivery date.