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

Yes. The key is to make correctness the only review contract, rather than asking for a generic “code review.” Current guidance on AI review similarly recommends giving the reviewer repository context and explicitly excluding style/naming/formatting feedback.Cursor+1

A good bot should:

• Review logic/correctness, including edge cases, state transitions, error handling, concurrency/races, broken API contracts, and security-impacting logic.
• Ignore formatting, naming, whitespace, imports, idioms, refactoring preferences, and lint rules.
• Comment only when it can point to a specific changed line and concrete failure scenario.
• Require evidence: what input/state triggers the bug → what the code does → why that produces incorrect behavior.
• Say nothing when it cannot identify a substantive problem.
• Treat findings as advisory rather than automatically blocking a merge; AI review still needs human verification.Robin Review+1

Core reviewer prompt

You are a senior software engineer reviewing a pull request.

Your ONLY job is to find substantive correctness problems in the changed code.

Look for:
- Logic bugs
- Incorrect assumptions about inputs or state
- Broken edge cases
- Incorrect error handling
- Race conditions and concurrency bugs
- Resource leaks
- Incorrect API/contract behavior
- Security vulnerabilities caused by incorrect logic
- Regressions in existing behavior
- Data corruption or incorrect persistence behavior

DO NOT comment on:
- Formatting or whitespace
- Naming
- Code style or idioms
- Lint rules
- Comments/docstrings
- Refactoring opportunities
- Readability unless it directly causes a bug
- "Best practices" that do not correspond to a concrete defect
- Missing tests unless you can identify a specific behavior that is likely broken

IMPORTANT:
- Do not invent requirements that are not supported by the repository.
- Inspect relevant callers, tests, types, and surrounding code when needed.
- Only report a finding if you can explain a concrete failure scenario.
- Prefer one high-confidence bug over several speculative comments.
- If the code is correct, return no findings.

For each finding, provide:

1. Location — file and line
2. Problem — what is wrong
3. Failure scenario — concrete input/state that triggers it
4. Impact — what actually goes wrong
5. Fix — concise description of the required correction
6. Confidence — high / medium

Do not provide a summary of the code.
Do not praise the author.
Do not provide style suggestions.
Do not manufacture findings to make the review look thorough.

For a production bot, I'd also give the model the PR diff plus relevant surrounding code, callers, tests, and project requirements, rather than the diff alone. Research and current practitioner guidance both point to repository context as important for catching bugs that aren't apparent from changed lines in isolation.Cursor+1

If you're building this for GitHub, I can also give you a complete GitHub Action that posts only high-confidence logic-bug comments on PRs.

Yes. The key is to make “logic correctness” the bot’s review contract, rather than trying to configure a general-purpose linter to be quieter.

A good setup would:

• Review behavioral correctness: wrong conditions, state transitions, edge cases, race conditions, incorrect error handling, broken invariants, stale caches, authorization mistakes, etc.
• Reason across the surrounding codebase, not just the diff.
• Comment only when it can explain a concrete failure mode.
• Ignore formatting, naming, documentation, refactoring preferences, and “this could be cleaner” suggestions.
• Prefer high-confidence findings over exhaustive findings.
• Ask: “Can this change cause incorrect behavior?” before producing a comment.
• Include a minimal reproduction/example when possible.
• Suggest a regression test for genuine bugs.

Existing option

coderabbit.ai is probably the closest off-the-shelf fit. It supports configurable review behavior and explicitly lets you teach it repository-specific review preferences; its documentation even gives the example of telling it not to complain about an error-handling pattern that is intentionally handled elsewhere.CodeRabbit+1

qodo.ai is another strong option if you want deeper repository/cross-repository context and more structured control over review rules.Qodo

If you want to build your own

I'd make the bot's system prompt roughly this strict:

You are a logic-focused code review bot.

Your ONLY purpose is to identify bugs and correctness problems introduced
or exposed by the change.

Report issues such as:
- Incorrect behavior
- Broken invariants
- Incorrect state transitions
- Edge cases that produce wrong results
- Null/undefined or boundary-condition bugs
- Race conditions and concurrency bugs
- Incorrect error handling that changes observable behavior
- Authorization/authentication flaws
- Data corruption or consistency problems
- Incorrect API/database/cache interactions
- Performance problems only when they can cause functional failure
- Regressions caused by the change

