Both show up on the Automations page now, and both can review a pull request and leave comments. I’m trying to understand what I actually gain or lose by picking one over the other.
From what I can tell, Bugbot is the managed option — it reviews on every push, posts a check status, avoids repeating comments it already made, and you steer it with .cursor/BUGBOT.md rules rather than a prompt. A custom automation lets me write the prompt and pick the model, and it can push fixes instead of just commenting, but I’d be building the review workflow myself.
I’ve run both on the same PR, and they don’t seem to be aware of each other — I get two separate reviews covering overlapping ground rather than one building on the other. Is that expected, or is there a way to have the custom automation take Bugbot’s findings into account?
And for anyone who has tried both: is a custom automation worth it for normal code review, or is Bugbot better at that and custom automations are really for other things?
Hey, thanks for the detailed breakdown, your comparison is basically correct.
On the main point, yes, this is expected behavior. Bugbot and a custom Automation are two independent systems, and today they don’t know about each other. Neither one reads the other’s output when building context, and Bugbot dedup only works against its own past findings. So on the same PR you get two separate reviews with overlap, not one review that builds on the other. There isn’t an out of the box way to automatically pull Bugbot findings into a custom Automation yet.
How I’d choose:
Bugbot: for standard code review. It’s built for that and comes with dedup, incremental review, PR check status, rule control via .cursor/BUGBOT.md, analytics, and Autofix. It can spawn a Cloud Agent to push fixes for its findings, so you don’t need a separate Automation for that.
Custom Automation: for what Bugbot doesn’t do. Your own review policy with a specific model, non review workflows like docs, triage, CI autofix, cron scans, or fixes triggered by events other than Bugbot findings.
Running both on the same PR means duplicated coverage by design. If you want to keep both, it’s worth narrowing the Automation prompt so it doesn’t do generic bug finding that Bugbot already covers.
A partial prompt level workaround: instead of triggering Automation on push or PR opened, trigger it on a human action like adding a label or a human comment after the Bugbot check finishes. Then an agent with repo access and gh can first fetch the existing PR review comments including cursor[bot] and the prompt can say don’t repeat them, add new value. The catch is that on a normal push or PR opened trigger, Automation starts at the same time as Bugbot, so Bugbot’s comments for that push won’t exist yet when Automation reads the PR. That’s why a label after Bugbot completes is more reliable.
Let me know if you want help putting together that prompt.