What a Senior Dev Actually Finds When Reviewing Cursor Code

Cursor is probably the most capable AI coding tool available. It understands context, follows patterns, and can build genuinely complex features. If you've built something substantial with Cursor, it probably works.

But "works" and "production-ready" are different things. When our developers review Cursor-generated codebases, here's what consistently comes up.

Error handling is optimistic

Cursor-generated code tends to follow the happy path. API calls assume success. Database queries assume they'll return data. External services are treated as always-available.

In production, things fail constantly. APIs timeout, databases return unexpected nulls, third-party services go down. Without proper error handling, your app doesn't degrade gracefully — it crashes.

What we look for: Try/catch blocks around all external calls, fallback states for failed data fetches, proper error boundaries in React, and meaningful error messages instead of blank screens.

State management grows into a mess

Cursor is great at solving individual feature requests. Ask it to add a filter, it adds a filter. Ask it to add sorting, it adds sorting. Ask it to add pagination, it adds pagination.

The problem is each feature gets its own state management approach. You end up with a mix of useState, useEffect, context providers, URL params, and local storage — all managing related state in different ways.

The tell: If your component has more than 5-6 useState calls, or you're passing props through 3+ levels, or the same data is stored in multiple places, the state management needs consolidating.

Types are loose or missing

Cursor will use TypeScript if your project is set up for it, but it tends toward loose typing — lots of any, optional chaining everywhere as a substitute for proper null checks, and interfaces that don't accurately describe the data.

Loose types mean your TypeScript is giving you a false sense of security. The compiler isn't catching bugs it should be catching.

What we tighten: Replace any with proper types, add strict null checks, define accurate interfaces for API responses, and enable strict mode in tsconfig.json.

Security is an afterthought

This isn't unique to Cursor, but it's worth calling out. Cursor writes code that does what you asked — it doesn't proactively add security measures you didn't ask for.

If you didn't prompt for rate limiting, there's no rate limiting. If you didn't ask for input sanitisation, user input goes straight to the database. If you didn't specify auth checks on every route, some routes are unprotected.

The mindset shift: Security isn't a feature you add. It's a review you do after every feature. Every endpoint needs auth checks, every input needs validation, every secret needs to be server-side only. We've put together a vibe coding security checklist that covers the 15 most critical items to review.

No tests

This is the most consistent finding. Cursor-generated codebases almost never have tests — not unit tests, not integration tests, not end-to-end tests. This means every change is a gamble. You fix one thing and break two others, with no way to catch it before users do.

The minimum: At least add tests for your critical paths — authentication, payment flows, data mutations. You don't need 100% coverage. You need confidence that the important things work.

The bigger picture

None of this means Cursor code is bad. It's often impressively functional. The gap is between "functional" and "maintainable, secure, and scalable" — and that gap is exactly what a code review from an experienced developer closes. Not sure where your app stands? Our production readiness checklist is a good place to start scoring yourself.

If you've built something with Cursor and want an honest assessment of where it stands, get a free security snapshot from our team. We specialise in getting Cursor projects production-ready.