No fixed number is right, but a budget helps: cap AI comments per pull request at a small figure such as five, show the highest severity first, and retire any rule that developers dismiss most of the time. When comments pile up, people stop reading all of them.
Why volume kills value
Developers read the first few comments with care. By the tenth, they skim. By the twentieth, they hit resolve on everything. A real security finding buried at number 14 gets the same treatment as a style remark at number 2.
Noise also spoils trust in the tool, and in the security team behind it. Once developers conclude that the bot is mostly wrong, they stop looking even when it is right. The cost shows up later, as dismissed true findings.
Set a comment budget
A comment budget is a limit on what the tool may post per pull request. How to set one:
- Measure first. Run the tool in advisory mode for two weeks and log comments per pull request, by type and severity.
- Choose a cap. Look at the distribution. A cap near the point where acceptance falls off is a good start. Five is a common first guess, to be tuned.
- Rank before posting. Severity first, then confidence, then whether the finding is in changed lines. Post the top items inline and list the rest in one summary comment.
- Group duplicates. Ten instances of the same issue are one comment with ten locations.
- Collapse low value remarks, such as style, into a single optional note, or turn them off.
Classify by what a developer should do
Labels cut cognitive load. A scheme like the one in review comment labels: nit, optional, blocking works for bot comments too. For bot output, a simple split is:
| Label | Meaning | Where it appears |
|---|---|---|
| Blocking | Must be fixed or explicitly waived | Inline, top of the list |
| Should fix | Real issue, can be fixed soon | Inline |
| Info | Context, no action needed | Summary comment only |
Only blocking items should ever stop a merge.
Prune by data
Each month, list rules by volume and by dismissal rate. A rule that fires often and is dismissed over 70 percent of the time is a candidate for removal or tuning. That threshold is only a starting point, so adjust it to your own data. Keep a note of what you removed and why, so a rule does not creep back unnoticed.
See how to triage AI review comments for the reader's side of the same problem.
Do not hide real findings to look quiet
A low comment count is not the goal. Capping must not drop high severity items. If a pull request really has eight serious problems, post all eight. The budget applies to the long tail.
Ask the developers
Run a short survey after a month: did the comments help, which were wrong, which would you remove? A five-question survey, like the one in SAST pilot developer survey, gives you direction faster than dashboards.
Quick check
Should the cap be the same for every repository?
Not necessarily. A security-critical service may tolerate more comments than a documentation repo. Start with one cap and adjust by repository.
Can the tool still block on items over the cap?
Yes. The cap limits inline noise, while blocking items should always be shown and enforced.
Safeguard includes policies, gates and guardrails where you decide which severities warn and which block. Try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
