An AI-built app can look finished long before it's ready for production. We see this regularly in projects built with Cursor, Bolt, Claude and similar tools: users can log in, data moves where it should, and the interface behaves exactly as expected.
That's a real achievement. The development speed these tools make possible would have been difficult to imagine only a few years ago.
What the demo doesn't prove is whether sessions expire, requests are properly authorized, input is validated, secrets are protected, environments are separated, and failures can be investigated and recovered from. Those production controls deserve their own review.
What "works" actually means
When an AI coding tool builds your application, it optimizes for the thing you asked for: functionality. You said "build me a task management app with user authentication and a dashboard," and that's exactly what you got. The app loads, users can create accounts, tasks get saved, the dashboard renders.
What you didn't ask for, and what the AI didn't volunteer, is everything underneath. The parts that don't show up in a demo but determine whether the app survives contact with real users, real data, and real attackers.
The seven layers beneath "it works"
There's a consistent set of issues we find when we audit AI-built applications. Not occasionally, but in virtually every engagement. The tools are getting better, but the pattern holds.
Authentication that isn't real authentication. The app has a login page, but the auth logic is client-side, or session tokens don't expire, or there's no rate limiting on login attempts. It looks like security. It isn't.
No input validation. Whatever the user types goes straight to the database or the API. That's how SQL injection, XSS, and a dozen other well-understood attacks work. AI tools rarely generate input validation unless you explicitly ask for it.
Hardcoded secrets. API keys, database passwords, and service credentials sitting in the source code. If the repo is public, or if an attacker gets access to the codebase, every connected service is compromised.
No environment separation. Development and production share the same database, the same API keys, the same everything. A mistake in development corrupts production data. There's no staging environment to test changes safely.
Missing error handling. When something goes wrong (and it will), the app either crashes entirely or exposes internal details (stack traces, database schemas, file paths) to the user. Both outcomes are bad.
No audit trail. There's no logging of who did what and when. If data changes unexpectedly, there's no way to trace it. If a regulator asks for access records, you have nothing to show.
No backup or recovery plan. The database exists in one place. If the server fails, the data is gone. If someone accidentally drops a table, there's no point-in-time recovery.
Why the AI doesn't fix this on its own
AI coding tools are trained on patterns. They generate code that follows the patterns they've seen, and most of the training data consists of tutorials, examples, and prototypes that prioritize clarity and functionality over production hardening. The AI builds what tutorials build: the working demo.
It's not that these tools can't generate secure, production-ready code. They can, if you ask with enough specificity. But you'd need to know what to ask for, which means you'd need to already understand the full landscape of production concerns. And if you already understood that landscape, you probably wouldn't need the AI to build the app for you.
That behavior follows directly from how the tools are used: the prompt defines the visible functionality, while production controls may never enter the specification.
Why a working demo can still be risky
The real danger isn't that AI-built apps are broken. They're not. The core logic is usually sound. The danger is that they look and feel complete. They pass the demo test. They pass the "show my co-founder" test. They even pass the "put it in front of users" test, at least initially.
The problems surface later. When someone discovers they can access other users' data by changing a URL parameter. When the database fills up because there's no pagination or cleanup. When a credential leak exposes every user's information. When a client in a regulated industry asks for an audit report and you have nothing to show.
By then, fixing the issues is more expensive than it would have been to address them up front, and the damage (to data, to users, to reputation) may already be done.
What production-ready actually looks like
Most AI-built applications don't need to be rewritten before they can be used in production. They need a deliberate pass over the controls that sit around the working feature set.
In practice, that means implementing proper session management, validating input on every user-facing endpoint, moving secrets to environment variables or a vault, separating development from production, handling errors safely, keeping useful audit logs, and establishing a backup and recovery process.
This is ordinary production engineering. It gets missed in AI-assisted projects because the initial build is usually driven by visible feature requirements, while these controls sit outside the feature list.
Before you call it production-ready
If people are already using an AI-built application, functional testing isn't enough. A production-readiness review should happen before an attacker, a client security review, or an operational failure discovers the missing controls for you.