If an AI tool built your app and it works, you have proved one thing only: that it works when someone uses it properly. You have not proved it is safe when someone uses it badly on purpose.
That gap is where the trouble sits. A business owner sees a working booking system, a customer portal or an internal dashboard, and reasonably assumes the hard part is done. The features run. Customers can log in. Nothing is on fire.
Meanwhile the parts that keep other people out of your customers' data were never really built, because nobody asked for them and the app runs perfectly well without them.
What vibe coding actually means
Vibe coding is building software by describing what you want to an AI tool and letting it write the code. You ask for a booking form, you get a booking form. You ask it to add payments, it adds payments.
It is genuinely useful. Things that used to take weeks now take an afternoon, and businesses that could never justify custom software suddenly can. We use AI tools ourselves, every day.
The catch is what the tool is optimising for. It is trying to make your request work. It is not trying to imagine the person who wants to read your customer list, and it will not tell you it skipped that part, because from its point of view nothing is missing.
What the research actually found
Researchers at Carnegie Mellon tested AI coding agents on 200 real software tasks and found the best performing setup produced working code 61% of the time, but secure code only 10.5% of the time. More than four out of five solutions that passed the functional tests still carried a vulnerability.
That is the whole problem in one statistic. Working and safe are not the same measurement, and only one of them is obvious from looking at the screen.
A second study is worth knowing about because it changes what you should worry about. Security researchers at Invicti generated and analysed more than 20,000 AI built web applications. Their finding was more nuanced than the headlines suggest: modern AI tools have actually got noticeably better at avoiding the classic textbook flaws.
What they had not fixed was the quieter category. Credentials left sitting in the code. Permissions that trust the browser to police itself. The things that look completely normal in a file and fail the moment somebody tests them properly.
Why "we ran a security scan" is not an answer
Automated scanners are far less useful on AI written code than most people assume. In the Invicti research, the scanning tools produced long lists of problems, and when a human checked the most serious ones by hand, only a handful were real.
So a clean scan is not reassurance, and an alarming scan is not necessarily a crisis. Both outcomes need somebody who can tell the difference.
There is a second trap here. If the same AI that wrote your app is the one reviewing it, you are asking it to notice the thing it did not think of the first time. It usually does not. And because these tools work fast, one blind spot tends to get copied into every similar part of the application.
The four things that usually go wrong
In plain terms, almost every problem we see in AI built applications falls into one of four buckets.
- Keys left in the open. Passwords and access codes for your database or payment provider written directly into the app, where anyone curious can find them. This is now the single most common issue.
- Doors with no lock behind reception. The app checks that you are logged in, then never checks whether this particular customer is allowed to see this particular record. Change one number in the web address and you are looking at someone else's order.
- Logging out that does not log you out. Sessions that stay valid after someone signs out, passwords stored badly, access that lasts weeks when it should last minutes.
- Ingredients nobody checked. AI tools sometimes reference software components that do not exist, and people with bad intentions have started registering those exact names and filling them with malicious code.
Notice what these have in common. None of them stop the app working. A customer could use your system happily for a year without ever bumping into one.
What this actually costs a UK business
If customer data leaks from your app, it is your business that answers for it, not the tool that wrote the code and not the freelancer who ran the prompts.
Under UK GDPR you are the one holding the data, which means you are the one with the obligation to protect it and to report a personal data breach to the Information Commissioner's Office when one happens. There is a reporting window measured in hours, not weeks.
For most small and medium businesses, though, the fine is not the real damage. The real damage is telling your customers it happened. That conversation costs more than any security review, and it is the part people never budget for.
Seven questions to ask whoever built your app
You do not need to understand the code to find out whether anyone thought about this. Ask these, and pay attention to whether the answers are specific or vague.
- Where are our passwords and access keys stored, and is any of that visible in the app itself?
- If a logged in customer changes a number in the web address, can they see another customer's information? Ask whether this was tested with two real accounts, not whether it should work.
- What happens when someone logs out? Specifically, can their old session still be used.
- Who checked this besides the AI that wrote it?
- Was the running app tested, or just the code read? These are different activities and only one finds permission problems.
- What personal data do we hold, where does it live, and who can reach it?
- If something went wrong tonight, how would we find out?
If the answers come back confident and detailed, that is a good sign. If they come back as "the AI handles that" or "it has not been an issue so far", you have your answer.
When vibe coding is completely fine
None of this means AI built software is a bad idea. It means the level of care should match what the app touches.
An internal tool that reformats a spreadsheet, a prototype you are showing to three colleagues, a calculator on a page with no login: build it however you like. The worst case is that it breaks and you fix it.
The calculation changes the moment the app holds customer names, takes payments, stores anything about someone's health or finances, or sits on the public internet with a login screen. At that point you are looking after other people's information, and somebody who understands the risks should look at it before your customers do.
How we can help
At Rinaztec we build custom software, AI automations and business systems for UK companies, and we review applications that were built elsewhere, including ones built with AI tools.
We start with what the system actually does for your business rather than with a list of technical findings. In practice that usually means going through the running application the way somebody with bad intentions would, telling you in plain English what we found and what it would mean for you, then fixing what needs fixing in priority order.
Sometimes the honest answer is that your app is fine for what it does. We would rather tell you that than sell you work you do not need.
If you have an application you are not sure about, or you are about to put one in front of customers, we are happy to take a look and tell you where you stand.
- Email: riaz@rinaztec.com
- Get in touch: rinaztec.com/contact
- What we do: rinaztec.com/services
Tell us what the app does and who uses it, and we will tell you honestly whether it needs a proper review or whether you can get on with running your business.