AI-generated code is not the risk. Unreviewed code is.
AI now writes a large share of the code in many products, from vibe-coded prototypes to enterprise systems built by AI-native teams. Used well, it is a genuine advantage. Used carelessly, it ships security holes and code nobody understands. Here are the main risks and the controls that manage them.
The six main risks of AI-generated code
AI-generated code fails in recognisable ways. None of them are exotic, but they appear faster and at greater volume than with human-written code, and they often look perfectly plausible.
Security vulnerabilities
Missing authorisation checks, unsafe handling of user input, secrets written into code, and permissive defaults that work in a demo and fail an attacker test.
Invented or risky dependencies
Models sometimes suggest packages that do not exist or are outdated. Attackers register fake package names in the hope that someone installs them.
Licensing and IP uncertainty
Output can resemble existing open-source code with licence obligations, and rules on ownership of AI-generated work vary by jurisdiction.
Maintainability
Duplicated logic, inconsistent patterns and code accepted because it passed a quick check. It works today and becomes expensive to change tomorrow.
Quietly wrong behaviour
Edge cases, time zones, rounding, concurrency and error handling are frequently mishandled, and generated tests may simply confirm the same mistake.
Data leakage through tools
Proprietary code, credentials or customer data pasted into AI tools without clear data terms can end up somewhere you did not intend.
How much AI-generated code risk is acceptable?
The same code can be fine in one setting and dangerous in another. Match the level of control to what the software touches.
| Throwaway prototype | Internal tool | Customer-facing production | |
|---|---|---|---|
| Acceptable risk | High, if no real data | Moderate | Low |
| Review needed | Light sanity check | Engineer review of key paths | Senior review of every change |
| Security testing | Keep it off the public internet | Access control and dependency scans | Scanning, threat review, penetration testing |
| Tests | Optional | Core workflows covered | Meaningful automated coverage, reviewed by humans |
| Licensing checks | Not critical | Basic dependency licence scan | Licence scanning and clear IP terms in contracts |
The most common failure is a prototype that quietly becomes production. When real users or data arrive, the controls must move one column to the right.
Practical controls for using AI-generated code safely
None of these ban AI. They make sure the speed it brings does not come at the cost of your security, customers or future flexibility.
A named human reviews and owns every change
If the reviewer cannot explain what the code does and why, it is not ready to merge, however well it appears to work.
Automated security and dependency scanning in the pipeline
Static analysis, secret detection and checks that every package exists, is maintained and has an acceptable licence.
Tests written against requirements, not against the code
AI can generate tests quickly, but a person should confirm they check what the business actually needs, including edge cases.
Clear rules for what goes into AI tools
Approved tools on business terms, no credentials or customer data in prompts, and settings that prevent your code being used for training.
Consistent architecture and conventions
Documented patterns that agents are instructed to follow reduce the drift and duplication that turn into technical debt.
Contracts that address AI use
Vendor agreements should assign IP to you, disclose AI tool usage and confirm how licensing risk in generated code is handled.
Why AI-native teams can still ship safer code than traditional ones
It is tempting to conclude that AI-generated code is inherently worse. In practice, the outcome depends on the process around it. A disciplined AI-native team can use the time AI saves on routine implementation to write more tests, review more carefully and run more security checks than a traditional team under deadline pressure ever managed.
The risky pattern is speed without structure: a founder building an entire product with an AI app builder and no engineering review, or a development team measured purely on output that merges generated code in bulk. That is where exposed databases, broken access controls and unmaintainable codebases come from.
If you already have software written largely by AI, the sensible next step is not panic or a rewrite. It is an independent look at authentication, data handling, dependencies and the parts of the system that change most, followed by a prioritised list of fixes.
Questions we often hear
Is AI-generated code safe?
AI-generated code can be safe when it goes through the same controls as any other code: human review, automated tests, security scanning and dependency checks. Without those, it often contains plausible-looking flaws such as missing access checks or unsafe input handling. The risk lies in the process, not the origin of the code.
Who owns the copyright of AI-generated code?
It depends on the jurisdiction and how much human creative input was involved, and the law is still developing. In practice, businesses protect themselves through contracts that assign all work product to them, AI tool terms that grant output rights, and licence scanning. Take legal advice for high-value or contested IP.
What are the security risks of vibe coding?
Apps built largely by prompting AI tools without engineering review commonly ship with weak authentication, open database rules, exposed API keys and no rate limiting. They work well in a demo and become risky once real users and personal data arrive. A security review before launch catches most of these issues.
How do you review AI-generated code?
Review it as if a new, fast but inexperienced developer wrote it. Check that it meets the requirement, handles errors and edge cases, enforces permissions, uses real and maintained dependencies, and follows your existing patterns. If the reviewer cannot explain the code, it should be simplified or rewritten.
Can AI-generated code violate open-source licences?
It is possible for generated code to closely match existing licensed code, which could bring licence obligations. Some AI coding tools offer filters for matches with public code, and licence scanning tools can check dependencies and snippets. The risk is generally low for routine code but worth managing for commercial products.
Related reading and tools
Concerned about AI-written code in your product?
Tell us how the software was built and what it handles. We will point out the likely risk areas, suggest proportionate controls, and say honestly whether a full review is warranted.
Working with companies globally · Response within 24 hours