Code review is starting to behave less like a checklist and more like a system.
Cursor's April 8 Bugbot update makes that shift visible. The release adds learned rules, MCP support, and a higher reported resolution rate, which means Bugbot is no longer just scanning diffs and emitting comments. It is now absorbing reviewer feedback, turning repeated signal into rules, and pulling in external context when the team wants it.
That is a meaningful change in the shape of code review.
What Cursor changed
Cursor says Bugbot can now learn from reactions, replies, and human reviewer comments, then convert that feedback into candidate rules that are promoted or disabled over time. Cursor also says Bugbot can use MCP servers for additional context during review.
The practical result is a reviewer with memory and tools.
| Review model | What it sees | How it improves |
|---|---|---|
| Static bot | Only the current diff and built-in heuristics | Mostly offline product updates |
| Learned bot | Diff plus feedback from prior PRs | Learned rules from real reviewer signals |
| Tool-using bot | Diff plus external context from MCP servers | Better context from repo-adjacent systems |
Cursor also says Bugbot's resolution rate is now 78%. That number matters less as a benchmark trophy and more as evidence that the product is now using live feedback as a first-class input.
Why this matters
The old mental model for code review tools was simple. They were expensive linters, maybe with some semantic awareness. They could catch obvious issues, but they did not really learn your team.
Bugbot's learned rules suggest a different model. The bot can observe what reviewers reject, what they explain, and what humans catch that it missed. Over time, that turns review from a stateless pass over a patch into a local policy system.
That is a better fit for real teams because teams do not review code with abstract correctness alone. They review for:
- product constraints
- security expectations
- architectural boundaries
- naming and style conventions
- repository-specific traps that are not obvious from the code alone
A static model can know general best practices. A learned review system can start reflecting the team's actual preferences.
MCP makes the review surface bigger
The other notable change is MCP support.
Once a review bot can query tools, code review stops being limited to the diff in front of it. A bot can potentially inspect adjacent context, fetch policy information, or consult domain-specific data sources before it speaks.
That is useful, but it also raises the bar for control.
| Benefit | Risk |
|---|---|
| Better context on complex PRs | Tool scope can leak more data than intended |
| More precise findings | More moving parts to audit and secure |
| Fewer generic comments | More chances for bad tool configuration to create noisy or unsafe behavior |
The lesson is not that MCP is unsafe. The lesson is that tool access changes the review bot from a comment generator into an operational actor. That deserves the same discipline we apply to any other production integration.
What teams should do with this
If you are using Bugbot or anything similar, the useful response is not "turn it on and hope."
The better response is to treat learned review like a control loop:
- Make reviewer feedback structured enough to train on.
- Audit learned rules the same way you audit policy changes.
- Scope tool access narrowly when attaching MCP servers.
- Watch for rule drift when a repository changes shape.
- Keep humans responsible for final merge decisions on sensitive paths.
That is especially important because the failure mode is subtle. A review bot that gets better at finding issues can also get better at encoding the wrong local norm if the team feeds it inconsistent signals.
The larger trend
Cursor is not alone here. The broader market is moving toward agentic development environments where tools can act, learn, and coordinate instead of just autocomplete.
Bugbot is a useful signal because code review is one of the hardest places to fake usefulness. If a product can keep up there, with real pull requests, real feedback, and real team-specific context, then the product category is no longer just "AI-assisted review."
It is becoming a review layer with memory.
That matters because code review is one of the last places where teams still expect a disciplined human judgment loop. Once that loop becomes machine-assisted, the important question is not whether the bot can comment.
It is whether the bot can absorb the team's policy without becoming a source of policy drift.
Final note
Cursor's Bugbot update is interesting because it is small in surface area and large in implication.
Learned rules make code review adaptive. MCP support makes it contextual. Together, they point to a future where review systems are closer to configurable operators than static analyzers.
That future will be more useful, but it will also require tighter governance. Teams that want the speedup will need to own the feedback loop, the tool boundaries, and the rules those systems learn.