DO NOT report:
- Formatting
- Naming
- Style
- Lint violations
- Refactoring opportunities
- Code organization preferences
- Documentation
- Minor readability issues
- "Best practices" without a concrete failure mode
- Missing tests unless the missing test corresponds to a specific
  correctness risk

Review the diff in the context of the surrounding repository.

For every finding, provide:
1. Severity
2. The exact failure mode
3. Why the changed code causes it
4. A concrete input/state/sequence that triggers it
5. A concise fix recommendation

If you cannot identify a concrete way the code can behave incorrectly,
DO NOT COMMENT.

Prefer one high-confidence finding over several speculative ones.
Silence is preferable to a low-confidence warning.

The most important line is “If you cannot identify a concrete way the code can behave incorrectly, DO NOT COMMENT.” That prevents the bot from gradually turning into another linting tool.

If you're building this as a GitHub PR bot, I can also sketch the architecture—including diff retrieval, repository-context retrieval, review prompting, severity filtering, and posting only high-confidence comments.

To see how modern AI reviewers handle deep logic vs. superficial noise, watch this breakdown of code review bots tested on backend edge cases:

15:50I tested another 5 code review bots to catch my slop!2.3K views · 5 months agoYouTube · Convex

Building a code review bot that strictly ignores style, formatting, and linting—while aggressively hunting for edge cases, race conditions, null-pointer exceptions, and broken algorithms—requires a specialized system prompt and configuration.

How to Configure an AI Reviewer for Logic-Only Mode

Whether you are using a custom GitHub Action with an LLM API, or tuning an existing tool like Coderabbit or Greptile , you need a tightly scoped system prompt.

A production-ready system prompt for a logic-only code review bot:

You are a senior systems architect and hostile code reviewer. Your ONLY job is to find critical logic bugs, security vulnerabilities, race conditions, unhandled edge cases, and algorithmic flaws in the provided pull request.

CRITICAL CONSTRAINTS:
1. IGNORE formatting, indentation, semicolons, naming conventions, and style entirely.
2. IGNORE traditional linting rules (e.g., unused variables, import orders, max line lengths).
3. Do not offer refactoring suggestions unless the current code introduces a definitive bug or memory leak.
4. If the code logic is sound, output: "NO_LOGIC_ISSUWES_FOUND" and nothing else.
5. Be concise. Structure feedback as: [Severity: High/Medium] -> [File/Line] -> [The Bug] -> [Proposed Fix].

Use code with caution.

Implementing it via GitHub Actions

If you want to spin this up yourself using a lightweight GitHub Action connected to an LLM (like Claude 3.5 Sonnet or GPT-4o), your workflow should feed only the git diff and the immediate dependency context into a prompt explicitly wrapped with the constraints above.

Key architectural choices to keep it noise-free:

• Bypass AST linters in the pipeline: Do not run ESLint, Pylint, or Rubocop in the same step where the AI outputs comments. Keep static linters strictly in CI checks; let the AI review solely the semantic behavior.
• Require reproduction steps or proof: Instruct the bot to only comment if it can explicitly trace an execution path that results in incorrect state, an unhandled exception, or a security breach.

If you'd like, I can help you:

• Write the complete GitHub Action YAML file combined with an LLM script.
• Tailor the system prompt to a specific language or framework (e.g., Python/Django, TypeScript/Node, Go).

Let me know how you plan to deploy or host this bot!

If your priority is “find real logic bugs, and shut up about style/lint”, I’d narrow the field considerably.

Best fits

• Cursor Bugbot — probably the closest match. It is explicitly positioned around bug detection rather than full review/style commentary, so it’s a strong choice if you want high-signal “is this actually broken?” feedback.Dupple+1
• Greptile — better if your bugs often involve cross-file interactions, call chains, or broader repository context. It indexes the codebase rather than looking only at the PR diff.Context Studios
• CodeRabbit — a strong general-purpose reviewer with good bug detection, but I would configure it aggressively to suppress style/quality noise. It has broader review capabilities than you seem to want.Hyrax+1
• Qodo/PR-Agent — worth considering if you want something more customizable or self-hosted, particularly if you want to define exactly what constitutes a review finding.Context Studios+1

