Your AI built app works. That does not mean it is ready.

You have an app. You cannot tell whether it is safe.

Something you put together quickly with an AI coding tool now has real users, real logins and real customer data inside it. It works. It looks finished.

That is the awkward part, because working and being safe to run a business on are two different tests. The tools that got you this far only measure the first one.

This is not an argument against building with AI. It is an explanation of what those tools reliably get wrong, so you can check the handful of things that actually matter before someone else finds them for you.

The tools are excellent at correct and poor at safe

Veracode has been running the same experiment on code generating models for two years. It gives them 80 coding tasks across four languages, then checks whether the result is both functional and secure.

In its spring 2026 update , published in March, syntax correctness came out above 95 percent across more than 150 models. The security pass rate was 55 percent.

That gap is the whole story. Offered a secure way and an insecure way to do the same job, models pick the insecure one close to half the time, and the code still runs perfectly when they do.

Two years of model releases have barely moved that number. It is not a rough edge waiting to be smoothed out by the next release.

The failures cluster in predictable places

The average hides something more useful. Some categories are fine and some are close to hopeless.

Database queries came out well, with an 82 percent pass rate on SQL injection, and cryptography scored 86 percent. Those are the problems the industry has been shouting about for twenty years, so the training data is full of good examples to copy.

Cross site scripting passed 15 percent of the time. Log injection passed 13 percent. By language, Java scored worst at 29 percent and Python led at 62 percent.

So if your app takes text from one person and shows it to another, which covers comments, reviews, profiles, messages, booking notes and support tickets, you are sitting in the category that fails most often.

What this looks like in apps that are already live

Lab tests are one thing. In December 2025 the security firm Escape scanned 5,600 publicly deployed apps built with AI tools and found more than 2,000 high impact vulnerabilities , along with roughly 400 exposed secrets including live API keys and credentials.

About one in three of those apps shipped with a serious flaw reachable from the open internet.

Exposed secrets deserve a moment. A key sitting in the code your visitors' browsers download is not a theoretical risk. It is a working password published on the internet, usually attached to a service that bills you by usage.

Five things worth checking this week

None of these require you to write code. They require someone to actually look.

• Who can read your database. Open your app, then open the network tab in your browser's developer tools and watch what comes back. If a response contains other people's records, the rules are not being enforced on the server, they are being enforced by the screen not showing them.
• What is in the bundle. Search your published front end files for the words key, secret and token. Anything you find is public, no matter what the original file was called or whether it sat in an environment file on your machine.
• What happens after sign in. Log in as one user, copy the link to a private page, then open it in a separate browser signed in as someone else. If it loads, your app is checking who people are and not what they are allowed to see.
• Uploads. If people can upload files, confirm there is a size limit and a type limit, and that the storage bucket is not publicly listable.
• Backups. Confirm one exists and that you have restored from it at least once. A backup nobody has ever restored is a belief rather than a backup.

Four of those five failures share a cause. The app was built screen first, so the rules about who sees what ended up living in the screens instead of in the data.

Patch or rebuild

Most owners assume the answer is rebuild. Most of the time it is not.

If the structure is sound and the problems sit in a few known places, this is a fixing job measured in days. Missing permission rules, secrets in the wrong place and unvalidated input are all repairable without disturbing the parts your users already like.

Rebuilding earns its cost when the data model itself is wrong. If the app cannot answer who owns this record without guessing, patching does not help, because every new feature inherits the same confusion and the same bug arrives again wearing a different hat.

The signal to watch is repetition. One surprise is a mistake. Three surprises in the same corner of the app means the corner is the problem.

Nobody hands you a warning first

The reason this matters more than it used to is that the consequences are no longer only technical. If customer data leaks, you have a reporting obligation and a conversation with people who trusted you, and neither is improved by explaining that a model wrote it.

There is also a quieter cost. Software that nobody understands gets slower to change, because every edit carries the risk of breaking something invisible. That shows up as a build that felt free in month one and feels stuck by month six.

Knowing which of those two situations you are in is worth more than any single fix.

The honest version of the advice

AI coding tools made it possible to test an idea in a week for the price of a weekend. That is genuinely good, and plenty of businesses should start exactly that way rather than paying anyone to build a guess.

What has not changed is that serving real customers means holding their data, and holding data means somebody has to have looked at how it is protected. The tools do not do that part and do not claim to.

If you have something live and you are not sure how you would score on the five checks above, that uncertainty is the thing to resolve. It is usually one conversation and a look at the code, not a project.

We build web apps, mobile apps and internal tools, and we are just as happy to tell you the boring answer when the boring answer is that yours is fine. Book a free 15 minute consultation or email info@kerenlabs.com .