Shimira IT
AI builders — Lovable, Bolt, Replit, v0, Cursor — now get a working app in front of users in an afternoon. That is genuinely new, and genuinely good. What hasn't changed is what "production" demands: that the app stays up, keeps data safe, and survives its hundredth user as well as its first.
This is a field report on the gap between those two moments. It's drawn from the AI-generated codebases we're brought in to rescue — the recurring failures, ordered by how often we actually encounter them, not by how dramatic they sound. We've deliberately avoided inventing a precise percentage for each; sample-of-convenience numbers dressed up as statistics are their own kind of dishonesty. What we can tell you is the order, because it's remarkably consistent.
First, the pattern that makes all of this worse
Before the ranking, the one thing that ties every item below together: an AI-built app fails in production in almost exactly the reverse order of how visible each problem is while you're building. The things that make the app feel finished — it looks polished, it logs you in, it saves your data, the demo is flawless — are surface features the builder is very good at. The things that make an app survive — enforced permissions, validated input, data integrity, tests, monitoring — are invisible in a demo, so the builder never generates them and you never notice they're missing.
That's why the failures are predictable. They're not random bugs. They're the same structural gaps, in the same places, every time, because every AI builder is optimizing for the same thing: the moment the thing works on screen. Keep that in mind as you read the ranking — each item is really the same root cause wearing a different hat.
The ranking, most common first
1. No real authorization layer
The single most frequent serious issue. The app has login — authentication — but the rows a logged-in user can read and write are not actually scoped to them. The AI generated a working auth screen and the client-side code looks locked down, but the API or database queries don't enforce ownership. Any user can often read any other user's data by changing an ID in a request.
This is the one that turns into a headline. It's near-universal in AI-built apps because the builder optimizes for the demo — a logged-in user seeing their dashboard — and the demo never tests what a different user can reach. The fix is rarely dramatic: it's enforcing ownership checks at the data layer, where they belong, instead of trusting the frontend to hide what a user shouldn't see.
2. Secrets and keys exposed client-side
API keys, database credentials, and third-party tokens embedded in frontend code or shipped in the client bundle. The app works perfectly, because the keys are right there — which is exactly the problem. Anyone can open dev tools and take them. We cover the specifics of one high-profile case in Lovable's April 2026 security incident. Worse, by the time you find an exposed key it may already have been scraped — so remediation isn't just moving the key server-side, it's rotating every credential that was ever in the bundle.
3. No input validation or rate limiting
Forms accept anything. Endpoints have no rate limits. The app assumes every request is a well-behaved user clicking buttons as designed — not a script, a bot, or someone pasting a megabyte of text into a field. In production this surfaces as spam, injected data, runaway costs (especially when an AI/LLM call sits behind an unthrottled endpoint — one abusive user can run up a real bill overnight), and crashes.
4. Database with no integrity rules
Data saves, so it looks done. But there are no foreign-key constraints, no uniqueness rules, no transactions around multi-step writes. The data model drifts into an inconsistent state the first time two things happen at once, and nobody notices until the numbers stop adding up weeks later — by which point the bad data is tangled through everything. This is one of the most expensive to fix late, because you're not just adding the missing rules — you're cleaning up all the inconsistent data that accumulated while they were absent.
5. Everything passes because nothing is tested
No automated tests, so "it works" means "it worked when the builder last clicked through it." Every change risks silently breaking something else, which is why AI-built apps often get more fragile as they grow — each feature added by re-prompting can quietly undo the last. Teams feel this as a mysterious slowdown: every new feature takes longer and breaks two old ones, because nothing is catching the regressions.
6. No error handling or observability
When something fails in production, it fails silently or crashes the whole page, and there's no logging to tell you what happened. The team learns about outages from users, not monitoring, and then can't reproduce them. We go deep on this in the production checklists for Replit, Bolt, Lovable, and vibe-coded apps generally.
7. Scaling assumptions that were never true
The app loads the entire table to show ten rows. It has no pagination, no caching, no indexes. At demo scale — a handful of records — it's instant. At real scale it slows to a crawl, then times out. This one hides the longest because it only appears once there's enough data to expose it, which is often right when the app is starting to succeed — the worst possible moment to discover it.
Why the order is so predictable
Every item above shares one root cause: AI builders optimize for the working demo, and the demo is the exact scenario where none of these problems show up. A demo is one trusted user, with a few records, doing the happy path, watched by the person who built it. Production is many untrusted users, with lots of data, doing unexpected things, unwatched. The failures cluster precisely in the gap between those two worlds — which is why they recur in the same rough order across completely different apps and different AI tools.
None of this is an argument against AI builders. They're a legitimately powerful way to validate an idea and get to a prototype fast. It's an argument against shipping the prototype as-is — and against the specific trap of an app that feels finished because it demos flawlessly.
A quick self-check
You don't need an engineer to get a first read on your own app. Ask these, honestly:
- Can a second test user reach the first user's data if they go looking? (If you've never tried, assume yes.)
- Open your browser's dev tools on the running app — do you see any API keys or tokens in the network requests or source?
- What happens if you paste 10,000 characters into a text field and submit?
- Is there a single automated test that runs before a change ships?
- If the app broke right now for one user, how would you find out — and could you see what happened?
A "no" or "not sure" on any of these maps directly to one of the ranked items above. Three or more, and the app has a production gap, not a bug list.
What to actually do about it
If you've built something with an AI tool and it's getting real users, the honest path is a hardening pass, not a rewrite. In our experience most AI-built apps have a salvageable foundation; what they lack is the unglamorous production layer — authorization, secrets management, validation, integrity, tests, observability. We walk through the rebuild-vs-rescue decision in should you rewrite or rescue an existing codebase, and what that costs in how much does it cost to fix an AI-built app. If the team that built it has since moved on, what to do when your software developer disappears covers taking ownership of a codebase you didn't write.
The cheapest first step is a read-only audit: someone who didn't build it checks it against exactly the list above and tells you which items you have, before anyone touches the code. If you want that done, tell us what you built and where — you'll get an honest assessment, including "this is in better shape than you feared" when that's true.
A note on method: this report ranks failure modes by observed frequency across AI-generated codebases we've been engaged to review and harden. It is a practitioner's field account, not a controlled study, and the ordering reflects what we see rather than a measured population. We've kept it to the order we can stand behind rather than attaching invented precision.