How to Use an AI IDE for a Real Feature Change

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

Sooner than feels reasonable. Cursor's Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. docs say to stop fixing a wrong result through follow-up prompts. Revert the changes, make the plan more specific about what you need, and run it again. The docs call this often faster than fixing an agent that is still running, and say it produces cleaner results.

The advice is easy to skip for a mechanical reason. The work already exists and some of it is right, so throwing it out feels like paying twice. You write a fifth follow-up prompt instead, and the diff ends up carrying two half-approaches that no reviewer can pull apart. Each prompt is cheap and only the total is expensive, so no single moment tells you it is time to restart. Decide on a restart rule before you begin.

Keep the plan where you can find it. Plans are saved to your home directory by default, and "Save to workspace" moves a plan into the repo. For a change big enough to need a plan, save it to the workspace, because the plan is what you will check the diff against a day later.

Queue additions and interrupt corrections.

If you type while the agent works and press Enter, your message joins a queue that runs in order once the current task finishes. ⌘+↵ sends it straight away instead: Cursor appends your text to the most recent user message and processes it immediately. You can drag queued messages to reorder them.

The question is whether the work in flight is still worth finishing. "Also add the empty state" can wait, and it lands better after a coherent unit of work than in the middle of one. "You are editing the wrong file" cannot wait, because every second adds more diff to unpick. Interrupting has a cost too, so you are choosing the smaller of two costs.

If you spot the problem only after the agent has made the change, checkpoints cover you. Cursor creates them automatically before significant changes, and you can restore any point from the chat timeline. They live outside Git, so they undo agent work and do not replace a branch.

Review everything you changed locally, not only the last edit. Agent Review runs a dedicated code review on your local changes from inside Cursor, and /agent-review starts it on demand. Run it from the Source Control tab to compare all your local changes against your main branch. The docs note that this catches issues across your full set of changes.

That matters most on multi-step work. A per-edit review sees each change while it still makes sense on its own. In agent-assisted feature work, look for the cross-edit defect: a helper added in step two and used in step five still has the signature that only step two needed. Neither file is wrong by itself, so reading the edits one at a time misses it.

Agent Review has two depths, and Cursor's guidance is to choose by how thorough a review you need. Quick is fast and low-cost, and it suits small diffs, formatting changes or a sanity check. Deep is slower and costs more, and it is meant for complex logic, security-sensitive code and large refactors.

On a small team, we would run Deep before every pull request, because one deep review costs less than one bad merge.

On a larger team, put the standard in BUGBOT.md, which Agent Review reads. Then the check on someone's laptop and the check on the pull request apply the same rules, instead of two people's memories of them.