Cap the number of bot comments, move low priority output to summaries and annotations, and watch the ratio of bot to human comments. When bots dominate a thread, reviewers stop reading it, and the human comments that carry design and security judgement get lost with the rest.
The hidden cost of bot volume
Human review is the scarce resource. A reviewer opens a pull request, sees forty comments, and sees that thirty five are from automation. The reflex is to skim all of them. The five human comments, which may include the most important point, get the same skim.
Several bots make it worse: a linter, a coverage reporter, a dependency bot and a security bot each add their own. Each is reasonable alone. Together they bury the conversation.
Measure the ratio
Count, per pull request, bot comments versus human comments, and track the median per team. There is no universal healthy number, but a trend upward is a warning. Also track the share of bot threads that end resolved without any action, since that suggests they were noise.
| Signal | What it suggests |
|---|---|
| Bot to human ratio rising | Too much automation output |
| Many bot threads closed with no change | Low value rules |
| Human comments per pull request falling | Reviewers disengaging |
| Late human comments after approvals | Skimming earlier threads |
Tactics
- One summary per bot. Update a single comment in place and avoid new ones.
- Move detail out of the thread. Use the job summary or check output. GitHub combines step summaries into one page per run, which keeps detail off the conversation.
- Collapse the routine. Use collapsible sections for tables and low severity lists.
- Agree a shared budget. If four bots each get ten comments, that is forty. Set a team wide cap, then split it.
- Silence the green. Do not post when nothing is wrong.
Separate machine feedback from human feedback
Where possible, give machines a different surface: status checks, annotations and summaries. Reserve review threads for human conversation, with exceptions for findings that need a decision. GitHub notes that batching comments in a review reduces notifications, which is another reason to bundle bot output.
Let reviewers filter
Prefer bots that use a clear, consistent account name and, if your platform allows it, filters that let a reviewer hide bot threads. Consistent naming makes this possible, and our post on introducing a security bot to developers covers identity.
Review the whole stack, not one tool
Security teams often tune their own bot and ignore the rest. Ask platform engineering for the full list of automation that comments on pull requests, and agree on one budget and one style. The developer sees one experience, not four.
Safeguard checks can be configured to report through status and summaries instead of threads, which helps keep review pages readable. See the free scan.
Quick check
Is there an ideal ratio of bot to human comments?
No published standard exists. Track your own trend and treat a steady rise as a sign to cut output.
Should security comments get priority over other bots?
Give them a clear place and a cap, but do not exempt them from the shared budget. Priority on severity, not on source.
Sources
Last reviewed: 19 October 2026.
