How BugViper reviews pull requests

BugViper’s AI agent queries your knowledge graph for context, then posts inline GitHub comments pinpointing bugs, security issues, and code quality problems.

When you ask BugViper to review a pull request, a three-node AI agent runs against your indexed codebase. The agent doesn’t just read the diff — it actively explores the knowledge graph to understand callers, class hierarchies, complexity scores, and blast radius before generating findings. Issues that pass a confidence threshold of 7/10 or higher are posted as inline diff comments pinned to the exact line where the problem occurs.

BugViper only reviews repositories that have been indexed. Index your repository before requesting a review.

Triggering a review

Post a comment on any GitHub pull request with one of these commands:

Command	What it does
@bugviper review	Reviews only the files changed in this PR (incremental)
@bugviper full review	Reviews every file in the repository

Incremental review is the default and recommended mode for ongoing development. It focuses the agent on the changes you’ve made and keeps costs low. Full review is useful when you want a comprehensive audit of the entire codebase, such as before a major release or after onboarding a new repository.

What the agent does

The review pipeline runs a three-node LangGraph graph for each file under review: Explorer → Reviewer → Summarizer.

1. Explorer — investigating the codebase

   The Explorer node runs a ReAct loop, iteratively calling tools against the Neo4j knowledge graph to build context about the code being reviewed. It has access to 19 tools that cover the full range of graph queries:

   • Tracing call chains and callers upstream
   • Fetching class hierarchies and inheritance trees
   • Calculating cyclomatic complexity for functions in the diff
   • Estimating blast radius (how many callers would break if a function changes)
   • Searching for related functions, variables, modules, and file content
   • Retrieving full file source and language statistics

   The Explorer runs for up to a configured number of tool rounds (default: 8), accumulating evidence in its message history before passing control to the Reviewer.

2. Reviewer — generating structured findings

   The Reviewer node reads the Explorer’s full message history and the file context, then makes a single structured LLM call to produce a list of issues and positive findings. Each issue includes:

   • Title and description of the problem
   • Severity: Low, Medium, or High
   • Confidence score: 1–10
   • Suggested fix with a code snippet you can apply directly
   • Exact line numbers in the diff

   Only issues with a confidence score of 7/10 or higher are included in the final output posted to GitHub.

3. Summarizer — generating the walkthrough

   The Summarizer node produces a one-line narrative summary of what changed in each file. These summaries are collected into the walkthrough table that appears in the top-level PR comment.

What you see on GitHub

After the agent finishes, BugViper posts two types of comments to your pull request:

Top-level summary comment — posted once per review run, containing:

• The model used and the total number of actionable comments
• A walkthrough table listing every reviewed file and a one-line summary of what changed
• An Impact Analysis section describing the broader effect of the changes
• A Positive Findings section highlighting good patterns found in the diff

Inline diff comments — one comment per issue, posted directly on the line in the diff where the problem was found. Each inline comment includes the severity, confidence score, a description of the problem, and a suggested fix with a code block you can commit directly from GitHub.

Example: inline security comment

The agent might flag an issue like this on a specific line:

Severity: Medium — Confidence: 8/10

LLM error details (rate limits, model names, API keys) are exposed to the user via str(e)[:100]. Log the error server-side and return a clean fallback message to prevent accidental information disclosure.

The confidence filter

BugViper applies a hard filter: only issues scored 7/10 or higher in confidence are posted to GitHub. Issues below this threshold are discarded. This means every comment you receive reflects something the agent is reasonably certain is a real problem — not a guess.

If a review run produces zero comments, it means the agent found issues but none cleared the 7/10 confidence threshold, or no meaningful problems were detected. This is a good sign.

Cost

A typical review costs approximately $0.12 per file when using claude-sonnet. The total cost scales with the number of files reviewed and the number of tool rounds the Explorer uses. Use the incremental @bugviper review command (not full review) for routine PR feedback to keep costs manageable.

Running @bugviper full review on a large repository with hundreds of files will cost significantly more than an incremental review. Reserve full reviews for audits and pre-release checks.