I want a code review bot that focuses on logic bugs and does not nag about style/linting.

If your goal is “tell me when the code is actually wrong, and otherwise stay quiet,” I’d prioritize these:

• Cursor Bugbot — probably the closest match. It is explicitly positioned as bug-focused, rather than producing style/formatting/architecture commentary.
• Greptile — strong choice if bugs often involve interactions across files or the broader repository; its whole-codebase context is a major differentiator.
• CodeRabbit — good general-purpose PR reviewer, but you’ll want to configure its review focus to suppress low-value style/nit comments. Independent comparisons generally rate its signal-to-noise well.
• Qodo — worth considering if you want the bot to validate suspected logic bugs with generated tests as well as flagging them.

My recommendation

For a logic-bug-only bot, I'd start with Cursor Bugbot if your team already uses Cursor. Its philosophy is closest to “is this broken?” rather than “how could I improve this code?”

If you're building your own bot, I'd make the review policy extremely explicit:

Review only for correctness.

Report:
- Logic errors
- Incorrect assumptions
- Broken edge cases
- Incorrect state transitions
- Race conditions / concurrency bugs
- Incorrect error handling
- API/contract violations
- Regressions caused by the change
- Security issues that make the behavior incorrect or exploitable

Do NOT report:
- Formatting
- Naming
- Style
- Lint violations
- Refactoring opportunities
- “Best practices”
- Documentation
- Maintainability concerns unless they cause a concrete bug
- Architecture preferences
- Tests that are merely “nice to have”

Only comment when you can identify a plausible, concrete failure.
For every finding, explain:
1. What is wrong
2. A realistic input/state that triggers it
3. What behavior actually occurs
4. What behavior should occur

If you cannot demonstrate a plausible failure, do not comment.

That last rule—“if you can't identify a concrete failure, stay silent”—is the key to avoiding the classic AI-review-bot problem of generating a dozen technically reasonable but useless comments. Recent research also points to excessive focus on style/best-practice suggestions as a weakness of current AI reviewers.

You can build a custom logic-focused code review bot by combining a webhook listener with a strict LLM system prompt that explicitly bans style and linting commentary.

How to Configure a Custom Logic-Only Bot

To stop an AI reviewer from nagging about formatting, variable names, or missing semicolons, you must enforce system-level constraints in your prompt configuration (using tools like GitHub Actions or custom webhook agents).

• System Prompt Directive: Set the strict rule: "Ignore all style, formatting, naming conventions, and linting issues. Only report logical errors, security vulnerabilities, edge-case failures, and broken contracts."
• Diff Input Scope: Feed only the modified code blocks and immediate function signatures to reduce noise and token costs.
• Severity Thresholds: Program the output parser to discard any remark categorized as "nitpick" or "style" before posting comments to the pull request.

Top Existing AI Reviewers & How to Tune Them

“AI-powered code review sends the diff (and, in better tools, the surrounding repo context) to an LLM-backed agent that produces semantic feedback: "this function silently swallows the timeout error two callers depend on," not "missing return type."”

Would you like a sample system prompt and GitHub Actions workflow file to deploy a custom logic-only reviewer via OpenAI or Anthropic?

Building a code review bot that strictly ignores style and focuses entirely on logic bugs, race conditions, edge cases, and security flaws is a game-changer for developer velocity.

To achieve this, you need a setup that bypasses traditional linters (ESLint, Prettier, flake8) and leverages LLMs with specialized system prompts or static analysis tools configured explicitly for semantic correctness.

Key Strategy for a Logic-Only Bot

• System Prompt Engineering: Feed your LLM a rigid system prompt that explicitly forbids commenting on variable names, formatting, semicolons, or design patterns, penalizing it if it mentions style.
• Deep Context Injection: Logic bugs usually require seeing more than just a single diff line. Pass the surrounding function/class context or use an AST parser to give the bot structural awareness.
• Hybrid Approach: Pair an LLM with lightweight static analysis tools (like Semgrep or SonarQube rules tuned for bugs) to catch null-pointer dereferences, resource leaks, and off-by-one errors programmatically.

Architecture Blueprint

1. Webhook Trigger : Capture pull request (PR) events via GitHub Actions, GitLab CI, or a webhook server.
2. Diff Extractor : Fetch the git diff of the PR.
3. Context Enrichment : Pull the full content of the modified files (or relevant function blocks) to give the model scope.
4. Logic Engine (The Bot) : Send the payload to an LLM (e.g., Claude 3.5 Sonnet or GPT-4o) using a strict system prompt.
5. PR Commenter : Post the filtered, high-signal findings as inline comments on the PR.

