AI Coding Agents

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.

Cursor ships often, so advice about it can go out of date. The table summarizes Cursor's recent releases, so you can check this page against the current product. For each release's date and sources, see What's new in Cursor 2026.

Start local, in the editor, on work someone was going to do that week anyway. Real work gives you a fair test, because someone on the team already knows what a good result looks like. After that, the order that holds up is cloud runs, then /loop, then /automate, then the SDK. Cloud runs and automations need Premium or higher, a Teams or Enterprise plan, or a legacy plan that includes them, which leaves out Free and Plus.

Read that order as a supervision ladder. Each rung has fewer people watching the run. A local run happens in front of you, and you stop it when it goes somewhere strange. /in-cloud hands the next task to a subagent in its own VM and branch, so you inspect the result instead of the run. /loop reruns a prompt or skill at an interval you set.

An automation built with /automate goes furthest. It fires on a schedule, a Slack message, a GitHub event or a webhook, so it can run at three in the morning with nobody watching.

That makes automations the tempting place to begin, because a scheduled agent looks like free work. Start there, and on Monday morning you test your review habit against a queue of pull requests that arrived overnight. Agree on how those get reviewed before the first queue lands, and move up a rung only once reviewing the current one is routine.

Be exact about what an automation can do. It doesn't merge. When it changes code, it opens a pull request that a person reviews, and whoever clicks merge owns the change.

What automations change is who can start a run. Wire a code-touching automation to a Slack channel, and everyone in that channel can trigger an agent. A trigger that fires on every message in a busy channel also builds a queue. Narrow it with the trigger's filters, such as a keyword or regex on Slack messages. Then put the rest in the prompt: Cursor's docs suggest a quality bar for when the agent should open a pull request, comment or do nothing.

Scope the trigger before anything else. The automation guide covers the rest of the setup.

The SDK sits last on the ladder because of how it spends money. SDK runs draw on the same request pools as a developer prompting in the editor, and the spend shows up under the SDK tag in the team usage dashboard. A script that loops over a hundred files spends real money against somebody's budget. Whose budget depends on whether you gave it a user key or a service-account key.

As many as you can review properly, which is fewer than the interface suggests. The agent count is a property of the tool. The review count is a property of your team, and only the agent count shows up on screen.

Isolation solves the mechanical half of the problem. Two agents editing the same file leave you with conflicting edits, so give each one its own git worktree, an isolated checkout of the same repo. The Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. supports worktrees directly. In the editor, the /worktree command starts one, and the CLI takes a --worktree flag.

Isolation does nothing for the constraint that matters. Four isolated agents still produce four diffs, and one person has to read them while holding four different intentions in mind.

So cap the unfamiliar surface, not the agent count. Two agents on a config change you understand cost less attention than one agent loose in a service nobody has read this year. Decide how many files you can read carefully today, and let the number of agents follow.

/review runs BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. or Security Review over your changes before you push. It returns review evidence for a person to weigh, and humans still own merge. That boundary slips first as the agent count climbs, because a tired reviewer will accept a passing bot check in place of reading the diff.

On a team of three, the ceiling is one person's afternoon. On a team of thirty, it depends on whether anyone owns the queue. A large team can have the review capacity but no rule about who spends it, and then agent diffs pile up with whoever is most conscientious. Name an owner for each queue.

A small team can skip nearly all of the control plane. Under roughly 10 people, one shared rules file, one convention about who launches cloud work and a habit of opening diffs carry a team further than any admin setting. What hurts at that size is weak context and weak review. Neither shows up on a dashboard, which is part of why teams skip them.

Past that size, the controls exist because informal agreement stops holding. On Enterprise, a group gives a cohort its own model access, spend limit and agent permissions without a new team. Admins set a monthly team-wide limit on additional usage. Enterprise accounts can also add pooled usage, one committed pool for the whole team, with member-level spend alerts on total spend, not only on additional usage.

API keys are the detail teams miss. SDK runs and scripted CLI runs authenticate with an API key, and any member can generate a user key without a new seat. On Enterprise, a service-account key doesn't take a seat either, and its usage draws on the team's pool like everyone else's. Set the spending limit before you point automation at it.

Timing matters more than which controls you pick. A group boundary drawn before anyone has run agents on real work encodes a guess about how that work will flow. The guess is usually wrong in both directions. It is too tight where people improvise, such as a model block that stops one project, and too loose where money leaks, such as a pilot group's high spend limit that nobody lowers afterward. Write the policy after the pilot, and soon after it.