Cursor AI, what it is good at and where it breaks

The two products inside one app

Cursor AI is a fork of VS Code with two distinct things bolted on. One is inline: predictive completion and multi-line edits that appear as you type, plus a quick inline edit on a selection. The other is the agent: a chat panel that reads files, edits them, and runs commands until a task is done.

They are not the same tool and they suit different work. The inline half is best when you already know what you want and typing it is the only obstacle. The agent half is best when the change spans files and you would otherwise spend twenty minutes finding all the places.

Teams that struggle usually use one where the other belongs. Asking the agent to rename a variable is slower than doing it. Typing out a twelve-file migration by hand while the agent sits idle is slower still.

Where Cursor AI actually earns time

• Cross-file changes with a clear pattern. Change a function signature and fix every call site, or move a module and repoint the imports.
• Reading code you did not write. "Where does the retry logic for this queue live, and what happens after the last attempt" is one of the strongest uses of the agent.
• Tests for code that already works. Point it at the file and the existing test conventions.
• Boilerplate with a local precedent. It copies the shape of the neighbouring code well.
• Turning an error message into a first diagnosis. Paste the stack trace, let it find the frame that matters.

Where it breaks

Context is the recurring problem. The agent does not read your whole repository, it reads what it retrieves and what you point it at. When output is bad, the cause is almost always that the relevant file was never in context. Referencing files explicitly with @ beats hoping the search finds them.

Second, it does not know your intent history. It will re-derive an abstraction you deliberately avoided, because the reason you avoided it is in someone's head. Write those decisions into .cursor/rules or accept that you will re-litigate them monthly.

Third, long agent runs drift. A task that goes twenty turns produces a diff nobody wants to review, and the last few turns are usually the agent fixing problems it created three turns earlier. Stop it, take the good part, restart with a narrower ask.

Fourth, tab completion is genuinely dangerous in the small. It is right often enough that you stop reading it, and then you accept a suggestion that flipped a comparison operator. The bugs it produces are the hardest kind to spot, because the code looks exactly like what you meant.

The setup that changes the outcome

Three things, in order of return.

Write rules and scope them by glob. Not a manifesto. The facts a new hire needs, and the conventions that keep getting violated.

Give the agent one command that verifies a change, and say so in the rules:

pnpm verify # typecheck, lint, unit tests. Run this before claiming a task is done.

That single line moves more quality than any model setting, because it converts "looks right" into "passed".

Keep the diff small enough that you would review it from a colleague. If you would push back on a human for that pull request, push back on the agent.

What to do next

Pick one task type your team does weekly and run it through the agent three times, logging where it went wrong. You will find the same missing context each time. Write that into a rule file, and you have converted a recurring annoyance into a permanent fix.

If you want help putting this into practice, talk to us.