What happened

Cursor, the AI coding tool, launched two automated bots that work after your code is written, not during it. Cursor’s announcement describes Rollouts, which watches a change from the moment its pull request opens to the moment it’s live in production, and Security Reviewer, which scans pull requests for security bugs and proposes fixes.

Both are live today, but only on Cursor’s Teams and Enterprise plans. If you’re on Cursor Pro as a solo builder, you can read about what these bots do, but you can’t turn them on yet.

Why it matters

Rollouts needs three things connected before it can do anything: your source control (like GitHub), your deploy system, and a telemetry platform, meaning a tool that already tracks your app’s metrics and error traces, such as Datadog, Grafana, or Honeycomb. If you don’t already have one of those wired up, Rollouts has nothing to compare against.

For teams that do have that in place, here’s the workflow. Before a pull request merges, Rollouts reads the code change and writes a monitoring plan: what could go wrong, what the change is supposed to do, and which parts of your telemetry can’t actually confirm whether it worked. You can edit that plan before merging.

After the change deploys, Rollouts compares your live metrics against how things looked right before the deploy, which Cursor calls the baseline. If it spots a problem, what happens next depends on how you configured it: it pings whoever wrote the code, pauses a progressive rollout (sending the new version to a small slice of users before everyone gets it), or opens a pull request that reverts the change and waits for a human to approve it. Cursor is explicit that a revert always waits for your approval. It does not merge that on its own.

The part worth sitting with is what Rollouts says it does well today: catching a regression, meaning something that used to work and broke because of this change, when it’s confined to one part of your app in one region, before a company-wide alert would ever fire. It also tells a deliberate change in behavior apart from an actual bug, and flags before merge when your monitoring can’t actually tell you if a change worked. That last one addresses a real, common failure: a change ships, nothing alerts, and weeks later someone discovers it broke something nobody was watching for.

Security Reviewer works differently. It reads every pull request looking for specific categories of bugs: ways user input could reach your database or system commands unsafely (the kind of bug that lets an attacker inject their own commands), broken login or permission checks, secrets like API keys accidentally left in code, and dependencies, meaning the outside code libraries your app relies on, that have known security holes. For each one it finds, it explains the severity, how an attacker could actually exploit it, and offers what Cursor calls a one-click fix.

That phrase is doing some work. A one-click fix means Cursor proposes the corrected code for you to apply, not that it rewrites your app unattended. Treat every fix as a suggested change to read before you accept it, the same way you’d read a fix a junior engineer proposed. Security-sensitive code is exactly the code where a plausible-looking but subtly wrong fix causes more damage than the bug it replaced.

Who should care

Teams already running Cursor on a paid Teams or Enterprise seat, with a deploy pipeline and a metrics tool already in place. If that’s not your setup, this is still worth knowing about: it’s a signal that coding agents are expanding past writing code and into watching what that code does after it ships.

What builders should do next

If you have access to these bots, enable them from the automations tab in your Cursor dashboard, one bot at a time. Turn on Security Reviewer first since it needs no other setup, and read its first few fixes in full before accepting any of them, so you can judge whether its explanations match what you’d expect from your own codebase.

For Rollouts, don’t accept the auto-generated monitoring plan as-is on your first pull request. Check it against a change you already understand well, and confirm it correctly flags any part of your app that your telemetry doesn’t actually cover. If it misses an obvious gap on a change you know, it will miss that same kind of gap later, when you don’t.

The bottom line

Cursor is betting that the next place coding agents add value isn’t the editor, it’s everything that happens after the pull request merges. The guardrail that matters most here is real: reverts wait for a human. But “wait for approval” only works if someone is actually reading the plan and the fix before clicking yes, not treating the bot’s confidence as a substitute for their own.

End of article