How to hand a change to Cursor without losing control (2026)

Cursor is not a chat with syntax highlighting. It is an editor where a model can apply a patch. The difference between «it saved me an hour» and «it wrecked main» is scope and review. This flow assumes you already ship code. If you cannot read diffs, stop here and come back later.

1. Steps 1

   Isolate the work: branch, repro, done-when

   Create a `fix/…` or `feat/…` branch from a clean main. Reproduce the bug or the happy path locally and write down the command (`pnpm test auth`, «open /login and submit empty»). Write the done-when in one line: «test X passes» or «the form shows the error and does not POST». If you cannot reproduce it, the agent cannot know it is finished. Do not open Agent yet.

   What you should see: Git on a new branch, the repro command run once, and a done-when line in a scratch pad or in a chat you have not sent.

2. Steps 2

   Write the job with a scope (and a do-not-touch list)

   Open Agent and paste a block like this:

   - Outcome: [done-when from step 1] - Files you may touch: `src/…` (3 paths max) - Do not touch: global snapshot tests, CI config, `.env`, generated files - No drive-by refactors or renames - If you need more files, STOP and ask

   Attach the error or the failing test. Do not paste «act like a senior». The model already tries to sound like one. What it lacks is your map of landmines.

   What you should see: The Agent panel with the scope block visible, 1–3 paths, and the stack trace or test in the same message. No edits applied yet.

3. Steps 3

   Demand a five-line plan before the first patch

   Add at the end: «Before you edit, write a 5-line plan: likely cause, files, test you will run, risk. Wait for my OK.» Read the plan. If it proposes a rewrite, a library swap or «simplifying» half a folder, say no and cut it down. If the plan is «change the guard in X, add a case in test Y», OK it. This is the cheap place to stop. A large diff is not.

   What you should see: A short plan in the chat and your «OK, go» or «no, only file X». No files changed yet, unless you allowed it.

4. Steps 4

   Review the diff as if you did not write it

   Open every touched file. Ask three things: does this hunk serve the done-when? Did a test get easier to pass (asserts removed, `toBeTruthy()` where a value lived)? Side effects (I/O, auth, dates, flags)? Read the agent’s explanation after the diff, not before: the paragraph always sounds reasonable. If you do not understand a hunk, do not accept it. Ask it to split the change or discard that file.

   What you should see: A diff view with 1–3 files, hunks you can explain out loud, tests that gained assertions or stayed as strict.

5. Steps 5

   Run the done-when yourself (do not trust the chat’s «all green»)

   Run the same command from step 1 in your terminal, not only the one the agent claims it ran. If it passes, do the 60-second manual path. If it fails, paste the output and narrow: «touch no more files; fix this error». If it passes in a weird way (shorter test, snapshot updated to a nonsense value), treat the change as suspect: revert the test and ask it to fix the code, not the expect.

   What you should see: Your terminal, not the agent’s, with the repro command green or with an error you just pasted back.

6. Steps 6

   Close: a small commit, or revert; pick the next job

   If the done-when holds and the diff is defensible, commit on the branch with a message that states the outcome, not «wip agent». If you are not convinced, `git checkout --` the files or reset the branch. Do not «just fix a bit more» in the same thread: the context is already dirty. Open a new Agent with a smaller job. If the next job is an agent outside the IDE (cron, Telegram, a cloud machine), that is Hermes or Grok Bot — not another lap in this chat.

   What you should see: Either a clean commit on the feature branch, or a clean working tree after revert. The Agent thread treated as closed.

Part of the path Build with agents