Where I start
The demo path is the one part I trust least.
When an app is generated by an AI assistant, the parts that look finished are usually the parts the model had the most examples of: the UI, the obvious CRUD screens, the login form. What the demo does not show you is everything that only matters when someone is hostile, careless, or simply at scale. That gap is the whole job. I review in roughly this order, hardest-hitting first.
1
Trust boundaries: is the server actually in charge?
The single most common serious finding in AI-built apps is authorization that lives in the UI but not on the server. The admin button is hidden for normal users — but the endpoint behind it does not re-check who is calling it. Anyone who opens the network tab can hit it directly.
So I trace a few sensitive actions end to end: who can call this, what stops them, and is that check enforced on the backend rather than assumed by the frontend. Hidden is not the same as protected. If a permission only exists in client-side code, it does not exist.
2
Validation and data: what happens on the unhappy path?
Generated code tends to validate the inputs it expects and ignore the ones it does not. I push on the writes that matter — the ones that move money, change ownership, or can't be undone — and ask what happens with empty values, the wrong type, a negative number, a duplicate submit, or two requests racing each other.
I also look at the schema underneath: missing constraints, no uniqueness where the business clearly assumes it, migrations that exist in the code but were never run cleanly. These are quiet bugs. They don't crash the demo; they corrupt data weeks after launch, when it's expensive to untangle.
3
Secrets and exposure: what's reachable that shouldn't be?
I check where API keys and credentials live, whether any of them have been shipped to the browser bundle, and what a logged-out or unrelated user can read if they just ask the API politely. AI tools are happy to wire a third-party key straight into client code because it makes the example work. That same key is then public.
This is also where dependency risk shows up: known-vulnerable packages, abandoned libraries, or a lockfile that doesn't match what's deployed.
4
Operations: can you tell when it breaks, and recover?
Most AI-built apps have no answer to a simple question: when something goes wrong in production at 2am, how do you find out? I look for error tracking, structured logs, a sane deploy and rollback story, and environment configuration that isn't one fragile machine someone set up by hand.
This rarely blocks a launch on its own, but it decides whether your first real outage is a ten-minute fix or a lost weekend.
5
Generated-code sprawl: what will slow every future change?
Finally, maintainability. AI tools duplicate logic freely — the same business rule reimplemented in three screens, slightly differently each time. It runs fine today. It becomes the reason a one-line change takes a day six months from now, and the reason a fix in one place silently leaves the other two broken.
I flag the duplicated rules and tangled boundaries that are worth consolidating before the codebase grows around them — not to make it pretty, but to keep it cheap to change.
Why this order
Risk first, polish never.
The point of the order is triage. Security and data issues can hurt real users and are hard to walk back, so they come first. Operations decides how bad your worst day is. Maintainability is real but rarely a launch blocker. A good review doesn't hand you a hundred notes — it hands you a short list in the order a sensible person would actually fix them, with the launch blockers marked clearly.
That's exactly what a vibeCleaners review delivers: the same checks above, written up as risk-ranked findings with evidence and a fix order. If you've built something with Cursor, Lovable, Bolt, Replit, or a chat assistant and you're not sure it's ready, that's the gap this is built to close.
More reading