What I would build

If you're asking for a custom bot, I'd make its review contract extremely narrow:

Review this PR exclusively for correctness.

Report only issues that can cause:
- incorrect program behavior
- incorrect business logic
- broken edge cases
- incorrect state transitions
- data corruption or loss
- race/concurrency bugs
- incorrect error handling
- security vulnerabilities
- regressions caused by the change

Do NOT report:
- formatting
- naming
- lint violations
- code style
- refactoring opportunities
- documentation
- subjective architecture preferences
- performance unless the change creates a concrete correctness problem

Only comment when you can explain:
1. what is wrong,
2. a concrete input/state that triggers it, and
3. what the code will do incorrectly.

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

That last rule is important: make the bot prove the bug to itself before emitting a comment. It dramatically changes the bot from “AI reviewing everything” into a logic-bug detector.

I'd also have it inspect the whole repository when necessary, not just the diff. Many of the most valuable bugs are things like “this caller assumes the function still returns X, but your change now returns Y.” Whole-codebase context is specifically where tools like Greptile distinguish themselves.Context Studios

If you tell me GitHub vs GitLab, language/stack, and whether you want SaaS or self-hosted, I can recommend the exact setup—or sketch the bot architecture/config for you.

To build or configure a code review bot that strictly targets logic bugs, race conditions, and architectural flaws while completely ignoring formatting, semicolons, and naming conventions, you need a custom system prompt or a tightly constrained agent. Off-the-shelf AI code reviewers tend to default to nitpicking style if you don't aggressively pin them down.

Here is how you can set up a custom logic-only reviewer using a prompt-engineered LLM (via GitHub Actions, a custom webhook, or an agent framework like Vercel AI or LlamaIndex):

The Anti-Style System Prompt

Save this prompt as your core instructions for the bot. It explicitly forbids style commentary and forces the model to ignore superficial code artifacts.

You are a senior systems architect and hostile peer reviewer. Your ONLY job is to find critical logic bugs, security vulnerabilities, edge-case failures, data corruption risks, and concurrency/race conditions in the provided code diff.

STRICT CONSTRAINTS:
1. IGNORE all style, formatting, variable naming, file organization, comments, and linting entirely. Do not mention spacing, trailing commas, or missing docstrings.
2. If the code is ugly or breaks stylistic conventions but the logic is sound, output NOTHING or explicitly state "No logic errors found."
3. Do not suggest refactoring unless the current structure directly causes a functional bug or memory leak.
4. Focus exclusively on:
   - Incorrect conditional branches or off-by-one errors.
   - Unhandled async/await, unhandled exceptions, or missing null/nil checks.
   - Silent data loss, state mutation bugs, or race conditions.
   - Broken business logic constraints or authorization gaps.

Format your response as a bulleted list. For each issue, provide:
- **Severity**: (Critical / Moderate)
- **Failure Mode**: What breaks and under what specific conditions.
- **Suggested Fix**: A precise code snippet fixing the mathematical or logical flaw.

Use code with caution.

Implementation Approaches

1. GitHub Actions + OpenAI/Anthropic API:
   • Set up a lightweight workflow triggered on pull_request events (opened, synchronize).
   • Fetch the git diff using git diff HEAD~1 or via GitHub's API.
   • Send the diff along with the strict system prompt above to an LLM API (like GPT-4o or Claude 3.5 Sonnet).
   • Post the response as a PR comment only if the model identifies a "Critical" or "Moderate" logic flag.
2. Dedicated Tools & Alternatives:
   • Tools like Cursor Bugbot or specialized evaluation setups focus more heavily on deep behavior than standard linters, but you still achieve the cleanest results by injecting a hard system prompt into a customized LLM action.
   • If you are evaluating automated platforms, ensure you turn off standard static analysis tools (ESLint, Prettier, Flake8) from your AI pipeline so the reviewer doesn't inherit their noise.

If you want to implement this, tell me:

• What CI/CD platform are you using (GitHub Actions, GitLab CI, etc.)?
• What programming language(s) does your codebase primarily use?

I can help you write the exact workflow file and hook it up to an API.