Ito vs Cursor Bugbot (2026): Reviewing the Code You Just Generated
In-editor review vs the merge gate
Ito
Runtime AI code review at the merge gate. Works with any editor or coding agent.
Cursor Bugbot
Static review inside Cursor. Catches logic errors as your agent writes them.
Cursor Bugbot vs Ito at a glance
| ITO | CURSOR BUGBOT | |
|---|---|---|
| Where it runs | The pull request | Inside Cursor, and on PRs |
| When it runs | At the merge gate | As you write, and at review |
| Analysis type | Runtime execution | Static |
| Executes your code | Yes | No |
| Catches | Broken flows, runtime errors, dead integrations, regressions in files the PR never touched | Logic errors, edge cases, bugs in freshly generated code |
| Evidence | Video, logs, repro steps, a failing test | Inline explanation and a suggested fix |
| Requires your team uses Cursor | No. Any editor, any agent. | Yes |
| Covers code written elsewhere | All of it. Human, Claude Code, Copilot, anything. | Strongest on code written in Cursor |
| Pricing | $40/seat/mo, unlimited repos1 | Add-on to a Cursor subscription2 |
Why agentic coding broke code review for AI generated code
Agentic coding didn't just change how code gets written. It broke the assumption review was built on.
Code review was designed around a rate limit that no longer exists. One human could only open so many pull requests a week, so another human could plausibly read them. Teams running coding agents removed that limit on the writing side and kept it entirely on the reviewing side.
You get a queue that grows faster than anyone can drain it, reviewed by people who know they can't read it all properly. Approval rates hold steady. Attention per PR collapses. Nobody says this in standup.
Bugbot answers part of this well. Catching a bug in the editor seconds after generation is the cheapest place to catch anything, and staying inside Cursor means no context switch. If your team lives in Cursor, that loop is fast.
It's still reading, though. And agent-written code has a specific signature. It's syntactically clean, plausibly structured, and confidently wrong about something it couldn't verify. An API shape that changed. An assumption about data it never saw. A flow it never walked.
That code reads fine. It just doesn't work.
Two layers, not two options
Bugbot at authoring time:
- Sees the code the moment your agent writes it
- Flags logic errors and edge cases inline
- No context switch. You're already in the editor.
- Blind to anything only visible at runtime
Ito at the merge gate:
- Builds the app once the PR opens
- Drives the flows your change touched
- Catches regressions in files the PR never edited
- Works no matter who or what wrote the code
Six bugs an agent writes, and where each one gets caught
Agent-written code fails in a specific way. It is clean, plausible, and confidently wrong about something it could not check.
| BUGBOT | ITO | |
|---|---|---|
| Off-by-one in generated pagination — Visible in the source the moment it is written. | Caught | Caught |
| Unreachable branch in generated logic — Static analysis is good at this. | Caught | Missed |
| Hallucinated method on a real library — Plausible name, does not exist. Sometimes caught in the editor, always caught at runtime. | Caught | Caught |
| Assumed an API field that was renamed — The agent never saw the current response. | Missed | Caught |
| Regression in a flow the PR never touched — Outside the diff entirely, so there is nothing to read. | Missed | Caught |
| Code written outside Cursor — Claude Code, Copilot, a person. Bugbot is strongest on what it watched get written. | Missed | Caught |
The overlap is real and useful. So is the gap. If you ship agent PRs daily with only one of these two, the missing layer is the one costing you.
What this looks like across 43 real pull requests
The case for a merge gate, in one team's numbers rather than in theory.
DoltHub ran Ito across 43 pull requests over six weeks. Fixed versus dismissed is the number to watch, because at high PR volume a noisy tool does not just waste time. It trains your team to stop reading.
Eighty-one percent were unique to runtime, which means authoring-time review had no line of sight to them. When agents are opening pull requests faster than anyone reads them, that is the share of risk moving straight through to main.
A real pull request, in public, that you can go and read
This is what the merge gate is for. One public pull request, four defects, none of them visible at the moment the code was written.
Chatwoot is a widely used open-source customer engagement platform. In July 2026 a pull request touched their Freshdesk data import. Nothing here was caught at authoring time, because at authoring time there was nothing wrong to see.
Import counts silently regressed under concurrency, Concurrent workers could push progress metrics backwards while cursors advanced. The numbers went down and nothing errored.
Rate-limit handler ignored the provider's retry delay, Freshdesk returned a requested backoff. The code did not honor it.
Placeholder inbox creation bypassed after_create callbacks — Working hours never initialized, because the callback that sets them never fired.
Non-atomic claim on DataImportItem — Two workers could claim the same item, producing duplicate deliveries.
Final run: 1 fixed, 14 passing. Safe to merge. The maintainer fixed all four, using row-level locking and monotonic cursor comparisons for the concurrency bug. Merged 5 August 2026.
Link to PR: https://github.com/chatwoot/chatwoot/pull/15261
None of these four are authoring-time bugs. They are integration-time and concurrency-time bugs, and they only exist once the system runs with more than one worker against a live provider. An in-editor reviewer watching the code get written has no vantage point on any of them. That is not a criticism of in-editor review. It is a description of where the two layers sit.
When Cursor Bugbot is the better buy
If you only get one, here's when it should be Bugbot.
You want one bill and one surface, not another vendor.
If your gate is holding, tightening the authoring loop is the higher-leverage move.
Nothing beats catching it before a PR exists at all.
For a library or SDK there's no flow for Ito to drive.
Why most teams end up with both
These aren't substitutes, and the pricing doesn't force the choice that two seat-priced review bots would. Bugbot tightens the loop where code gets written. Ito holds the line where code gets merged. If you're shipping agent-written PRs daily with only one of the two, the missing one is costing you more than the one you have is saving.
Frequently asked questions
No. You connect a GitHub repository and it works regardless of which editor or agent wrote the code. Cursor, Claude Code, Copilot, or a person.
They overlap on intent, not method. Bugbot does static review, mostly inside Cursor. Your app gets built and run at the pull request. Plenty of teams use both.
No. Bugbot analyzes code statically. It doesn't build or execute your product, so runtime failures sit outside what it can see.
They catch different failures in it. Bugbot is strong on logic errors visible in the source. Ito is strong on the signature failure of agent code: confidently written, structurally sound, and wrong about something it couldn't verify without running.
Cursor Bugbot pricing is structured as an add-on to a Cursor subscription, so your cost depends on your existing Cursor plan and seat count. Ito is $40 per seat per month with unlimited repos and does not require any other tool. Check both vendors for current pricing.
Cursor Bugbot is Cursor's code review feature. It reviews the code your agent just generated, flags logic errors and edge cases inline, and also comments on pull requests. It performs static analysis, so it reads code without executing it.
If you want review that works regardless of editor, CodeRabbit or Greptile cover static review across teams not standardized on Cursor. If you want the layer Bugbot cannot reach, Ito builds and runs your app at the pull request and catches failures that never appear in source.
Your first PR tested within 60 minutes.
Connect your repo and Ito starts testing pull requests right away. Each PR includes a full QA report with video, screenshots, and failure details directly in the PR.
no credit card required