The Risks of Building Software With AI (And How to Ship Anyway)
Your app works. Customers are using it. You could not sit down today and explain how the login actually works, and you are about to add three more features on top of it.
That gap is the risk. Not a bug you can find, but the growing distance between what your software does and what anyone can account for.
This is not an argument against building software with AI. The speed is real, the cost savings are real, and neither is going away. Most of the companies we work with build this way now, and the ones who do it well are not the ones who use the tools less.
What follows is what tends to break, how to tell which parts of your system are exposed, and the guardrails you can put up without hiring a security team.
If you have not tested what you already built, start with our vibe-coded app security checklist and come back. That one is the audit. This one is the practice.
What actually goes wrong with AI-built software?
AI-built software usually fails in one of four ways, and none of them look like a crash. The app keeps running while the problem sits underneath it.
| What happens | How you find out | What it costs you |
|---|---|---|
| One customer can see another's data | A customer emails you a screenshot | Breach notification, regulatory exposure, the trust you spent a year building |
| Your keys ship inside the app | A surprise invoice, or usage you did not create | Fraudulent charges, rotating every credential, possible account suspension |
| It works until it is busy | Your first real traffic spike | Downtime at the exact moment attention arrives |
| Nobody can safely change it | You try to add one feature and three break | Rebuilding what you already paid to build |
The last one is the quiet killer. The first three are incidents you can respond to, while the fourth just slowly raises the cost of every change until building on what you have stops making sense.
You will feel it before you can name it. A feature that should take a day takes a week, every fix creates a new problem somewhere else, and you start avoiding parts of your own product. That is not bad luck or a bad developer, but the bill arriving for code nobody ever understood.
The scale is documented. Security firm Escape scanned 5,600 live applications built with AI tools and found over 2,000 high-impact vulnerabilities, more than 400 exposed secrets, and 175 instances of exposed personal data, some of it medical records and bank account information.
These are not lab conditions. Those were real applications with real users at the time of the scan.
The trend is moving too. Georgia Tech's tracking of publicly recorded vulnerabilities attributed to AI-generated code counted 6 in January 2026 and 35 by March.
Two named cases make it concrete. A flaw in apps built on Lovable left database access controls inverted across 170 production applications, and in February 2026 the Moltbook platform exposed roughly 1.5 million user tokens through a missing database permission setting.
Neither was an exotic attack. In both cases a default was left as the tool generated it.
One number worth correcting, since it circulates widely: the claim that 91.5% of AI-built apps carry a critical flaw comes from Kingbird Solutions, a commercial audit firm reviewing 200-plus apps, and its sampling method was never published. It is frequently attributed to Escape, which did not produce it. The Escape figures above are the ones with a published methodology behind them.
The Ownership Test
The Ownership Test is four questions you apply to each significant part of your system. A component passes only if a named person can answer all four without opening the code.
| # | Question | It fails when |
|---|---|---|
| 1 | Who owns this? Can you name the person responsible for it? | The honest answer is "the AI built that part" |
| 2 | What does it do? Can they explain it in plain language? | They can only tell you what it is called |
| 3 | Why is it built this way? Can they explain the choice? | They did not know there was a choice |
| 4 | What breaks if it changes? Can they name what depends on it? | The only way to find out is to change it and see |
Run it on the parts that matter: login and accounts, payments, anywhere you store customer information, and anything that talks to an outside service.
Reading your results
| Verdict | What it means | What to do |
|---|---|---|
| Owned | All four answered | Nothing. Keep it that way as you add features. |
| Thinly owned | Questions 1 and 2 answered, 3 and 4 not | Document the decisions now, while you can still reconstruct them |
| Unowned | Question 1 fails | Stop adding features here until someone can answer it |
What this looks like in practice
Say you run a small booking platform you built with AI over a few months. Run the test on three parts of it.
You can explain it, you chose the time-slot logic yourself after the first version double-booked people, and you know the reminder emails depend on it. That passes on all four questions, so you own it.
You know it charges the card and it has never failed, but you could not say what happens if the charge succeeds and your app crashes before recording it. That is thinly owned, and the question you cannot answer is exactly the one that produces angry customers and manual refunds.
It was built in the first week, it worked, and you have not touched it since. You cannot say whether one customer's session could reach another's data, because nobody ever asked, which means nobody owns it.
Now look at the order. Your calendar is the part you understand best because it broke once and you had to learn it. Your login is the weakest because it never broke.
Most people expect their weakest area to be something technical. It is usually payments or account permissions, because those got built early, worked immediately, and never got revisited.
Unowned code is not a code quality problem. It is a business continuity problem, because you cannot fix, explain, or defend something nobody understands, and those three things are exactly what you need on the day something goes wrong.
What better prompting cannot fix
There is a real ceiling on what instructions can do, and knowing where it sits saves you from solving the wrong problem.
Start with the security evidence. Veracode tested more than 100 AI models across 80 coding tasks in four languages, and in roughly 45% of cases where the model could choose a secure or insecure way to build something, it chose the insecure one.
The important part is the trend. That rate has stayed flat since 2023, while the models' ability to produce code that simply runs correctly climbed past 95%.
Models got dramatically better at writing code that works. They did not get better at writing code that is safe.
Then there is the research on why. When one researcher examined AI coding failures that came within a few tests of succeeding, he asked what instruction would have been needed to push them over the line.
The answer was none of them. The failures were an optimization with a subtle correctness bug, a security check built to react instead of prevent, and a rule the system knew but connected incorrectly.
Those are judgment calls, not missing facts. No instruction file could have supplied them, because the gap was not information.
This is also visible in how developers experience the tools. In Stack Overflow's 2025 survey of more than 49,000 developers, the single most common frustration was AI output that is almost right but not quite, cited by 66%.
Almost right is the hardest kind of wrong to catch. It passes a glance, it passes a demo, and it fails on the day that matters.
None of this means you should build less software with AI. It means the review step is not optional, and it cannot be performed by the same tool that wrote the code. Somewhere in your process a person has to be accountable for the parts that carry real consequences.
Not sure which parts of your system are unowned?
We read AI-built codebases for a living and tell you plainly what is safe, what is fragile, and what needs rebuilding before you scale it.
Book a 30-Minute Call →Five guardrails that do not need a security specialist
You can close most of the gap without hiring anyone. These five are ordered by how much they protect you for the effort involved.
- Make the AI explain before you accept. Before approving a change, ask it what it changed, why, and what else touches that code. If the explanation is vague, the change is not ready. This costs you thirty seconds and catches the "almost right" category better than reading the code would.
- Get your keys out of the app. Passwords and API keys belong in environment variables, never inside the code the browser downloads. Ask your AI tool to search the project for hardcoded credentials and show you every result, then move them and generate new ones, because anything that shipped publicly should be treated as already exposed.
- Test every screen as a second person. Create two accounts, log in as the first, then try to reach the first account's data while logged in as the second. Change the numbers in the address bar and see what loads. This one exercise finds the most common serious flaw in AI-built applications, which is software that checks who you are but never checks what you are allowed to see. Do it for every screen that shows customer information, not just the obvious ones.
- Turn on dependency scanning. Your code sits on top of other people's code, and some of it has known holes. GitHub does this free with a settings toggle, and it will tell you what needs updating without you needing to understand any of it.
- Keep a list of what you do not understand. Every time you accept something you could not explain, write it down. That list is your risk register, and it maps directly onto the Ownership Test above.
Guardrail five is the one people skip and the one that compounds. A written list of unknowns is something you can hand to someone, price out, and work through, while unwritten unknowns just accumulate until they surface on their own schedule.
For the structural questions underneath all of this, our guide to the four gates every AI-built app has to clear covers what has to hold before you scale.
When to bring in help
Not every AI-built app needs professional review. Some genuinely do, and the triggers are specific rather than about how much code exists.
Bring someone in when any of these are true:
- You take payments or store card details
- You hold personal data covered by regulation, including health, financial, or children's information
- You have paying customers who would be materially harmed by an outage or a leak
- Your Ownership Test came back mostly unowned
- You are about to raise money or sell, and someone will look at what you built
That last one surprises people. Technical due diligence during a raise or acquisition is often the moment these problems surface, at the worst possible time for your negotiating position.
If none of those apply, the five guardrails above are proportionate to your risk. Come back to this when one of them changes.
When you do bring someone in, ask them to start with the Ownership Test rather than a full audit. It is faster, it costs less, and it tells you where an audit would actually be worth paying for.
Frequently asked questions
It can be, with review. Testing across 100-plus models found AI picked the insecure option in about 45% of cases where a secure one existed, and that has not improved since 2023. The code is usually functional, but safe is a separate question that still needs a human answer.
It helps, but do not rely on it alone. Asking the AI to review its own work catches obvious problems like exposed keys, and it is worth doing. It misses the subtler category it created, because the same judgment that wrote the flaw is the judgment now reviewing it.
It depends almost entirely on how much is unowned. Fixing a specific flaw in code someone understands is usually hours. Reconstructing intent across a system nobody can explain runs far longer, which is why the Ownership Test is worth running before you ask anyone for a quote.
Fix first, in most cases. Working software with real users is valuable even when the code underneath is untidy. Rebuild when the Ownership Test comes back unowned across your core flows and every change breaks something else, since that is when repair costs more than replacement.
Working is not the same as maintainable. You need one when you handle money or regulated data, when you cannot change things without breaking them, or when an outage would genuinely hurt customers. Plenty of small applications never cross that line.
The short version
The risk of building software with AI is not bad code. It is unaccounted-for code, working today, that nobody can explain tomorrow.
The evidence is clear that this is common rather than unlucky. Thousands of live applications carry serious flaws, the rate at which models choose insecure approaches has not improved in three years, and the failures that matter most are judgment calls no instruction could have prevented.
So run the Ownership Test on your core flows. Put up the five guardrails. Write down what you do not understand and treat that list as real.
Build fast. Just know which parts you own.
Want to know what you actually shipped?
Hireplicity is a US-led engineering team based in Cebu that builds and secures software for growing companies. Book a 30-minute call and we will tell you plainly what is solid, what is fragile, and what needs work before you scale.
Book a 30-Minute Discovery Call →- Escape — The State of Security of Vibe Coded Apps (2026) — https://escape.tech/state-of-security-of-vibe-coded-apps
- Veracode — GenAI Code Security Report (2026) — https://www.veracode.com/blog/spring-2026-genai-code-security/
- Georgia Tech — Vibe Security Radar, CVE attribution tracking (2026)
- Stack Overflow — 2025 Developer Survey, 49,000+ respondents — https://survey.stackoverflow.co/2025/ai
- Khatri, P. — Do Context Files Help Coding Agents? A Two-Agent Ablation Study on Real Repositories (arXiv:2607.27250, July 2026) — https://arxiv.org/abs/2607.27250