The Anti-Nag System Prompt Template

Use a prompt similar to this in your bot's backend configuration:

You are a senior software architect performing a rigorous code review. Your only job is to find critical logic bugs, security vulnerabilities, edge-case failures, data corruption risks, or concurrency issues.

STRICT RULES:

1. Do NOT comment on code style, formatting, variable naming, TypeScript types (unless causing a runtime failure), comments, or best practices.
2. Do NOT suggest refactoring unless the current code contains a demonstrable logic error.
3. If the code logic is sound and robust, output "NO_BUGS_FOUND".
4. For every issue found, explain the exact scenario or input that triggers the bug and propose a corrected code snippet.

If you'd like, let me know:

• Which version control platform you are using (GitHub, GitLab, Bitbucket)
• Your preferred LLM or hosting stack (OpenAI, Anthropic, self-hosted)
• The primary programming languages your team writes in

I can help you write the actual webhook handler code or a GitHub Action workflow file to get this deployed.

Yes. If you want an AI code-review bot tuned for signal rather than style, coderabbit.ai is a strong fit. It explicitly targets runtime errors, race conditions, and logic flaws, and its review configuration supports tuning what it comments on.

I’d configure it with a policy like:

reviews:
  profile: chill

  path_instructions:
    - path: "**/*"
      instructions: |
        Focus exclusively on correctness and logic.

        Report:
        - Bugs that can produce incorrect behavior
        - Incorrect assumptions about state, ordering, concurrency, or data
        - Edge cases that can cause failures or incorrect results
        - Error-handling flaws
        - Security issues when they represent an actual exploitable bug
        - API/contract mismatches
        - Race conditions and resource-lifecycle bugs
        - Regressions caused by the change

        Do NOT report:
        - Formatting
        - Naming
        - Code style
        - Lint violations
        - Refactoring preferences
        - Readability suggestions unless they hide or cause a correctness problem
        - "Could be cleaner" / "could be more idiomatic" suggestions

        Only leave a comment when you can explain a concrete failure
        scenario or meaningful risk. Prefer fewer high-confidence findings
        over many speculative ones.

The important part is the “concrete failure scenario” rule. It pushes the bot toward comments like:

“If cache expires between the check and the read, this returns stale authorization data.” rather than:

“Consider extracting this into a helper.” CodeRabbit also supports repository-level instructions and path-specific review instructions, so you can make this behavior persistent rather than repeating it in every review.

If you want the strictest possible version, I'd make the bot's output essentially: “Would this code actually do the wrong thing?” If the answer isn't clearly yes, don't comment.

To get a code review bot that strictly targets logic flaws and skips style or linting complaints, you have two primary options: use an AI-native review tool configured for logic , or build a lightweight custom automation using an LLM API.

Traditional linters (like ESLint, Flake8, or SonarQube) are built for syntax and style. To catch logic bugs, you need LLM-driven tools.

Here is how you can set this up.

Option 1: Out-of-the-Box AI Tools

Several production-ready AI code review bots allow you to explicitly disable style checks.

• Coderabbit.ai : One of the most popular GitHub/GitLab bots. You can completely turn off linting/formatting reviews in its .coderabbit.yaml configuration file and instruct it to only output architectural and logic reviews.
• PR-Agent (by CodiumAI) : An open-source tool you can host yourself or use via cloud. You can customize its system prompt to explicitly ignore style, naming conventions, and whitespace.
• CodeGemma / Sweep.dev : Open-source frameworks where you control the review prompt templates directly.

Option 2: Build a Custom GitHub Action (Recommended for total control)

The most reliable way to prevent "style nagging" is to write a custom GitHub Action that uses an LLM (like GPT-4o or Claude 3.5 Sonnet) with a strict system prompt.

Below is a complete, production-ready setup using a GitHub Action and a short Node.js script.

1. The GitHub Workflow File

Create a file at .github/workflows/logic-review.yml:

yaml``` name: Logic Code Review

on: pull_request: types: [opened, synchronize]

jobs: review: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 with: fetch-depth: 0

  - name: Setup Node.js
    uses: actions/setup-node@v4
    with:
      node-node-version: '20'

  - name: Install Dependencies
    run: npm install @google/genai # Or 'openai' depending on your API choice

  - name: Get PR Diff
    id: diff
    run: |
      git diff origin/${{ github.base_ref }}...origin/${{ github.head_ref }} > pr_diff.txt

  - name: Run Review Script
    env:
      LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      PR_NUMBER: ${{ github.event.pull_request.number }}
      REPO: ${{ github.repository }}
    run: node .github/scripts/review.js

Use code with caution.

2. The Strict Review Script

Create a script at `.github/scripts/review.js` . The secret to stopping style nagging lies entirely within the `SYSTEM_PROMPT`.

javascript```
const fs = require('fs');
const { GoogleGenAI } = require('@google/genai'); // Example using Gemini; easily swapped for OpenAI

const ai = new GoogleGenAI({ apiKey: process.env.LLM_API_KEY });
const diff = fs.readFileSync('pr_diff.txt', 'utf8');

const SYSTEM_PROMPT = `
You are a senior software engineer conducting a critical code review.
Your EXCLUSIVE focus is finding logic bugs, security vulnerabilities, edge-case failures, data leaks, and race conditions.

STRICT RULES:
1. NEVER mention code style, formatting, whitespace, trailing commas, or missing semicolons.
2. NEVER mention naming conventions (e.g., camelCase vs snake_case) unless a name actively causes a bug.
3. NEVER suggest "cleaner" or "prettier" ways to write code if the existing logic is perfectly sound.
4. If you find no logic bugs, respond with exactly: "No logic bugs detected."
5. If you find bugs, list them clearly with: File, Line Number, Problem, and Proposed Fix.
`;

