AI-generated code can work well in a demo because the application only needs to demonstrate its intended functionality. Production introduces a different set of requirements, including access control, credential protection, error handling, and recovery procedures. These become more important as the product starts handling real customer data and transactions.
The difference often becomes apparent when the first paying customers arrive, an enterprise pilot begins, or an investor requests technical due diligence. At that point, demonstrating that the application works is no longer enough. The team also needs evidence that it can operate securely and recover from failures.
If you built with Lovable, Bolt, Replit, or Cursor, review the five common failure points for AI-built products, the four stages to production, who should review the code, and which EU rules apply.
Tl;DR
AI-generated code is not automatically production-ready. A working demo confirms that the expected user flow runs, but not that access controls, customer data, integrations, or recovery procedures are safe. Before production release, verify those areas through engineering review, testing, and documented remediation.
- Check five points before real users arrive: access control, API and dependency integrity, personal data, error handling and monitoring, maintainability.
- Get the review from someone who did not write the code; asking the same AI tool repeats its blind spots.
- Fix isolated defects when the architecture is sound. Refactor recurring structural problems. Rebuild a core component when essential security controls cannot be supported or when a documented assessment shows replacement carries less cost and risk than targeted remediation.
What AI generated code is, and what changes when real users arrive
AI-generated code is code written by AI tools from natural-language prompts, from a single function to a complete application. App builders such as Lovable, Bolt, and Replit produce a working product from a description. Cursor works inside an existing codebase, next to a developer.
AI-assisted coding and AI-built products involve different levels of human oversight. In AI-assisted development, developers use AI suggestions while retaining responsibility for reviewing and integrating changes. By contrast, an AI-built product may contain substantial amounts of generated code that have received limited human review. This distinction matters because security requirements that were missing from the original prompts may also be missing from the implementation. The risks discussed below are particularly relevant when that independent review has not taken place.
Tools are rarely the main weakness. The problem is usually in the specification. Most prompts define expected user behavior but do not cover cases like one customer accessing another’s data or a payment provider failing during checkout.
| Dimension | Prototype | Production |
|---|---|---|
| Users | You and a few testers | Paying customers who do unexpected things |
| Data | Test data | Personal data covered by the GDPR |
| Traffic | One session at a time | Concurrent users, bots and automated scans |
| Failure cost | Restart the demo | Lost customer data, a breach report or a lost contract |
| Who checks | Builder or internal team, primarily for functionality | A reviewer before launch, monitoring after it |
If any cell in the production column already describes your product, you are in production, whatever the version number says.
Is AI generated code safe to put in production?
Not by default. AI-generated code is safe for production once someone has checked what it does with users, data and secrets. A working demo proves that a feature works. It does not prove that the feature is safe.
The SusVibes study published at ICML 2026 evaluated 186 security-sensitive software engineering tasks drawn from real-world open-source projects. In one tested configuration (SWE-agent with Claude 4 Sonnet), 57% of generated solutions passed functional tests, but only 11.8% passed both functional and security tests. Among functionally correct solutions, 79.3% failed the security checks.
These results concern deliberately selected security-sensitive tasks, not the vulnerability rate of complete AI-built applications. They do not mean 79.3% of AI-built apps are insecure. They show why passing functional tests is not sufficient evidence of production security.
The pattern is not new. Pearce et al. tested GitHub Copilot in security-relevant scenarios and found about 40% of the generated programs vulnerable (Communications of the ACM, February 2025; first presented at IEEE S&P 2022). Newer models write more working code, but SusVibes shows that security did not improve at the same pace.
The practical threshold: once real personal data or payments flow through the product, an unchecked AI-built app carries risk you cannot see from the screen.
Where AI-built products break: five failure points
Most problems in AI-built products fall into five areas. Each area below gives a plain definition, the questions to ask your developer or builder, and the red flags you can notice without reading code. One red flag is enough reason to get the product reviewed before launch.
Access control: users who can see other users’ data
Access control is the set of rules that decides who may see or change what in your product. Broken access control is the number one risk in the OWASP Top 10:2025. In AI-built products, it often looks fine on screen: the interface hides another customer’s data, but the server still returns it to anyone who asks. More detail follows in vibe coding security risks.
Questions to ask your team
- Which user roles exist in the product, and what may each role see or change?
- Is every permission checked on the server, or is data only hidden in the interface?
- Who has admin access today, and is each admin account tied to a named person?
Red flags
- A tester or customer mentions seeing someone else’s name, order or invoice.
- A page opens for anyone who has its link, without logging in.
- Several people share one admin login.
API and dependency integrity: leaked keys and unchecked add-ons
Your product depends on outside services and outside code. Payment, email and AI providers are reached through API keys, and the AI tool adds open-source packages that the product needs to run. OWASP Top 10:2025 lists this risk as A03 Software Supply Chain Failures.
AI-built products often rely on third-party services and open-source packages, which introduce two areas that need separate checks. The first is credential protection. API keys can grant access to paid services or sensitive data, so storing them in shared documents, chat messages, or AI prompts can expose the accounts they protect. The second is dependency security. Even when credentials are handled correctly, outdated or unmaintained packages may introduce vulnerabilities into the application. Reviewing both areas requires an inventory of external services, a secure credential-storage process, and regular dependency scanning.
Questions to ask your team
- Which outside services and packages does the product rely on, and who owns each account?
- Where are the keys stored, who has a copy, and when were they last replaced?
- Has any key ever been pasted into a chat, an email, a shared document or an AI prompt?
Red flags
- Your bill from an AI, email or payment provider shows a spike nobody can explain.
- Keys sit in chat messages, emails or shared documents, and nobody has replaced them since.
- Service accounts are registered to a former freelancer’s personal email address.
- Nobody can say when the packages in the product were last updated.
Personal data: collected by default, never deleted
Personal data is any information that identifies a person, such as a name, an email address or payment details. GDPR Article 25 requires data protection by design and by default: collect only what you need, and protect it from the start. AI-built products tend to store everything a form sends and offer no way to remove one customer completely.
Questions to ask your team
- Which personal data does the product collect, and why does it need each field?
- Which third-party tools receive customer data?
- How does the product handle valid erasure requests across live systems, third-party services, and backups, including preventing deleted data from being restored into active systems?
GDPR Article 17 provides a right to erasure under defined conditions, with exceptions where continued retention is legally justified. For backups, the review should check retention periods, access restrictions, deletion procedures, and safeguards that prevent erased data from returning to active systems during recovery. A valid erasure request needs a documented response, not an assumption that every backup can be modified immediately.
Red flags
- A customer asks to be deleted and nobody knows how long it takes or where their data lives.
- Sign-up forms ask for more than the product needs.
- Real customer data has been copied into test or demo versions.
Error handling and monitoring: failures nobody sees
Error handling defines how the product responds when something fails. Monitoring shows your team that a failure happened. OWASP Top 10:2025 highlights both issues: A09 Security Logging and Alerting Failures and A10 Mishandling of Exceptional Conditions. In AI-built products, failures can go unnoticed until a customer reports them.
Questions to ask your team
- Who gets an alert when the product fails, and how fast?
- What does a user see when a payment or a form fails?
- Can the team see what went wrong yesterday, and how long are those records kept?
Red flags
- You hear about outages from customers before your team notices.
- A payment or form fails without telling the user what happened.
- Nobody can say what went wrong yesterday, because nothing records it.
Maintainability: every change breaks something else
Maintainability is how easily the product can be changed without breaking what already works. AI tools tend to repeat logic instead of reusing it, and they rarely write automated tests unless asked. The result shows after launch: the next change breaks two features that worked yesterday. Managing that cost is covered in ai technical debt.
Questions to ask your team
- Could a developer who did not build the product make a change next week?
- Which parts of the product have automated tests, and who wrote them?
- How much of last month’s work went into fixing things that used to work?
Red flags
- Small changes take longer every month.
- Fixing one thing regularly breaks another.
- Only the person who built the product, or the AI tool itself, can make changes.
- Your developer reports that all tests pass, but the same AI tool wrote those tests.
Figure 2. Five points where AI-built products break
From vibe coding to production: four stages
Taking AI-generated code to production takes four stages: inventory what you have, get an independent review, fix what blocks launch, and release with monitoring and a way back. Before you start, make sure you have admin access to the code repository, the hosting account and every third-party service the product uses.
Stage 1: Inventory what you have
The goal is a one-page overview. It answers four questions: which tool built the product, where data is stored, which third-party services hold keys and who has admin access. The stage is done when one person can answer all four without logging in to check.
Stage 2: Get an independent review
The goal is an outside view of the code, with engineering and security checked together. The output is a list of findings ranked by launch impact, not by technical severity alone. What a production readiness review covers is explained separately.
Stage 3: Fix what blocks launch
Treat confirmed unauthorized access to sensitive data, exposed production credentials, and failures that create unacceptable privacy or transaction risk as release blockers. Record lower-risk findings with an owner, a remediation deadline, and a clear decision on whether a restricted launch is acceptable. Use a production readiness checklist to confirm nothing was missed.
Stage 4: Release with monitoring and rollback
A rollback returns the product to the last working version. Release to a small group first, such as pilot customers, with alerts switched on. The stage is done when you have tested a rollback once before launch day. The ai deployment checklist lists the release steps. The same four stages apply to any AI prototype to production move, whoever built the first version.
Figure 3. Four stages from prototype to production
| Not sure which stage your product is in? An AI-built product review gives you a written answer: what blocks launch, what can wait, and where the effort goes. Engineers and security specialists review the code together, and the findings are explained in plain English. → Book an AI-built product review |
Who should review AI generated code (and why the AI can’t review itself)
Asking the AI tool that wrote the code is useful as a first pass. It checks the code against the same assumptions it wrote it with, and it does not know your users, your data or your contracts.
The SusVibes researchers also tested whether security-specific instructions improved the results. With SWE-agent and Claude 4 Sonnet, asking the agent to identify potential vulnerabilities increased secure, functional solutions from 11.8% to 14.5%, but functional correctness fell from 57% to 50%. Providing the exact vulnerability type increased secure, functional solutions to 15.1%, while functional correctness dropped to 55.4%.
These findings suggest that security-focused prompting can improve some generated solutions, but it is not sufficient as the final production check. A more reliable review process combines different methods because each identifies a different class of problem. Static application security testing (SAST), for example, can flag known risky code patterns, while dependency scanners identify known vulnerabilities in third-party packages. However, automated tools may miss application-specific authorization rules, such as whether one customer can access another customer’s records. Those checks require tests based on the product’s actual roles, data flows, and business requirements.
| Option | What it catches | What it misses | When to use |
|---|---|---|---|
| Ask the AI tool | Obvious bugs and missing checks you prompt it about | Your users, data rules and contracts; its own blind spots | Daily, as a first pass |
| Automated scanners (SAST, dependency scan) | Known risky patterns, outdated libraries, some exposed secrets | Business logic and who should see what | Continuously, from day one |
| Freelance developer | Code quality and bugs in the parts they read | Security, unless that is their specialism; independence if they also quote the fix | Small codebase, one feature |
| Independent product review | Access rules, data handling, architecture and security together, ranked by launch impact | Live attack simulation against the running system | Before the first paying customers or an enterprise pilot |
| Penetration test | What an attacker can do against the running system | Why the issue exists and how maintainable the code is | When a customer or regulator asks for a test report, or after fixes |
Use scanners from day one to catch issues early. Arrange an independent review before real users join to reduce onboarding risk. Run a penetration test when required by a customer contract.
After launch: fix, refactor or rebuild?
Fix isolated defects when the architecture is sound. Refactor when duplicated logic or tightly coupled components make changes repeatedly break other features. Consider rebuilding a core component when its architecture prevents essential security controls or when targeted remediation would cost more and introduce greater risk than replacement.
| Signal you can observe | What it usually means | Recommendation |
|---|---|---|
| Findings sit in two or three modules; tests can be added | Local problems in a sound structure | Fix |
| The same bug class appears across the codebase; no automated tests | Repeated logic, no safety net | Refactor |
| Changes regularly break unrelated features | Coupled code that resists change | Refactor |
| Records are not linked to the account or organisation that owns them | The data model cannot express who owns what | Rebuild the core |
If the rebuild signal applies, decide before launch: changing the data model after customers arrive also means migrating their data.
What a review costs and how to choose a provider
Review cost depends on five factors: codebase size, number of integrations, scope of personal data, need for a written report, and requirement for a re-test. The use of AI in code does not change the price.
To compare providers, check if review and remediation are separate, if engineers and security specialists collaborate, if the report is clear for non-technical founders and if findings are ranked by launch impact.
EU obligations that apply to your AI-built product
The regulatory obligations for an AI-built product depend on what the product does, what data it processes, and who uses it, rather than simply how its code was generated.
If the application processes personal data within the GDPR‘s scope, the relevant data protection and security obligations apply regardless of whether a developer or an AI tool wrote the code. For companies supplying larger organizations, security requirements may also arise through customer contracts and supplier assessments. NIS2 Article 21, for example, requires organizations within its scope to address supply-chain security risks, which can lead to security questionnaires and evidence requests for their software vendors.
The EU AI Act raises a different question. Its applicability depends on whether the product includes AI systems covered by the Act and the relevant obligations, not merely on whether AI-generated code was used during development.
Rules for AI-written code once your team grows
Once more than one person prompts code into the product, three rules prevent most problems. The 2025 DORA report from Google Cloud found that AI use now raises delivery speed but still increases delivery instability. The first capability it names for teams using AI is a clear, communicated position on what AI use is expected and allowed.
- Name who may merge changes to production, and require one reviewer per change.
- Decide which data may go into prompts: no customer personal data and no keys.
- Review before every release, not after a customer reports a problem.
How Sunbytes reviews AI-built products
An AI-built product does not necessarily need a complete rebuild before entering production. The first step is to understand which parts of the application can be retained, which weaknesses require attention, and whether the existing architecture can support real users securely. This assessment helps founders avoid unnecessary redevelopment while identifying issues that could affect the product after launch.
At Sunbytes, this assessment brings software engineering and security expertise into the same review process. Through Digital Transformation Solutions, engineers examine the codebase, architecture, integrations, and data model to identify technical limitations. They work alongside Cybersecurity Solutions specialists, who assess access controls, API credentials, dependencies, and personal-data handling against the application’s actual requirements. By evaluating these areas together, the review can distinguish isolated vulnerabilities from structural problems that require broader changes.
The findings then inform a prioritized remediation plan based on exploitability, data sensitivity, and business impact. Some issues can be resolved through targeted fixes, while others may require refactoring or replacing specific components. If the existing team lacks the capacity to complete that work, Accelerate Workforce Solutions can provide senior engineers to support remediation. Importantly, the review remains separate from the remediation engagement, allowing founders to assess the findings before deciding how to proceed.
With 15+ years of experience, 300+ projects delivered, and ISO/IEC 27001:2022 certification under Netherlands-led governance, Sunbytes combines engineering delivery with structured security assessment. The outcome is a clearer decision on what must be fixed before launch, what can be addressed later, and where further development effort is justified.
Book an AI-built product review to identify the risks and technical changes that need attention before your next release.
