When the team is on a tight deadline, the focus shifts to delivering — fast. But that doesn’t mean quality has to be pushed aside. The key here isn’t to stop reviewing, but to adjust Kody to only act where it really matters.
With the right settings, you can keep the review process running, but in a much leaner way: protecting what could cause real problems and skipping suggestions that aren’t a priority right now.
Below is a step-by-step guide on how to configure Kody to maintain technical quality in the critical parts of the code — without slowing down delivery.
1. Cut the noise with the Minimum Severity Level
To cut down on noise without turning Kody off completely, one of the first settings you can tweak is the Minimum Severity Level, setting it to High or Critical.
This ensures that only suggestions with real technical impact — like security flaws, performance issues, or broken architecture — show up automatically in PRs.
You can apply this adjustment in the global settings or directly in the repository that’s under the tightest delivery pressure.
2. Adjust rules based on the team’s priorities
Besides filtering by severity, it’s worth reviewing the active rules and tweaking anything that doesn’t make sense right now. Low-impact rules — like variable naming or formatting — can be:
Temporarily disabled, if the team prefers to cut out this kind of suggestion entirely
Downgraded to Low, so they stay available but won’t show up automatically in PRs (since they’ll be filtered out by the Minimum Severity setting)
On the flip side, take this moment to reinforce the rules that protect the critical parts of the code. If any Security or Performance rule isn’t already set to Critical, it’s worth updating — that way, Kody keeps flagging serious issues, even in the fastest-moving PRs.
3. Limit the number of suggestions per PR
Even with the settings above, some PRs might still involve a lot of code being reviewed. To avoid overwhelming the team with too many suggestions at once, set a cap on the maximum number of comments per PR.
A good starting point: 6 or at most 10 suggestions per PR.
This helps Kody prioritize the most critical points and leave the less urgent ones out. It gives the team more focus and speed — without sacrificing technical protection.
With these adjustments, the team can keep the review process active even under deadline pressure — focusing only on what could actually compromise technical quality. Kody still acts as a safety net for the most critical parts of the code, without distracting the team with suggestions that can wait. After the delivery, you can just bring the normal rules and severity levels back — no need to reconfigure everything from scratch.
