AI code reviews for vibe coders

The agent that wrote the feature also wrote the test. A passing test can still leave a real bug on the pull request.

Vibe coding is how a lot of first versions get built. You describe the screen in Cursor or Claude Code, the agent writes the branch, the tests it added go green, and the chat says the work is done. You are the person who will merge that branch.

The chat summarizes what the agent meant to build. The pull request is what it built. The test is a third text from the same session, and it checks the path the agent remembered. You can ship a product when an agent wrote the handler. You still own what goes live. The review has to sit on the pull request.

ThinkReview MCP is that reviewer inside the editor you already have open. The server is the connection. A skill makes the agent call it, fix the breaks that would reach a user, and leave the rest alone.

The tests passed. Two high bugs were still real.

This run is from Cursor, on pull request 96. The draft tests had already passed, including the remix-note cases. The local page still loaded. The session was signed out, so a live remix never ran in the browser. On the evidence of its own tests, the branch looked finished.

/thinkreview-pr sent the pull request URL to ThinkReview. Two high findings were real. The fixes went onto the same branch. The pass took about eleven minutes.

A Cursor session running /thinkreview-pr on pull request 96. The draft tests had passed. ThinkReview still found two high bugs, and those fixes landed on the branch.

A remix was marked saved only when generateCampaign returned remixApplied. The request had also been sending regenerate, so an older function rewrote the draft and dropped the note. After the fix, that older function leaves the draft alone. A click guard could drop a field edit, so a normal edit failed to save. Removing the guard made those edits save again.

ThinkReview also raised a secondary-language finding that was wrong. The page already sends the fields for the language you are viewing. A second review raised more items marked critical or high. They described paths that already throw before a write, the intended “remix did not run” message, or a nit about a 40-key loop. The skill left those alone.

That split is what a vibe coder needs. The bugs that would show up for a user get fixed. Findings the code already handles stay as notes. The setup for Cursor and Claude Code is in How ThinkReview integrates into Cursor and Claude.

Why this is the review a vibe coder actually needs

The demo click works on the path you tried. The test covers the note the agent thought about. An older function, or a click that should save, can stay broken. The first person who finds it is a user, after the branch is live.

Vibe coding makes the author an agent. The last reader is often a founder who will hand the finding straight back as the next instruction. The review has to be about the diff on the host, in language plain enough to act on.

ThinkReview reviews pull requests and merge requests on GitHub, GitLab, Azure DevOps, and Bitbucket. Your assistant calls review_url_code with the live URL. ThinkReview fetches the diff through the git credentials stored in the portal. You get the structured review the extension already returns: summary, severity, security notes, and a reason. Your custom rules apply. A cached review of an unchanged diff spends no extra credit.

You can ask in one sentence. The skill is what turns that sentence into a review_url_code call on the real pull request.

Add the MCP, then add the skill

The MCP server is the tool. The skill is the instruction that makes the agent use it. Connect the server, then add the skill, or the model will summarize the chat and call that summary a review.

Cursor. Install ThinkReview from the Cursor Directory. The plugin adds the thinkreview MCP server at https://mcp.thinkreview.dev/v1 and a review-pull-request skill. Enable the server, click Authenticate, and finish consent in the browser. Git credentials for the host still belong under Settings → Integrations.

The Directory skill reviews a URL when you ask. The loop in the screenshot is /thinkreview-pr. Add SKILL.md at .cursor/skills/thinkreview-pr/ in the project, or ~/.cursor/skills/thinkreview-pr/ for every project. The folder name is the command.

Claude Code. Add the same server, then put that same file in .claude/skills/thinkreview-pr/ or ~/.claude/skills/thinkreview-pr/:

claude mcp add --transport http thinkreview https://mcp.thinkreview.dev/v1

Run /mcp and authenticate in the browser. The skill should tell the agent to do six things:

1. Resolve the pull request URL. If the branch has none, push this chat's work and open one.
2. Call review_url_code with that URL.
3. Fix critical and high findings that are real defects in this change. Leave nits and findings the code already handles.
4. Run the tests that cover the edit.
5. Push the fixes to the same pull request.
6. Call review_url_code again with forceRegenerate: true, and stop when the real high issues are gone.

A copy-paste SKILL.md and the client configs are in the integration post and on the MCP setup page.

Merge after the review

The agent can write the product. The pull request is how you stay responsible for it.

• Keep the work on a branch and open the pull request, so the change has a URL
• Add ThinkReview MCP, then add the /thinkreview-pr skill beside it
• Run the skill before you call the branch done
• Merge after the real high findings are fixed and the second review has been read

Connect git integrations, add the MCP server, and put the next feature through a pull request before it is live. If you already review from the browser, MCP is the same engine in the chat that wrote the code.

• Chrome
• Firefox
• Edge

Vibe coding got you to a branch. The review is what makes the branch safe to merge. Start with the MCP integration guide, or see how the same loop runs in Cursor and Claude.