Is your AI-generated code safe? You can't tell from the outside, but you can find out

Start with the reassuring part: these tools rarely produce broken code. Ask ChatGPT, Cursor, or Bolt for a login form, a checkout page, or a file upload, and you'll get something that runs, looks right, and does what you asked in the demo. The problem isn't that AI writes broken code. It's that 'runs correctly' and 'safe to expose to the internet' are two different things, and nothing in the tool tells you which one you got.

The reason comes down to how these tools learned to write code in the first place. They were trained on an enormous number of tutorials and Stack Overflow answers, and almost all of that material optimizes for teaching a concept clearly, not for protecting real users. A tutorial on file uploads skips the part where it checks who's allowed to upload. A tutorial on a search box skips the part where it sanitizes what you typed before using it. Each shortcut makes sense in a 40-line teaching example. In a live app handling real people's data, the same shortcut is a hole. The AI can't tell teaching code from production code, so it ships the tutorial version, gaps and all, whether you built it by hand, prompted it, or vibe-coded the whole thing in an afternoon.

The first gap, and the easiest to explain, is secrets sitting where they shouldn't. AI-generated apps regularly ship with API keys and database credentials typed directly into files the browser can read, or committed into the project's history where anyone with access to the repository can find them. This happens because it's the fastest way to get something working, and the AI has no concept of 'this key should never leave the server.' It just makes the demo run.

The second, and worth understanding in some detail, is missing server-side checks. A typical AI-built app asks 'who are you?' when you load a page, but never asks again when you actually request data. So the page might correctly hide another customer's invoice from the menu, but if you know, or guess, the web address that loads invoice number 124, and you change it to 125, the server hands it over without checking whether it's yours. Nothing about this shows up while you're using the app normally. It only shows up if someone goes looking. This single pattern, checks that exist on the screen but not on the server, is behind a large share of what a review turns up.

The third gap is trusting whatever a person types. Search boxes, comment fields, contact forms: AI-generated code often takes that input and uses it directly, assuming everyone will type something reasonable. Someone who types something deliberately unreasonable can sometimes get the app to run a database command it shouldn't, or display content that wasn't meant to be shown. Fixing this is usually a matter of adding validation that should have been there from the start, not a rebuild.

The fourth: your app isn't built from scratch, it's built from hundreds of borrowed packages, and some of those have known holes that get published and patched on an ongoing basis. AI tools tend to reach for whatever version is common in their training data, often not the current, patched one. Less dramatic than the others, but the one that keeps mattering after launch, not just on day one.

The fifth costs money rather than data: an endpoint with no rate limit that happens to call a paid API, sending emails, texts, or AI requests, can be hit repeatedly and run up a bill you didn't expect. This is a real and common gap in vibe-coded apps that lean on third-party services, and it's easy to miss because it looks fine in a demo with one user.

Not everything a review finds is a five-alarm fire. Some findings are launch-blockers you'd want fixed before a stranger touches the app. Others are worth knowing but fine to leave for a few weeks. And some of what looks like a security problem is really just fragile code — no handling for a failed payment or a timed-out network request. It works fine until the first time reality doesn't match the demo. Treating all of these the same would be dishonest; a review's job is to tell you which is which.

The reassuring conclusion is that none of this is a mystery. These are well-known, well-understood patterns with known fixes, not open-ended unknowns. Having someone look before you launch, someone who knows exactly what to check, turns a vague worry into a short, plain-language list: what's actually wrong, how serious each item is, and what it would take to fix. That's the entire point: not to make you afraid of what you built, but to make it knowable, so you can ship it with confidence instead of a guess.