How to Use an AI IDE for a Real Feature Change

The working pattern for AI IDE feature work is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Running AI IDE feature work as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

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.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains 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.

Sooner than it feels reasonable to. Cursor's guidance on plan mode is to stop trying to fix a wrong result through follow-up prompts: revert the changes, make the plan more specific about what you wanted, and run it again. The docs say that is often faster than fixing an agent mid-flight, and that it produces cleaner results.

Almost nobody does this, and the reason is not ignorance. The work already exists and some of it is right, so throwing it out feels like paying twice, and instead you write the fifth follow-up prompt and end up with a diff carrying two half-approaches that no reviewer can pull apart. I used to frame that as sunk-cost stubbornness, which puts it on the person. It is more mechanical than that. Each prompt is cheap and only the total is expensive, so no single moment announces itself as the one where you should have restarted. Which argues for setting the restart rule before you begin rather than during.

Where the plan lives matters for this. Plans are saved to your home directory by default, and "Save to workspace" moves one into the repo. For a change big enough to warrant a plan at all, put it in the workspace, because the plan is the thing you will want to read the diff against a day later.

Queue the additions and interrupt the redirections. Typing while the agent works and pressing Enter puts your message in a queue that runs in order once the current task finishes, and ⌘+↵ sends it straight away, appending your text to the most recent user message so it is processed immediately. Queued messages can be dragged to reorder, which becomes useful faster than you would expect.

The distinction is whether the work in flight is still worth finishing. "Also add the empty state" can wait, and waiting is better, since it then lands after a coherent unit of work instead of inside one. "You are editing the wrong file" cannot wait, and every second it does is more diff to unpick. Interrupting is not free either, so this is really a judgement about which cost is smaller.

Then there is the case where you notice too late, and checkpoints cover that one. Cursor creates them automatically before significant changes and you can restore any point from the chat timeline, though they live outside Git, so they undo agent work rather than standing in for a branch.

A review of the whole set of local changes, not the last edit. Agent Review runs on your local changes from inside Cursor. /agent-review triggers it on demand, and running it from the Source Control tab compares everything you have changed against your main branch, which the docs point out catches issues across your full set of changes rather than only the most recent one.

That distinction is the entire value on multi-step work. A per-edit review sees each change while it still makes sense locally. The defect in agent-assisted feature work is usually the cross-edit kind: a helper introduced in step two, used in step five, left with the signature step two happened to need. Nothing is wrong in either file on its own, which is precisely why reading the edits one at a time misses it.

There are two review depths, and Cursor's framing is to pick on how thorough a review you need. Quick is fast and cheap and suits small diffs, formatting changes or a sanity check. Deep is slower and costs more, and is meant for complex logic, security-sensitive code and large refactors.

On a small team I would run Deep before every pull request and stop thinking about it, since the cost of one deep review is nothing next to one bad merge. On a larger team the interesting move is different. Put the standard in BUGBOT.md, which Agent Review reads, so the check running on someone's laptop and the check running on the pull request are testing the same rules rather than two people's memories of them.