For Cursor-built apps

Cursor writes more sophisticated code. And more sophisticated bugs.

Cursor's agent mode produces code that looks closer to what a careful engineer would write than Lovable or Bolt. That's the danger: the bugs hide better. Race conditions in optimistic UI. Abstractions that drift apart across sessions. Tests that pass because they never check the adversarial path.

Book a free audit
§ I. Patterns

What we read for in Cursor apps.

Cursor's failures are less about missing-the-obvious and more about drift over time. The patterns below are what we look for first.

  1. 01

    Refactor drift across sessions

    HIGH

    A long Cursor session builds something coherent. A second session refactors it for a 'cleaner pattern.' A third adds a feature, assuming the second finished cleanly. Each session is reasonable; the end state is two versions of the same function with subtly different rules, and the wrong one gets called.

  2. 02

    Optimistic updates without reconciliation

    HIGH

    Cursor writes more sophisticated client-state code than other tools. It also writes more sophisticated client-state bugs: optimistic updates that don't reconcile with server state, double-submissions, lost updates under concurrency.

  3. 03

    Tests that pass without testing what matters

    HIGH

    Cursor writes tests when asked. The tests cover the happy path it just implemented. 'User can log in' is tested. 'Unauthenticated user gets 401' is not.

  4. 04

    Type-safety theater

    MED

    TypeScript everywhere, and .as, .any, or runtime data coerced into types that don't match. The compiler stays quiet. The app crashes at runtime when an API returns something the type said couldn't happen.

  5. 05

    Inconsistent error shapes

    MED

    Some endpoints return JSON errors. Others throw. Others return empty arrays on failure. Client code assumes one shape and silently mishandles the others.

  6. 06

    Auth refactored mostly

    CRIT

    Cursor often touches auth at some point in the project. The new flow gets implemented; the old flow gets mostly removed. The 'mostly' is where the bug lives.

6 patterns 1 critical 3 high 2 medium
§ II. Root cause

Why Cursor ships these patterns.

Cursor's agent runs in your editor, with access to the full codebase and the ability to read, refactor, and re-test as it goes. That power is also the failure mode: a single session can introduce a feature, partially refactor it for some "cleaner pattern," and leave both versions in the codebase. The agent's view is what it just touched, not the cumulative state of everything that came before.

Auditing a Cursor codebase reads like auditing a codebase written by three engineers who never spoke. The audit takes longer than a Lovable or Bolt audit for the same reason, but the failure patterns are consistent enough that we know where to look.

Auditing a Cursor codebase reads like auditing a codebase written by three engineers who never spoke.

Cursor audit notes
§ III. Honest limits

What this approach won't catch.

We audit for the patterns multi-session AI development produces. We don't reconstruct architectural intent from a codebase where the original direction was never clear. For that, you want a different kind of engagement. If the codebase has hit the point where you're not sure what it's trying to be anymore, the audit will surface the gaps, but the deeper question is one we'll raise on the call.

Book a free audit for your Cursor app