AI Coding Agents

The working pattern for coding agents 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 coding agents 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.

Cursor ships often, so here is the current state of the surfaces this page touches. Each row links to the source where you can confirm the detail.

Start local, in the editor, on work someone was going to do that week anyway. The order that holds up after that is cloud runs, then /loop, then /automate, then the SDK. Read it as a supervision ladder rather than a difficulty curve, because each rung has fewer people watching.

So the reason to keep that order is what happens between the rungs. 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 what you inspect is the result instead of the run. /loop repeats a prompt locally until you stop it. /automate fires on a schedule, a Slack message, a GitHub event or a webhook, which means it can run at three in the morning while nobody is looking at anything.

Automations are, I suspect, the most tempting place to begin, because a scheduled agent reads like free work. Teams that start there usually find out their review habit was thinner than they thought, and they find out against a queue of pull requests that arrived overnight.

A Monday morning with a queue of overnight pull requests on it. Not the moment to be inventing a review process.

Worth being exact about the risk, though, because it is narrower than it sounds. An automation does not merge. It produces a pull request a human reviews, and whoever clicks merge owns the change. What actually changes is who can start one: wire a code-touching automation to a Slack channel and everybody in that channel can trigger an agent, which is why triggers take allow-list filters on people, channels, keywords or a regex. Scope the trigger first and the rest of the automation guide is detail.

The SDK sits last for a reason unrelated to how hard it is to use. SDK runs draw on the same request pools as a developer prompting in the editor, and the spend shows up in the team usage dashboard under the SDK tag. A script that loops over a hundred files spends real money against somebody's budget, and which budget depends on whether you handed it a user key or a service-account key.

As many as you can review properly, which is a smaller number than the interface implies. The agent count is a property of the tool. The review count is a property of your team, and only one of the two is displayed anywhere.

Overlapping files are the mechanical half of the problem, and isolation solves that half cleanly. 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, and /worktree sets one up from the CLI.

The awkward part is that isolation tidies the collisions and leaves the constraint that matters untouched. Four isolated agents still produce four diffs, and those land on one person who has to hold four different sets of intentions in their head while reading them.

That argues for capping the number of parallel agents. Actually no, the count is the wrong control. Two agents on a config change you understand cost less attention than one agent loose in a service nobody has read this year. Cap the unfamiliar surface instead, meaning how many files you are willing to read carefully today, and let the agent count fall out of that.

/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, and what comes back is review evidence rather than a verdict. Humans still own merge. That distinction is, I think, the first thing to go as the count climbs, because a passing bot check is exactly what a tired reviewer will accept in place of reading the diff.

On a team of three the ceiling is one person's afternoon.

On a team of thirty it is whether anyone owns the queue. Larger teams usually have the review capacity and no rule about who spends it, so agent diffs pool up against whoever is most conscientious about picking them up. Naming an owner per queue is duller than tuning prompts and it does more.

Nearly all of the control plane, and it should. Under roughly ten people, one shared rules file, one convention about who launches cloud work and a habit of opening diffs will carry a team further than any admin setting.

Context and review. Those are the two that bite at that size, and neither of them has a dashboard, which is part of why they get skipped.

Past that size the controls exist because informal agreement stops holding. Organizations sit above teams, groups scope model, spend and agent permissions, and the monthly team-wide spending limit is set in the dashboard. Enterprise accounts add pooled usage, where member limits apply to total usage rather than only to on-demand spend.

The line that catches teams out is quieter than any of those, and probably the most expensive small print in the setup. SDK and CLI agents authenticate with an API key, draw on the same pooled usage as everyone else and do not consume a paid seat, so anyone on the account can generate a key and spend against the pool. Set the limit before you point automation at it.

The sequencing honestly matters more here than which controls you pick. A group boundary drawn before anyone has run agents in anger encodes a guess about how the work will flow, and that guess is usually wrong in both directions at once, too tight where people improvise and too loose where the money leaks.

So write the policy after the pilot. Just not long after.