LLM spam in PR reviews comes from two places: people who paste model output without reading it, and AI reviewers set up to comment on everything. For people, the fix is a written team rule. LLVM's policy says "Contributors must read and review all LLM-generated code or text before they ask other project members to review it.", and it lists "Comments and feedback on pull requests" among the contributions it covers. For bots, AI code review vendors document their own levers against noise: run only when someone asks, raise the bar, skip paths and kinds of comments, write team rules into the repository, and let the reviewer learn from comments the team rejects. Then count what share of each reviewer's comments the team accepts; several vendors already show that share.
Every vendor and project fact below comes from that vendor's or project's own pages as I read them on 5 November 2026, and none of them saw this text before publication.
When a teammate pastes model output into a review
Write the rule down where reviewers see it, and answer a pasted list with a link to that rule instead of a reply to every point. The question behind this article describes the case exactly: a colleague posted, as a review comment on a pull request, an eleven-point list that a model wrote and the colleague had not read. Answering such a list point by point takes the reviewer longer than pasting it took, and LLVM's policy is written against that imbalance.
LLVM's AI Tool Use Policy fits the whole rule into a few sentences. Tools are allowed, but a person reads the output first and owns it: "The contributor is always the author and is fully accountable for their contributions." Tool use is to be noted where authorship is normally shown: "Contributors should note tool usage in their pull request description, commit message, or wherever authorship is normally indicated for the work." Review bots fall under the same rule: "Similarly, automated review tools that publish comments without human review are not allowed." The next sentence leaves room for a reviewer that a person drives: "However, an opt-in review tool that keeps a human in the loop is acceptable under this policy." Under all of it sits one test: "Our golden rule is that a contribution should be worth more to the project than the time it takes to review it." For a contribution that breaks the policy, maintainers get a standard reply to paste, which asks the author to justify why the change is worth the project's review time.
Ghostty's AI policy calls its own rules strict. It says "All AI usage in any form must be disclosed.", and for issues and discussions it asks for exactly the trimming that the list in the question skipped: "AI is very good at being overly verbose and including noise that distracts from the main point." and "Humans must do their research and trim this down." Its scope is stated plainly: "These rules apply only to outside contributions to Ghostty."
When a pasted list has already landed, GitHub lets a team fold it away. Organization moderators and anyone with write access to a repository can hide a comment, and GitHub's moderation page names the cases: "If a comment is off-topic, outdated, or resolved, you may want to hide a comment to keep a discussion focused or make a pull request easier to navigate and review." A hidden comment stays available to readers of the repository: "Hidden comments are minimized but people with read access to the repository can expand them."
A team can take the shape of these rules without adopting any of them whole: whoever posts model output has read it, answers for every point in it, and says that a tool wrote it. Such a rule works when it sits where authors and reviewers already look, in CONTRIBUTING or in the pull request template, so that the answer to the next unread list is a single link.
Levers AI reviewers document against noise
Bots are the other half of LLM spam, and here the vendors document the controls themselves. A vendor appears in a row where its own pages, read for this text, describe that lever; a vendor missing from a row is not a claim that it lacks the lever.
| Lever | What it changes | Who documents it, on their own pages |
|---|---|---|
| Run it only when someone asks | no review on pushes nobody asked about | GitHub Copilot: "By default, Copilot only reviews a pull request if you assign it to the pull request." and "However, you can configure automatic reviews."; Greptile: autoReview as an empty list, "To disable automatic reviews entirely"; CodeRabbit: reviews.auto_review.enabled set to false, with a review started by a label or by a "Keyword in the PR description that triggers a review when automatic reviews are disabled."; Codex in GitHub: a review on an @codex review comment, with automatic review as a toggle and a Review trigger for when it runs |
| Raise the bar | fewer comments, and the ones left rank higher | CodeRabbit: profiles quiet, chill (the default) and assertive, where quiet "Posts only the most important comments inline and groups the other review comments in the review summary."; Greptile: strictness on a 1-3 scale, where 3 "Shows only the most critical issues (high threshold)."; Sourcery: a review profile that "sets how many comments a review posts."; Qodo: the Precision preset, "Only display comments worth acting on."; Codex in GitHub: it "flags only P0 and P1 issues" |
| Drop a kind or a severity | takes out a whole class of comments | Greptile: commentTypes, with logic, syntax and style as the types; Claude Code Review: REVIEW.md, "Use it to say what your team wants flagged, at what severity, and what to skip."; Devin Review: "By default, bugs and security findings are posted as PR comments.", "Investigate and informational flags are not posted by default.", and "Admins can toggle each finding type independently."; Graphite: comment exclusions, situations written in plain language where Graphite Agent should not comment |
| Skip paths | no comments on generated, vendored or lock files | CodeRabbit: path_filters, "Specify file patterns to include or exclude in a review using glob patterns"; Greptile: ignorePatterns, for files that do not need review, "to speed up analysis and reduce noise"; Claude Code Review: in REVIEW.md, "list paths and finding categories where Claude should skip findings."; Macroscope: .macroscope/ignore.md "at the repository root, with one glob pattern per line."; GitHub Copilot skips some file types on its own: "If you include these file types in a pull request, Copilot code review will not review the file." |
| Write team rules into the repository | the reviewer checks your rules, not generic ones | GitHub Copilot: .github/copilot-instructions.md and path-specific instruction files with applyTo, where you "Use glob syntax to specify what files or directories the instructions apply to.", and "Custom instructions are enabled for Copilot code review by default"; Codex: a ## Code Review Rules section in AGENTS.md, with the advice "Start with two or three concise rules that encode checks reviewers often explain." and "Keep formatting, lint, and other deterministic checks out of review rules."; Cursor Bugbot: project rule files .cursor/BUGBOT.md, and team rules: "Team admins can create rules in Bugbot Automations that apply to all repositories in the team." |
| Let it learn from what you reject | repeats less of what the team ignores or turns down | Greptile: "Greptile learns to eliminate nitpicky comments that distract developers from critical issues by analyzing which suggestions your team actually acts on.", and "Reactions are the fastest way to train Greptile."; CodeRabbit: learnings, "it learns your team's code-review preferences based on chat interactions"; Cursor Bugbot: learned rules, "Rules are generated automatically from your team's activity on GitHub for that repository or by manually backfilling from the history of the repository."; cubic: "cubic uses relevant learnings to find issues and avoid repeating known false positives."; CodeAnt AI: a reply that dismisses a suggestion is saved as "a customized review instruction that prevents similar suggestions in future reviews." |
| Deduplicate and check before posting | one finding once, the most severe first | Claude Code Review: "A verification step checks findings against the code before they're reported.", then "the findings that remain are deduplicated and ranked by severity."; cubic, on later pushes: "Only new issues are posted as comments; previously flagged issues are not repeated" |
Each row says the vendor documents the setting, as read on 5 November 2026; it does not say how well it works on your code.
Sigma (Mnemoverse, the author's company), a GitHub pull request reviewer, documents three of these levers on its own pages. Its docs say "On request starts reviews only when asked; Automatic can also start them after PR events.", and that P3 findings, "an optional improvement", are "not published inline by default", with at most five verified findings going inline and suspicions no verifier confirmed folded apart as "leads no verifier confirmed, not findings". Sigma runs on Claude Code and OpenAI models.
What each lever costs
Every lever trades some noise for some risk, and the vendors name the trade on the same pages. A higher bar and a wide exclusion can hide what matters. Greptile's checklist for missing important issues starts with "Is strictness too high? Try reducing by 1", and Graphite warns: "If an exclusion is written too broadly, then Graphite Agent may not leave valid comments."
Path filters and repository rules hold only under conditions. Greptile's ignorePatterns "will only ignore those files during PR review.", and Greptile still indexes those files. Claude Code Review applies path exclusions, lowered severities and nit caps from REVIEW.md "When a review reads the copy on a protected default branch", and it reads that file from the base or default branch, "never from the pull request's own changes." Macroscope keeps ignored paths out even on a manual request: "Manual review requests do not override ignores."
A profile or a preset reaches only part of the output. Sourcery says "The profile changes only the inline comments.", and Qodo says "Findings already published on open pull requests are not affected by a preset switch."
Learning takes time and the right kind of feedback, and at Cursor it counts toward Bugbot usage. Among the steps for a team that still sees too many comments at the highest strictness, Greptile lists "Give the learning system 2-3 weeks to adapt to your reactions". cubic says it learns from what is addressed to it ("cubic only learns from feedback directly addressed to it in comments"), and that short replies such as thanks or done "do not become learnings." Cursor says Bugbot learns from a pull request once it is merged or closed, and "each learning run counts toward Bugbot usage like a review."
GitHub Copilot handles feedback differently. Where repository settings and policies allow it, Copilot code review draws on Copilot Memory: "Copilot can store useful details it has learned about a repository and use them when reviewing pull requests." Ratings on its comments go to GitHub instead, whose page says "We use this information to improve the product and the quality of Copilot's suggestions.", and on a second review Copilot "may repeat the same comments again, even if they have been dismissed".
How to tell whether the noise went down
Count, for each reviewer, how many of its comments the team acted on, before and after one change. Several vendors already put that count on a dashboard. Cursor's rule analytics for Bugbot show, for each rule, "Number of findings your team accepted." and "Percentage of findings that were accepted." Qodo counts a finding as accepted when it "resulted in an accepted code change", and reports "The percentage of findings that were accepted." Greptile shows an addressed rate, "The percentage of Greptile comments on closed or merged pull requests that were addressed", and its advice for a low rate begins "Your rules may be too noisy." Graphite's dashboard shows "Percentage of suggestions that were accepted over time" next to a downvote rate.
Each vendor defines acceptance its own way, so compare a reviewer with itself over time, not one vendor's rate with another's. Without a dashboard the same count fits in a spreadsheet: for two weeks, mark each comment from each reviewer as acted on or not, change one thing, such as the bar, a path filter or the trigger, and count for two more weeks. If the share of comments the team acts on goes up while the number it acts on holds, the change took out noise and kept the signal.
Sources
Sources and method: every page below was read on 5 November 2026, each quotation was matched word for word against its page that day, and this text describes the pages as of that date. Related on this account: Why does Codex keep finding new issues every time it reviews its own code?, on review loops and when to stop them, and a comparison of how AI code reviewers describe noise.
Projects and GitHub: LLVM AI Tool Use Policy, Ghostty AI policy, managing disruptive comments
GitHub Copilot: code review, using code review, repository instructions
CodeRabbit: configuration, learnings
Greptile: controlling nitpickiness, training the learning system, reducing nitpicks, analytics
Cursor: Bugbot
Anthropic: Code Review, customizing Code Review
OpenAI: Codex code review in GitHub
Qodo: review presets, code review analytics
Sourcery: review settings
Devin: Devin Review
Graphite: customization, review comments
cubic: memory and learning, review settings
CodeAnt AI: learnings
Macroscope: ignore files
Sigma: docs, reading a review
