AI Pair Programming in Cursor: How It Works

Cursor describes it as working alongside a coworker: you describe your task, and the agent reads your codebase, makes changes to files, runs shell commands, and automatically fixes any errors it hits. Then you review the code, give feedback, and work together to arrive at the right solution.

The self-correction clause is the part that changes the job. An agent that runs a command and reads the error can fix its own broken build before you ever see it, so what reaches your review is usually a working change. Reading a working change is a different task from reading a suggestion that was never executed.

The coworker comparison holds up for about a minute. With a human pair you both watch the same screen, so the reviewing happens continuously, a line at a time. Here it batches instead. The agent works, then hands you the finished thing, and so the length of turn you allow also sets the size of the review you have agreed to do. Keep turns short enough that you get through the whole diff.

Self-correction reaches the errors the agent hits, meaning the ones that announce themselves. A command comes back non-zero, the agent reads the output and tries again. A requirement you never stated produces no error at all: the build goes green, the tests pass, and the change solves a slightly different problem than the one you had in mind. When a session ends somewhere strange, read the prompt before you read the code. In my experience the prompt named the outcome and left the constraint out.

An AI coding assistant is software that helps you build software using large language models. In Cursor that assistant is an agent, which is a narrower claim than it sounds: you give it a goal and it plans and carries out the work, rather than only answering questions.

Cursor works with every frontier model and tunes its harness to each one to get the most out of it, so the assistant is not a single model with a single personality. If you want to see how the models compare rather than take the claim on trust, Cursor publishes results on the CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. Press Enter for the full definition. page.

That benchmark deserves a second look if you are picking a model to pair with. CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. Press Enter for the full definition. scores token efficiency as well as task performance rather than accuracy alone, and efficiency is, I think, the half that shows up in a pairing session, since the tokens a model spends on the way to an answer are also the output somebody has to read. Weigh how much it produced alongside whether it got there at all.

Four steps, and the last one is the one people skip. Cursor's documented sequence ends at the pull request, not at the working diff.

1. 1Open the agent with ⌘+I.
2. 2Describe your task, referencing files as needed.
3. 3Review the output from the agent, and reply with feedback to refine.
4. 4Ask Cursor to create a pull request to finish your work.

Step two is where most of the quality comes from. Referencing files means typing @ and naming them, which is how you stop the agent guessing at which component you meant.

The conversation does not close when you press enter. Agent can put a clarifying question to you mid-task, and while it waits it carries on reading files, editing and running commands, folding your answer in as soon as that answer arrives. Nothing blocks. That cuts both ways in a pairing session. Stepping away does not hold the run up, and a reply you give ten minutes late lands ten minutes into work it chose without you.

The order of steps three and four matters more than it looks. Feedback in the chat lands while the agent still holds the context it built, the files it read and the errors it hit. Feedback on the pull request lands outside that thread, so whoever picks it up rebuilds that context by hand. Refine in the thread until the change is the one you want, then ask for the PR.

The pull request also carries a marker you may not have chosen. Cursor appends a Made with Cursor trailer to Agent commits and PRs by default, and Enterprise admins can switch it off for everyone from the dashboard, which overrides whatever individuals set. On a two-person team that is noise. Past a certain size somebody asks what share of the repo the agents wrote, and the thing that answers that is Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition., which annotates the git history rather than the commit message. The trailer is a smaller decision, and I would leave it on.

Pair programming as Cursor describes it is Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition.: you and the agent both changing the same code. The two neighbouring modes exist because not every task wants a file edit as its first move.

Expensive, in the Plan row, mostly means expensive to read. The diff arrives finished, so the way you discover it was the wrong shape is by reaching the end of it.

Ask is listed for understanding before you change anything, and I followed that rule for a long time. True, and not much use at the keyboard. What decides it is whether you can name the files. If you can, going straight to Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition. with those files referenced often answers the question on the way to the change. If you cannot, Ask is the cheaper place to find out what you are dealing with. Rotating modes is ⇧+⇥ from the chat input, so the pick is not a commitment.

Two things stay with you however well the session went: what counts as done, and whether the change merges. Cursor's documented loop ends at the pull request, and reviewing is listed as your step rather than the agent's.

Some of the reading can be handed off without handing off the decision. Agent Review has the agent critique its own diff, on demand with /agent-review or automatically after each commit, at Quick or Deep depth. It clears the obvious problems out of your queue before you open the diff. Whether the change was the right one to make is still yours, since nothing in the loop knows what you were after beyond what you wrote down.

How much of this you formalise depends on who reviews. On a small team the person who wrote the prompt is usually the person reading the diff, so the loop can end in the chat thread and nothing is lost. Once those are two different people the intent has to leave the thread: 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. can save a plan into the repo with Save to workspace, and a constraint restated in the PR description does the same job more cheaply. A reviewer who was not in the conversation should be able to tell what you asked for.