From AI-generated code to production software / Understanding the risk
The real risks of taking vibe-coded software to production
Vibe-coded software that never gets a real review tends to fail in a specific, predictable way: it works in normal use and breaks in every other case, including the places an attacker would look first. Here is what that risk actually looks like and why it is not theoretical.
Published July 28, 2026. Editorial.
Key takeaways
- AI-generated code tends to reproduce the same flaws found across the code it was trained on, security issues included.
- The risk is not the AI. It is code that skips the review step a human engineer's code would normally get.
- Common failure points are input validation, exposed secrets, and logic that only handles the case that was tested.
- Speed and review are not opposites. The fastest safe method is AI for the draft, a person for the check.
Every engineering team has released an imperfect feature. That is normal, and a team can recover from it. What is different about the current increase in AI-built software is scale: a single person can now generate a working application in a weekend, and a meaningful share of that code never gets the kind of review a team would normally require before it touches real users or real data.
Why the risk is structural, not incidental
AI models learn from a huge body of existing code, and that code contains the same mix of good and bad patterns every codebase has. The model does not know which patterns are safe for your situation. It reproduces what is statistically common, and common code includes real security flaws, because plenty of the code humans have written and published over the years has them too.
That alone would be manageable if the output got the same scrutiny a human's code gets before merging. The structural problem is that it often does not. The tools that make AI-generated code trivial to produce also make it trivial to accept without reading closely, and the volume of code being produced this way has grown faster than most teams' review habits have adapted to match.
Where the failures actually show up
A few patterns repeat often enough to be worth naming directly.
Input that is trusted instead of checked. AI-generated code tends to assume inputs will look like the examples it was shown, rather than defending against the input an actual attacker or a confused user will eventually send. This is the root cause behind a large share of security issues in any codebase, AI-written or not, and it is easy to miss in a quick read because the code works fine on normal input.
Secrets left where they should not be. It is common for AI-generated code, especially when copied quickly from a chat interface into a project, to include example credentials, API keys, or configuration that was never meant to reach a real environment. Left unnoticed, that becomes a live exposure the moment the code is released.
Logic that only handles the tested path. A demo needs to work once, for one input, in front of one audience. Production needs to work every time, for every input, including the ones nobody thought to test. AI-generated code, like a rushed first draft from any engineer, tends to be strong on the case it was asked about and weak on everything adjacent to it.
No tests to catch a regression. When the code was produced quickly through a prompt, tests are often an afterthought or missing entirely. Without them, a change made six weeks later can silently break something that used to work, and nobody finds out until a user does.
This is not an argument against AI-generated code
None of this means AI-generated code is unsafe by nature. It means unreviewed code is unsafe, at any speed of production, and AI has made it possible to produce far more of it far faster than most review processes were built to handle. The fix is not to slow down the writing. It is to make sure the review step, which used to happen almost by default because writing code took long enough to create natural pauses for checking, now happens deliberately.
The concrete version of that review is covered in how to review AI-generated code before release. If you are looking at software that was already released without that review, what it takes to fix a vibe-coded app is the more useful next page. And if this risk is showing up across a team rather than one project, AI coding governance for enterprise teams covers the controls that still work as the team grows.
Where this fits in a real build
We do not treat this risk as a reason to avoid AI tools. We treat it as the reason a senior engineer still has to be involved in anything that reaches real users. That is how our AI development engagements work: AI accelerates the draft, a senior team owns the review and the parts that decide whether it keeps working. If you want an independent opinion on whether something you already built is safe to keep adding to, talk to us.
Common questions
Is AI-generated code inherently less secure?
Not inherently. AI models reproduce the mix of patterns found in the code they were trained on, which includes real security flaws, the same way a rushed human engineer's code would. The risk is not the AI, it is code that skips the review a human engineer's code would normally get before release.
What are the most common production risks in vibe-coded apps?
Input that is trusted instead of validated, secrets or example credentials left in the code, logic that only handles the tested normal case, and missing tests that would catch a later regression. These are the same failure modes any rushed codebase has, at a larger scale.
Does using AI to write code mean I have to move slower to be safe?
No. The fastest safe method is AI for the first draft and a person for the review, not slowing down the writing itself. The mistake is treating AI-generated code as finished rather than as a draft that still needs the same scrutiny any new engineer's code would get.
What is the difference between vibe coding and AI-native development?
Vibe coding, as this guide uses the term, means accepting AI-generated code and releasing it without a close review. AI-native development uses the same AI tools but keeps a person responsible for reading the output, checking its assumptions, and deciding whether it is correct before it reaches real users.
How do I know if my vibe-coded app is actually at risk?
Check whether the code touching authentication, payments, or user data has ever been reviewed the way a new hire's code would be. If it has only ever been tested on normal use in a demo, treat it as unverified. The risk is concentrated in exactly the areas that a quick demo never tests.
Can automated tools catch the risks in vibe-coded software?
Static analysis and dependency scanning catch a meaningful share of the problem for little effort and should run before anyone reads a line by hand. They do not replace a person reading the logic for what it assumes about input, callers, and failure paths, which is where the harder issues are usually found.
Is it worth fixing a vibe-coded app instead of rewriting it?
In almost every case, yes. Fixing means sorting by risk: find what is actually broken, secure the parts that touch money and data first, and add the missing tests. A rewrite throws away the working parts along with the broken ones and usually costs more time than the original build took to produce.
How much AI-generated code actually reaches production without review?
There is no reliable industry figure for this, but the pattern is consistent across teams that build fast with AI tools: code that passes a demo is often treated as finished, and the review step that would normally happen before merging gets skipped or shortened under time pressure.
Related reading
Can you trust an AI agent with real work yet?
An agent that answers a question and an agent that takes an action are not the same risk. Here is how we decide where an agent is ready to act, and where it is not.
An AI demo is not a product
A convincing AI demo takes an afternoon. Turning it into something people trust in production takes most of the work, and most failures happen at that stage.
More in Understanding the risk
What is AI-native software development?
AI-native software development means AI is part of how a team builds from the start, writing a large share of the code, while a person still owns the architecture, the intent, and the decision about whether the output is correct. It is not the same as AI building without anyone checking.
Is AI-generated code secure? What the testing shows
Independent testing of more than 150 language models found that only 55 percent of their code generations were secure when no security guidance was given. That number has barely changed since 2023, while the models' ability to produce code that simply runs has risen to around 95 percent. The gap between code that works and code that is safe is getting wider, and that is the single most important fact to keep in mind when you decide how AI-written code reaches your customers.