Reviewing Cursor pull requests
Cursor's Agent can rewrite a feature across a dozen files from a single prompt, but the chat that shaped it never leaves the editor. Hervé captures each Cursor session and puts it next to the code: the prompts, the plan, and every place the change drifts from what was asked — on one review surface.
The problem with reviewing agent-written code
When a teammate opens a pull request, you can ask them why. When Cursor opens one, the why lived in a session that is already gone. The reviewer is left reading a large diff with no record of the request, the constraints, or the paths the agent considered and rejected. Volume makes it worse: the faster the agent ships, the further behind the reviewer falls.
Automated review bots don't close that gap — they widen the noise. In a 2026 study of 31,073 CodeRabbit comments across 239 repositories, developers rejected 56.3% of them.[1] A separate study of 278,790 reviews found developers act on an AI reviewer's suggestions 16.6% of the time, against 56.5% for a human's.[2] A bot that guesses intent from the diff produces findings the team learns to ignore.
What Hervé captures from a Cursor session
You install the rv CLI once and enable capture per repository. From then on, every commit carries the Cursor session behind it — the Composer and Agent prompts, the plan, and the multi-file edits it proposed — written to a branch on your own repo, never to our database. On the pull request, Hervé shows:
- The request and the session — the linked issue, the prompts, the plan, the alternatives the agent tried and abandoned.
- A change map — every changed file sized by how much moved and coloured by how much it can break, so you see the shape of the PR before reading a line.
- Criticality — the files that carry the risk, surfaced first, so a reviewer spends attention where it counts.
- Anti-drift — changes that contradict the linked issue get flagged, quoting the exact line they were judged against.
- Ask on the line — tag
@herve-reviewin a thread and the answer cites the issue and the session that wrote the code, not a guess from the diff.
Why the captured session matters
A summary reverse-engineered from the finished diff is not the same as the decisions actually made. It can't show the constraint the agent was given or the approach it rejected. Hervé reviews the change against the real session, so “it changed something it shouldn't have” becomes a flag with a quote instead of a gut feeling three weeks later.
Across a repository, Hervé Insights rolls this up: how much of the work Cursor authored and which files it touches most — so the tech lead can see where the agent is carrying the load.
Common questions
How does Hervé see what Cursor did?
The rv CLI captures each Cursor session — the prompts, the plan, and the decisions behind the change — and writes them to a branch on your own repository. Hervé reads that branch through the GitHub or GitLab API when it renders the pull request. Your code and your transcripts stay on your git; nothing is copied to our servers.
Does this replace my review agent or CI checks?
No. Review agents check the output and guess the intent from the diff. Hervé starts from the real captured session, so it shows the decisions behind the code and flags where the change contradicts the request. Keep your agent and your CI; Hervé is the surface your team reviews on.
Do we have to change how we use Cursor?
No. You install the rv CLI once and enable capture per repository. Your team keeps using Cursor, GitHub or GitLab, and your existing branch protection and merge flow exactly as they are.
What if we use more than one coding agent?
Hervé captures sessions from Claude Code, Cursor, GitHub Copilot CLI, OpenAI Codex, and OpenCode. Every pull request carries the session that produced it, whichever tool wrote the code.
Sources
- Is Agentic Code Review Helpful? Mining Developers' Feedback to CodeRabbit Reviews in the Wild, arXiv:2607.03316.
- Human–AI Synergy in Agentic Code Review, arXiv:2603.15911.