When the team works with lots of small PRs, it’s normal for people to start complaining that even when changing a comment, Kody is bringing suggestions. This happens because, by default, she analyzes any open PR, regardless of its size or type of change.
If the goal is to keep reviews lighter and focused only on points that actually bring technical risk, a few simple configuration tweaks can already help reduce the volume of suggestions in these cases.
How to adjust Kody for this kind of workflow
1. Raise the minimum severity level
If you want to reduce the number of suggestions Kody makes per PR, a good option is to raise the minimum severity level.
This makes her only point out issues classified as High or Critical, leaving out more superficial suggestions like style or readability adjustments.
To configure this:
Go to Settings → Global Settings → Suggestion Control and set the Minimum Severity Level field to High.
If you want to be even more restrictive, you can bump it up to Critical.
This helps cut down on suggestions in small PRs and makes Kody focus only on what could actually cause problems (like security issues, critical performance problems, or broken architecture).
2. Limit the maximum number of suggestions per PR
Another way to keep reviews focused is to limit the maximum number of suggestions per PR.
Even if Kody finds several improvement points, she will only comment on the most important ones — prioritizing what really has impact.
You’ll find this setting in Global Settings, in the Max Suggestions per PR field.
A good starting point: limit to 6 suggestions per PR.
This helps avoid cluttering small PRs with too many comments at once.
3. Disable low-impact rules
It’s also worth disabling rules that generate low-impact suggestions and that the team doesn’t consider relevant for small PRs.
Review the list of active rules and identify which ones are bringing this kind of suggestion.
For example: rules related to style, import organization, or naming.
If the team decides it doesn’t make sense to keep these rules active, just disable them directly on the Kody Rules screen.
4. Keep only the most critical rules
If the goal is to make Kody even more selective, the team can choose to keep active only the rules that indicate real technical risk — like security flaws, performance issues, or serious architectural problems.
It’s worth reviewing the rules list and analyzing, one by one, which ones really point to critical problems. Besides disabling what doesn’t make sense, you can also add other important rules that aren’t active yet.
The most relevant categories for this scenario are usually:
✅ Security
✅ Performance
✅ Architecture
No need to make all the changes at once. The team can adjust gradually as they see what really adds value to the reviews.
5. Leverage the rules Kody learns from your team
Besides the library rules, Kody also learns from the team’s review history. Whenever she identifies a recurring fix pattern in PRs, she suggests creating a new custom rule.
These suggestions appear right on the Kody Rules screen.
It’s worth reviewing these suggestions from time to time. Many of them reflect the kind of care the team already applies manually during reviews. Turning these patterns into rules helps automate the process and prevents the same issues from popping up over and over again.
When it makes sense, just add the rule. From that point on, it will start being applied automatically in the next PRs.
