Cursor’s Bugbot belongs before the push, not in the PR

Cursor’s June update turns Bugbot into a fast pre-push gate that catches more bugs for less money.

Cursor’s June Bugbot update is a real product improvement, but the bigger story is strategic: Bugbot should run before the push, not wait for the pull request.

The company says the average review time fell from about five minutes to roughly 90 seconds, while default runs found 10% more bugs and cost 22% less per run. That is not a cosmetic speedup. It changes the economics of when teams choose to ask for machine review at all.

First argument: speed changes behavior, not just metrics

A five-minute review is a checkpoint. A 90-second review is a reflex. That is the practical shift Cursor bought with this release. When a check finishes in under two minutes, teams stop batching risk for later and start running the review every time they touch code. The result is more total review coverage, not just faster individual runs.

Cursor says 90% of Bugbot runs now finish in under three minutes. That matters because review tools only pay off when they are used consistently. A tool that is “good enough” but slow gets skipped when deadlines tighten. A tool that returns before your attention moves on becomes part of the default workflow, which is where defect detection gains compound.

Second argument: pre-push is where the value is highest

Bugbot’s new /review command moves the check earlier in the lifecycle, before a pull request exists. That is the right place to catch mistakes because the cost of fixing a bug rises as it travels downstream. Finding a bad assumption before merge is cheaper than finding it in code review, and far cheaper than finding it after release.

Cursor also added duplicate-diff detection with GitHub and GitLab sync, so a diff reviewed locally does not get billed again when the matching PR opens. That detail matters. It removes the main objection to pre-push review, which is the fear of paying twice for the same work. If the same diff is recognized and skipped later, the workflow becomes economically sensible as well as technically cleaner.

The counter-argument

The strongest case against pre-push AI review is that it can slow developers down at the wrong moment. Teams already fight context switching, and adding another gate before push can feel like process creep. PR review also has a social function that local review does not: it creates a shared artifact for discussion, accountability, and follow-up. If Bugbot moves too much attention upstream, teams may end up with faster code movement but weaker team alignment.

There is also a trust issue. Cursor’s numbers are vendor-stated, and the model behind Bugbot is not exposed through public APIs. That makes the release useful, but not universally portable. If your org needs reproducible review infrastructure across multiple environments, a Cursor-only workflow is a constraint, not a universal fix.

That criticism is fair, but it does not overturn the case for pre-push review. It only sets the boundary. Bugbot should not replace human PR review, and it should not become the only quality gate. It should do one job earlier: catch obvious and subtle defects before they are pushed into shared history. Used that way, it reduces the burden on later review instead of competing with it.

What to do with this

If you are an engineer, run Bugbot before you push on any change that is large, risky, or agent-written. If you are a PM or founder, treat the June update as a signal to move quality checks left, not as a reason to add more review ceremony. Adopt the pre-push gate for speed, keep PR review for coordination, and benchmark the result on your own codebase rather than on Cursor’s headline numbers.