Cursor agents and the work they are actually good at

The test for handing work to Cursor agents

Cursor agents can read the repo, edit across files, run commands, and iterate until something passes. That is a different tool from inline completion, and it deserves a different decision.

Before you delegate, ask three questions. Does the task span more than two files? Is it mechanical enough that you could describe the finished state precisely? Is there an automatic check, a test suite, a type check, a build, that says whether it worked?

Three yeses means delegate. Two means you will spend longer reviewing than doing. One means write it yourself.

The third question is the one people skip, and it is the important one. Without a check, the agent has no way to know it is finished, and neither do you. You end up reading every line, which is exactly the labour you were trying to avoid.

Tasks that work

The reliable wins we see:

• Mechanical migrations. Move every call site from one client library to another, where the type checker fails loudly on anything missed.
• Test backfill on an untested module, with coverage as the check.
• Fixing a red suite after a dependency bump.
• Renaming a domain concept across code, tests, and fixtures, where find-and-replace breaks on the edge cases.
• Turning a spec or an OpenAPI file into client code plus its tests.

Tasks that go badly: anything where the requirement is still fuzzy, anything touching auth or billing logic, and any first implementation of a pattern the codebase has not settled on yet. The agent will pick a pattern, and you will inherit it.

Scoping so review stays cheap

Review cost is the whole ballgame. A 40-file diff you did not anticipate costs more attention than writing the change would have.

Three habits keep it down. State the finished condition, not the steps: name the test command that must pass, for instance npm test -- --run, and let the agent work out how to get there. Name the boundary explicitly, including directories it must not touch. And ask for a plan before edits on anything non-trivial, because reading a wrong plan takes thirty seconds and reading a wrong diff takes thirty minutes.

Then cancel early. The strongest habit we teach is interrupting the moment the agent's first two edits look off-target. People feel rude doing it. There is nothing to be rude to, and letting a bad run finish costs you a full review.

What still goes wrong

Agents make tests pass rather than making code correct, and those are not the same thing. Watch specifically for assertions weakened to match the implementation, and for a skip or an exclusion added to a test file. Whenever an agent touches test files in the same run as source files, read the test diff first.

Long runs also drift. Twenty minutes in, the early instructions are far back in context and the agent starts solving a slightly different problem. Shorter, chained tasks beat one heroic prompt almost every time.

What to do next

Take the migration ticket everyone has been avoiding, the one that is tedious rather than hard. Write the finished condition in two sentences, name the check, name the off-limits directories, and run it. Review the test diff before the source diff. If the result is good, you have found the shape of task worth delegating, and you can go looking for more of them.

We run this exercise on client repos with real tickets, which tends to settle the internal debate faster than a demo does.

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