Vibe Coding Risks: Security, Maintainability, and Production Readiness

An app built by prompting an AI agent to generate code can look completely finished and still pose real security risks, such as an authentication check that was never written or a secret sitting in a config file. None of that shows up in the demo. It surfaces once someone with the wrong intentions takes a look.

Vibe coding security is the most visible risk, but it's not the only one. The same speed that makes vibe coding attractive doesn't pause to check whether an app can hold up operationally and stay maintainable after the person who built it moves on.

This article covers the checks worth running before a vibe-coded app takes on real data or business responsibility, three examples of where the risk starts, and the paths available once the review is done.

When Does a Vibe-Coded Prototype Become a Business Risk?

Vibe coding is the process of prompting an AI coding agent until an application does what you want, with little of the manual coding that traditional software development requires. What actually matters for risk, though, isn't how the app was built. It's what changes once it's no longer a demo.

Picture three examples, each low stakes at first:

• A mockup using sample data to show what a new dashboard could look like. The turning point comes when it starts pulling in live data instead of samples.
• An internal request form that lets employees submit time-off requests, initially just logging them to a spreadsheet. The turning point comes when it gains permission to actually update company records.
• A customer-facing portal showing order history and account details. The turning point comes when it opens up to real customers instead of a handful of internal testers.

None of these projects starts out dangerous. What changes each one is the same thing showing up in a different form, whether that's real data, real permissions, or real users replacing a safe stand-in.

What actually matters is an app's users, its data access, what it's integrated with, and how much a workflow now depends on it, not whether the demo looked polished. An internal tool is not automatically low risk either. Handling sensitive data or making changes to important records can carry just as much risk as anything customer-facing.

What Should Teams Check Before Launch?

Professional and citizen developers now use AI coding tools to turn natural-language prompts into working software through rapid iteration, often without the human oversight that security teams would normally expect. This is AI-assisted development at its fastest, and speed doesn't pause for the usual checks.

The speed at which AI generates code compresses traditional security processes like writing, reviewing, and shipping into a single vibe coding loop. That means problems that a slower process would normally catch, like security flaws or missed edge cases, can ship straight to production instead. Traditional AppSec tools (application security) still help, but they weren't built for the pace vibe coding tools now move at. They can also miss logic flaws that only surface once someone understands what a feature is actually supposed to do.

Securing vibe coding output starts with the same five questions any production app should answer.

1. What data can the app access, and who can use it?

Start with data sensitivity, credentials, authentication, security controls, and permissions. Has this actually gone through human review, like code review on a pull request, or just automated checks? Has access been tested for users who shouldn't be able to see or change something, not just the users who are supposed to?

Data sensitivity isn't just an internal judgment call, either. An app that touches health records, payment data, or personal information may fall under regulations like HIPAA, SOX, or GDPR, and meeting them can require real architectural changes rather than a policy checkbox.

Example code copied from a prompt's first draft isn't inherently secure code. Insecure code tied to authentication logic is one of the easiest things to miss in a quick review. AI models trained on massive amounts of training data can reproduce insecure patterns and other security vulnerabilities without anyone intending it.

A widely cited NYU study found GitHub Copilot generated exploitable bugs or security-relevant design flaws in about 40% of test cases, and the BaxBench benchmark found that 62% of solutions from even the best-performing model were either incorrect or contained a security vulnerability. Treating AI-generated code as safe just because it works is how those patterns slip through.

Document what data and systems the app can reach, which roles have permission to use it, and what the access tests found.

2. Does it handle business rules and failures correctly?

Testing the intended path only tells you the happy case of the business logic working. Try invalid inputs, missing information, conflicting actions, and failed requests too. Under expected use, including concurrent actions or a traffic spike where that's relevant, does the app still behave the way it should?

Software defects and insecure logic buried inside an otherwise working feature rarely show up until someone tests the paths nobody thought to try. An AI-generated function can pass every test someone thought to write and still fail the one nobody did.

Think through what happens if the result is simply wrong, especially for anything processing orders, approvals, or account changes. Record which scenarios got tested and which failures are still unresolved. "It runs" and "it produces the right outcome consistently" are two very different findings, and it's easy to mistake one for the other.

3. What happens when an integration breaks?

