From Cursor prototype to production application

Cursor, v0, Lovable and the rest of the current generation of AI coding tools are genuinely good at what they do — a working prototype in an afternoon that would have taken a week by hand. That speed is real, and it's not the problem. The problem is what the speed hides: none of these tools know your product is going to production, so none of them build for that, and the gap between 'runs' and 'production-ready' is invisible until it isn't.

This is a specific, recurring set of omissions, not a general complaint about AI-generated code. Here's what's consistently missing and where to look for it.

Auth that exists only in the interface

Ask an AI coding tool to 'hide the admin panel from regular users' and it will very competently hide it — in the frontend. The API route underneath frequently has no independent check. This is the single most common vulnerability in AI-generated applications, because it's invisible in the UI (which is all a demo checks) and only shows up when someone calls the endpoint directly.

Check every endpoint that returns or modifies data, not just the ones with a visible button in front of them. If the check for 'is this person allowed to do this' lives only in a component, it isn't a check.

A data model shaped by the first feature, not the product

AI tools build the schema that satisfies the prompt in front of them. That's reasonable for a single feature and frequently wrong for the product as a whole, because the tool has no view of what you'll ask for next. The result is usually workable but has specific gaps: missing foreign keys, no constraints enforcing rules the application assumes are true, a shape that made the third feature much harder to add than it should have been.

Read the schema deliberately once the prototype has a few features in it, not just the first one. This is far cheaper to fix at feature three than at feature twelve.

No idea what happens when a model call fails

Prototypes are built and tested against a model that responds. Production traffic includes timeouts, malformed output, rate limits and provider outages, none of which a coding assistant has any reason to simulate while it's building your happy path.

• A timeout on every model call, with a visible fallback state instead of an indefinite spinner.
• Schema validation on model output, with a bounded retry when it doesn't parse.
• A rate limit per user, so one script or one bad loop can't spend a month's budget in an hour.

No visibility once it's running

A prototype gets debugged by watching it run in front of you. A production application gets debugged by reading what it recorded, days later, from a report that says 'it did the wrong thing yesterday' with no other detail. If there's no error tracking and no structured logging, every production bug becomes an investigation with no evidence.

The tool optimised for you seeing it work once. Production needs to keep working when you're not watching.

Deployment config copied, not understood

It's common to see environment variables, CORS settings and build configuration accepted as generated rather than reviewed line by line. Most of the time this is harmless. Occasionally it's a CORS policy open to any origin, or a debug flag left on in what's meant to be production. Fifteen minutes reading the actual config catches this before it ships, not after.

The honest framing

None of this is an argument against building with AI tools — it's an argument for treating the output the way you'd treat a fast, capable, context-blind collaborator: genuinely useful, and worth a deliberate pass over exactly the parts it had no way to know mattered. That pass is usually a few days of focused work, not a rewrite, if it happens before launch rather than after an incident.