Part one was about reading the surface: the purple gradients and pep-talk buttons that mark an app as AI-built, and the too-smooth, hollow writing that gives away AI text. That’s the easy half. All of it is cosmetic, quick to spot and quick to fix, and none of it can actually hurt you.
This is the other half. The signs that matter are the ones you can’t see from the outside, and they’re the reason “built with AI” is worth a closer look before you trust it with anything real.
What the Surface Doesn’t Show You
A purple gradient is harmless. A database anyone can open is not. The risk that actually matters sits underneath, in the parts of an app you never see: how it stores your data, who is allowed to reach it, and whether a stranger can walk in through a door nobody remembered to lock.
AI writes code that runs, not code that’s safe. It will happily build you a working login and a working database, and both will pass a quick demo. What it tends to skip is the quiet work underneath: limiting who can read what, keeping passwords and keys out of the public code, and checking the ways things can go wrong before real customers arrive. The app works, so it looks done, and the hole sits there until someone finds it.
This is not a rare mishap. It is the common case.
In early 2026, one security scan looked at roughly 380,000 apps built on popular vibe-coding platforms and found about 5,000 of them leaking real data: medical records, financial details, customer service chat logs. The most common cause wasn’t a clever attack. It was that these tools default a new project to publicly visible, and the person building it never knew there was a setting to change.
The Risks Worth Knowing by Name
These failures aren’t exotic. They fall into a handful of buckets, and once you can name them, you can ask about them.
- Data left out in the open. The database is set so that anyone who knows where to look can read it, usually because the tool made the project public by default and no one changed the setting. That means customer names, emails, orders, sometimes far more, sitting there for the taking. One founder built an entire social app this way without writing a line of code himself, and within days of launch it had exposed more than a million access keys and tens of thousands of email addresses, all from a single setting left in its default state.
- Keys and passwords sitting in the code. An app connects to outside services like payment, email, storage, and AI using secret keys, and these tools have a habit of leaving those keys somewhere a visitor can find them. Someone who does can run up your cloud or AI bill overnight, send email in your name, or gain access to the accounts those keys unlock.
- Security that stops at the browser. A web app really has two halves: the part that runs in the visitor’s browser, on their own phone or laptop (often called the frontend), and the part that runs on the server, the computer you control (the backend). A visitor can open up and change anything in the half running on their own device, so when the “are you allowed in here?” check lives only in the browser, they can switch it off and reach whatever it was meant to guard. A real lock lives on the server, where the visitor can’t touch it.
- No limit on how often something can be used. Forms, signups, and especially AI features cost you something every time they run, and AI-built apps often ship with no cap on how fast or how often anyone can hit them. Left open, a bot can flood your inbox with junk, fill your database with garbage, or, when a feature is billed per use, turn your monthly bill into a number you never agreed to.
Notice what these have in common. Not one of them shows up in a demo. The app looks and works exactly the same whether these doors are locked or standing open, which is precisely why the person who prompted it into existence never sees them, and why they sit unnoticed until someone else finds them.
How to Check Before You Trust It
You don’t need to read the code to find out whether these doors are locked. You need to ask the right questions, and know what a real answer sounds like. Each risk above has a question that flushes it out, plus one that covers all of them. A good developer will welcome them and answer plainly. Vagueness, or a quick “don’t worry about that,” is itself an answer.
- “Can any of my data be reached without logging in?” You’re listening for a clear no, backed by how it’s enforced, not “no one would think to look.” Hidden isn’t the same as protected.
- “Where are the keys and passwords stored, and could a visitor find them?” The right answer keeps them on the server, never shipped out to the browser. If the person isn’t sure where they are, that’s worth pausing on.
- “When someone logs in, is that checked on the server or only in their browser?” On the server is the answer you want. If it’s only in the browser, the lock is decorative.
- “What stops someone from hitting my forms or paid features thousands of times?” You’re looking for some kind of limit in place. “Nothing yet” means anyone who feels like it can run your bill up for you.
- “Has a person actually reviewed this, or did it just pass a demo?” This is the one that matters most. Working in a demo and being safe for real customers are two different things, and only a person makes the second one true.
None of this requires you to become technical. It just requires you to ask, and to notice whether the answers are specific or hand-wavy. The difference between the two usually tells you everything you needed to know.
It Can Be Fixed
If you ran those questions and the answers came back shaky, take a breath. A leaky AI-built app is a fixable problem, not a teardown. In most cases the idea is sound and the app mostly works, and what’s missing is the safety work that never got done. You rarely have to start over. You have to go back and finish.
Here’s what finishing actually looks like. A developer reads through what the tool generated to see what’s really there, then closes the gaps one by one: locking the data down so only the right people reach it, moving the keys and passwords onto the server and out of anything public, putting real limits on the features that cost you money, and testing the ways it can break before your customers find them for you. None of it is exotic. It’s ordinary, known work, the exact work the tool skipped because none of it shows up in a demo.
The sooner it’s done, the smaller the job. Fixing this before your app has real customers is routine. Fixing it after their data is already flowing through those open doors is still doable, but now you’re cleaning up as well as repairing, so it costs more and the whole thing is tenser. The best time is before launch. The second best is now.
And now you know enough to tell whether it was done. That’s the real payoff of understanding any of this. You can look at your own app, or at one a vendor hands you, and know the difference between “it works” and “it’s finished,” which is the difference this whole series has been about.
Use the Tools, Finish the Job
None of this makes AI the villain. The tool did what it was asked and produced something that works. What it can’t do is care whether your customers’ data is safe, and that has always been a human job.
What these tools are genuinely good at is starting things. They turn a rough idea into something real enough to look at, in minutes instead of days, and for someone with an idea and no way to build it, that clears the thing that stops most people: the blank page. It’s scaffolding, fast to put up and never meant to be the finished building.
Across both parts of this series, every giveaway has really been the same giveaway. The default gradient, the pep-talk buttons, the hollow paragraph, the unlocked database, each one marks a spot where the tool did its part and no person came back to do theirs. Whether you’re spotting AI on the surface or checking whether it’s safe underneath, you’re doing the same thing: noticing where something was started and then left.
The machine can start almost anything now. It still can’t finish it for you.