Cursor, ChatGPT and Claude code review, done by a real developer

Full-app generators like Lovable or Bolt.new produce an entire project in one go, and their common mistakes are fairly predictable because the whole app came from one context window. Cursor and chat-based tools work differently. You're building incrementally, one file or one function at a time, often across many separate conversations or sessions.

That incremental style has a specific downside. The model helping you write function twelve doesn't necessarily remember, or have visibility into, the exact logic in function three. If you asked it to add authentication in one file and validation in another, weeks apart, there's a real chance the two don't line up the way you'd assume they do. Nobody wrote it wrong on purpose. The context just wasn't there.

Why pasted code is a different risk profile. When you paste code from a chat conversation, you're getting a snapshot. The model responded to what you showed it in that specific conversation, which is often a small slice of your actual codebase. It has no idea what your auth middleware looks like, what naming conventions you already established, or what your database schema actually contains, unless you explicitly pasted those in too.

This leads to a specific and common problem: code that's individually correct but collectively inconsistent. One paste handles errors by throwing an exception. Another paste, from a different conversation an hour later, handles errors by silently returning null. Both are "valid" ways to handle errors. Together, in the same app, they're a maintenance headache and occasionally a security gap, especially if one of those silent failures happens to be in an auth check.

A solo developer building a project management tool used ChatGPT for most of the backend logic over about six weeks, pasting snippets in as needed across dozens of separate conversations. Each individual piece worked fine when tested on its own.

The problem showed up in the permissions system. Three different files handled "can this user edit this project" checks, each written in a separate ChatGPT conversation weeks apart, each slightly different from the others. Two of the three correctly checked project ownership. The third, added later when a new feature needed a quick permission check, only verified the user was logged in, nothing about actually owning the project. It sat there for about a month before anyone noticed, purely because it was never tested against someone who was logged in but not the actual project owner.

This is a genuinely common outcome of the paste-as-you-go workflow, not a rare mistake. The individual pieces are usually fine. It's the seams between pieces built in separate conversations that cause the real problems.

We start by looking at your repo's structure and git history if available, since that tells us roughly which parts were built when and helps flag likely seams. From there, the review goes file by file with particular attention to authentication, authorization, and anywhere user input reaches your database or an external API.

You get a written report at the end, organized by severity, not a giant undifferentiated list. Critical issues, the kind that could expose user data or let someone bypass a permission check, are called out clearly at the top. Smaller inconsistencies and style issues sit further down, useful to know but not urgent.

Typical turnaround for a small to mid-sized codebase is about a week from the day we get repo access. Larger projects with a lot of separate conversations' worth of pasted code understandably take a bit longer, simply because there's more ground to cover for consistency checks specifically.