Identify every system the app reads from or writes to, including any cloud resources it can create, modify, or delete along the way. Look for incomplete updates, duplicated actions, inconsistent data, and error messages that actually help someone understand what went wrong. Can the team detect a failed integration and recover from it safely?

Document the integrations themselves, what the failure tests turned up in test environments, and how the team would correct or reverse an action that was only partly completed.

4. Can another person maintain it?

How AI-generated code got built matters just as much as whether it works. An AI-generated app that nobody can explain is harder to maintain than existing code or human-written code that's already been through a team's normal process.

Version control that tracks each round of code generation gives a future maintainer a paper trail that prompts alone don't provide, and each new batch of AI-generated code should have someone accountable for reviewing it before it ships.

Someone besides the original builder needs to be able to explain the important code paths, dependencies, and design decisions, not just recall roughly what a prompt or a set of development tools was supposed to do. Look for tests that make future changes safer, and an owner who's actually responsible for keeping the application running.

Verify that both the owner and at least one other qualified team member can figure out how to change the app without leaning on the original builder's memory or prompt history. A manual review by someone unfamiliar with the project is a good test of this.

5. Can the team support it after launch?

Confirm who actually receives alerts, investigates incidents, approves changes, and handles updates once the app is live. Where will it run, how will changes actually reach production systems, and how would the team identify and roll back a bad release? Runtime visibility, actually being able to see what the app is doing once it's live, matters here as much as it did during testing.

Check whether the team can restore service after an outage, not just detect that one happened. Record the support owner, the alerting setup, and the release and recovery steps. Ongoing support belongs in launch readiness from the start, not as a task someone assigns after the first incident.

What Should You Do After the Risk Review?

Engineering review doesn't always mean small fixes. It can lead to real changes, a substantial rebuild, or switching to a different implementation approach entirely.

There's no rigid risk score that makes this decision automatic. What matters is having real evidence behind whichever path gets chosen, and someone who actually signs off on it. The application owner should pull in engineering and security reviewers as the app's risk level calls for it.

Where Can Liferay DXP Fit Into the Decision?

When a review points toward building something different rather than patching what exists, the next question is what to build it on. A lot of what a review actually flags, unclear data ownership, missing approval steps, permissions nobody fully mapped out, are gaps a governed platform is built to close by default, not problems a team has to design and prove out on its own.

Liferay DXP addresses this through:

• Objects that give structured data a defined shape, owner, and history from the start
• Forms that capture input with validation and permissions already attached
• Workflows that route approvals through steps a team can see and audit
• Roles and permissions that control access at the platform level, not buried inside application code
• APIs and integrations that connect to existing systems through a supported, tested path

None of this removes the need for judgment. A team still has to decide what actually belongs on the platform versus what genuinely needs custom development, and any custom piece still needs the same review and testing as everything else. What changes is the starting point. Instead of proving out permissions, approvals, and integrations from nothing, a team building here starts from something that already passed that bar.

Make the Production Decision Deliberately

The real question isn't whether an app looks finished. It's what would have to be true for this particular app to be safe to actually rely on. The right path depends on its purpose, what it's exposed to, and how long it's expected to stick around, not how it was originally built.

Explore Liferay DXP's low-code capabilities if a governed application foundation sounds like the right fit for what comes next.

Frequently-Asked Questions About Vibe Coding Risks

Can an internal vibe-coded app still be high risk?

Yes. Being internal only limits who can reach the app, not what it can do once someone's using it. An internal tool that touches sensitive data or changes important records can carry as much risk as anything customer-facing, sometimes more, since internal tools often get less scrutiny.

Does a security review mean a vibe-coded app is ready for production?

Not on its own. Security is one part of the picture, regardless of which AI tools helped build the app. An app also needs to handle failures correctly, survive integration problems, be maintainable by someone other than its original builder, and have a real support plan in place after launch.

What if a vibe-coded app already has users?

Run the same checks on that vibe-coded app, just with more urgency. Existing users don't make an app safer. They just mean the consequences of a gap are already playing out. Prioritize the checks tied to whatever data or business processes the app currently touches.

Does every vibe-coded prototype need to become a production app?

No. Plenty of prototypes built with AI coding assistants do their job by answering a question or proving out an idea, then get retired. The pressure to formalize something usually shows up only once people start depending on it, which is exactly the moment this kind of review matters most.