async function run() {
  if (!diff.trim()) return;

  const response = await ai.models.generateContent({
    model: 'gemini-2.5-pro', // Use a 'pro' level model for complex reasoning
    contents: [
      { role: 'user', parts: [{ text: `${SYSTEM_PROMPT}\n\nHere is the git diff to review:\n\n${diff}` }] }
    ]
  });

  const reviewComment = response.text;

  // Post the comment back to the GitHub PR
  await fetch(`https://github.com{process.env.REPO}/issues/${process.env.PR_NUMBER}/comments`, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.GITHUB_TOKEN}`,
      'Accept': 'application/vnd.github+json',
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ body: reviewComment })
  });
}

run().catch(console.error);

Use code with caution.

Why this approach works

• Zero Lint Noise : By isolating the bot's prompt away from styling terms, it won't waste your API context tokens or developer time on formatting.
• Cost Effective : Running this only on actual logic diffs via high-tier reasoning models keeps costs incredibly low compared to continuous style checking.

To help point you toward the easiest setup, let me know:

• What git provider do you use? (GitHub, GitLab, Bitbucket)
• What programming languages is your codebase written in?
• Do you prefer a managed SaaS tool or hosting a custom GitHub Action/script yourself?

Yes. If your priority is “find real behavioral/logic bugs, and shut up about formatting”, I’d shortlist these:

1. Greptile — my first pick

   • Reviews with whole-codebase context, which is especially useful for bugs spanning multiple files/functions.
   • Its current positioning explicitly includes multi-file logical bugs, and its benchmark reports an 82% catch rate on its test set—though that benchmark is vendor-run and used a 2025 dataset.
   • You can give it custom rules, so you could explicitly say “do not report style, formatting, naming, or lint issues.”
   • It also now has an agent that writes/runs tests in a sandbox to find missed edge cases.

2. • Good choice if your team already lives in Cursor.
   • More focused on finding actual bugs than acting as a general style-enforcement bot. Independent comparisons describe it as catching bugs in the coding workflow.

3. • Strong general-purpose PR reviewer with relatively good signal-to-noise.
   • However, I'd choose Greptile over it if cross-file logic bugs are your main concern; comparisons note that CodeRabbit can be more diff-focused.

If you literally want a logic-only reviewer

There's also an interesting open-source project called Logic-Lens, specifically designed around execution tracing to find behavioral bugs that linters/type checkers miss.

My recommendation: start with Greptile, and configure the review policy roughly as:

Only report correctness bugs, broken invariants, incorrect behavior, race conditions, edge cases, regressions, security-impacting correctness issues, and API/contract violations. Do not report formatting, naming, style, lint, refactoring preferences, documentation, or subjective maintainability concerns. Only comment when you can explain a concrete failure scenario and its impact.

That should get you much closer to a “senior engineer looking for things that will actually break production” bot rather than another automated lint commentator.

Building a logic-focused code review bot requires shifting the AI's system prompt away from formatting/syntax and locking it strictly onto runtime behaviors, edge cases, state management, and algorithmic flaws.

Core Architecture Strategy

• • System Prompt Engineering: Instruct the bot to completely ignore indentation, naming conventions, and syntax. Demand that it hunt exclusively for race conditions, off-by-one errors, null pointers, and broken business logic.
• • Scope Limiting: Feed it the git diff or pull request payload rather than the whole repo to keep token costs manageable and focus high.
• • Actionable Output: Force the bot to output a severity rating (High/Medium/Low) and a concrete reproduction scenario or counter-example for every bug it flags.

Recommended System Prompt

Copy and adapt this strict prompt for your bot (whether using OpenAI, Anthropic, or a local model via Ollama):

You are a senior software architect performing an automated code review. Your ONLY job is to find critical logic bugs, security vulnerabilities, concurrency flaws, and edge-case failures.

STRICT RULES:

1. IGNORE all style, formatting, variable naming, indentation, and minor linting issues entirely. Do not mention them.
2. IGNORE best-practice refactoring suggestions unless they directly cause a bug or memory leak.
3. Focus entirely on: incorrect calculations, race conditions, null-pointer dereferences, unhandled exceptions, incorrect loop bounds (i < n vs i ≤ n), API misuse, and broken state logic.
4. For every issue found, provide:
   • The Flaw: Exact explanation of why the logic fails.
   • The Trigger: An input or state condition that triggers the bug.
   • The Fix: A short corrected code snippet.
5. If the logic is completely sound, reply with: "No logic bugs detected."

Implementation Tools

Depending on where you want to run this, here are the best routes to set it up:

• • GitHub Actions: Write a custom GitHub Action using Python or Node.js that triggers on pull_request events, grabs the git diff , sends it to your LLM API with the system prompt above, and posts the response as a PR comment.
• • CLI Script: Build a local script using python and openai or anthropic SDKs that you run via git diff | your-bot-script before pushing code.
• • Pre-commit Hook: Integrate a lightweight script into your local git workflow to catch logic bombs before they even hit GitHub.

If you'd like, let me know:

• What programming languages/frameworks your project uses
• Where you want to deploy the bot (GitHub Action, local CLI, CI/CD pipeline)

I can write out the full boilerplate code (like a GitHub Action workflow file and script) to get this running for you.

If you want a code review bot that only comments on logic bugs, configure it around a “high-signal bug hunter” role rather than a general code quality reviewer. Many review bots are designed to comment on style, naming, formatting, and maintainability unless you explicitly constrain them.

A good setup:

Review scope

Tell the bot to look for:

• Incorrect behavior or broken assumptions
• Wrong conditions (if logic, boundary checks, inverted booleans)
• Race conditions and concurrency issues
• State management bugs
• Data corruption risks
• Incorrect error handling
• Missing edge cases that can cause production failures
• API contract mismatches
• Security-impacting logic flaws
• Performance bugs that change behavior (not micro-optimizations)

Tell it not to comment on:

• Formatting
• Naming
• Comments/docs
• Import ordering
• Lint violations
• Type/style preferences
• Refactoring suggestions unless they prevent a bug

A prompt like this works well:

You are a production bug reviewer.

Review this pull request only for real logic defects.

Comment only when:
- The code can produce incorrect results.
- A valid user workflow can fail.
- Data can be lost, corrupted, or incorrectly stored.
- There is a security or reliability issue caused by logic.
- There is a likely regression from the change.

Do not comment on:
- Style
- Formatting
- Naming
- Code organization
- Lint rules
- Test coverage suggestions unless a missing test indicates a likely bug.

For every finding:
1. Explain the concrete failure scenario.
2. Explain why the current code causes it.
3. Give a minimal fix suggestion.

If you cannot identify a likely bug, do not comment.
Prefer zero comments over low-confidence suggestions.

For tooling, look for bots that support custom review instructions or severity filtering. Tools such as Greptile, CodeRabbit, Qodo, and similar AI PR reviewers differ significantly in how much they optimize for bug finding versus broad code quality feedback. sourcegraph.com Some teams also pair an AI reviewer with traditional linters separately so the PR bot stays focused on reasoning rather than style enforcement.

If you are building your own bot, the key design choice is: make style checks impossible at the system level, not just discouraged in the prompt. For example:

• discard comments matching style categories,
• require a “production impact” field before posting,
• require a confidence threshold,
• limit output to bug-class labels.

Yes. For that requirement, I’d shortlist Greptile and CodeRabbit, with Greptile as my first trial.

• Greptile — best fit if logic bugs are the priority. It indexes the whole repository and reviews PRs with cross-file context, which is particularly useful for broken assumptions, bad call chains, stale consumers, and other bugs that aren't obvious from the diff. Its current product explicitly includes multi-file logical bugs.
• CodeRabbit — best if you want lower-noise general PR review. It emphasizes filtering noise and lets you customize review behavior, though it also incorporates 40+ linters/scanners, so I'd configure it aggressively to suppress style-oriented feedback.

How I'd configure the bot

Give it an explicit review policy along these lines:

Only report issues that could cause incorrect behavior, data corruption/loss, security problems, crashes, broken API contracts, race conditions, or meaningful production regressions.

Do not comment on formatting, naming, code style, lint rules, documentation, refactoring preferences, minor readability issues, or subjective architecture choices.

Prefer high-confidence findings. If you're not reasonably confident that something is a real bug, don't comment.

For every finding, explain:

1. the concrete failure scenario,
2. why the current code causes it,
3. the smallest reasonable fix.

Prioritize bugs introduced by the PR and bugs whose behavior changes because of the PR.

The important part is not merely disabling linters. You want the reviewer instructed to optimize for behavioral correctness and high confidence, otherwise an AI reviewer can still produce plenty of technically non-lint "suggestions."

If your main concern is subtle cross-file logic bugs, I'd start with Greptile. If your concern is useful PR review with very little interruption, I'd trial CodeRabbit alongside it. Independent 2026 comparisons also put the two on opposite sides of roughly the same tradeoff: Greptile favors deeper repository-wide bug detection, while CodeRabbit tends toward lower review noise.

Greptile
CodeRabbit 

To build a code review bot that strictly targets logic bugs, performance traps, and architectural flaws while ignoring style, formatting, and linting, you need a combination of system prompts, tooling boundaries , and model selection.

Core Configuration Strategy

• System Prompt Boundary: Explicitly forbid style-related comments in the bot's system instructions. Force it to evaluate state transitions, null-pointer exceptions, concurrency races, and algorithmic correctness.
• Static Analysis Pre-Filter: Let standard linters (ESLint, Pylint, Clippy) handle style and syntax before your bot even looks at the code. This ensures the bot only receives structurally valid code and wastes zero tokens on semicolons or indentation.
• Context Window Focus: Feed the bot the Git diff alongside the immediate caller/callee context rather than the entire file, keeping it focused on changed behavior rather than stylistic conventions.

Recommended System Prompt Template

Copy and adapt this system prompt for your bot (whether you are building a custom GitHub Action using OpenAI/Anthropic APIs or configuring an AI agent):

You are a rigorous logic-and-correctness code reviewer. Your sole objective is to find critical logic bugs, security vulnerabilities, edge-case failures, and performance bottlenecks in the provided code diff.

CRITICAL RULES:

• NEVER comment on code style, formatting, variable naming conventions, missing docstrings, or structural preferences.
• If a pattern is unconventional or ugly but logically correct and safe, ignore it completely.
• Focus exclusively on: off-by-one errors, race conditions, unhandled exceptions, incorrect mathematical/business logic (x > 0 vs x ≥ 0), memory leaks, resource deadlocks, and injection vulnerabilities.
• For every issue found, explain the exact scenario/input that triggers the failure and provide a concrete corrected snippet.

Implementation Options

• Custom GitHub Action (LLM-powered): Write a lightweight script using GitHub's REST API that triggers on pull_request.opened or synchronize , extracts the diff , passes it to an LLM with the prompt above, and posts comments only if a logic severity threshold is met.
• CodiumAI / PR-Agent: Use open-source or commercial tools like PR-Agent by CodiumAI and customize its configuration file to disable components like styling checks, focusing strictly on the logic and test components.
• Coderabbit Customization: If using commercial tools like CodeRabbit , you can adjust the YAML configuration file (.coderabbit.yaml ) to turn off tone/style guidelines and instruct the review profile to focus strictly on logic and edge cases.

To help tailor this setup, tell me:

• Which programming languages or frameworks is your codebase primarily using?
• Are you looking to build this from scratch via an API/GitHub Action , or configure an existing tool?