When a team has never had a clear review process, it’s common for PRs to get merged after just a quick read — with no standard, no technical criteria, and no visibility into what really matters. The idea here is to start light but with real impact.
If you’re using Kody as the starting point to structure this process, you can activate the right settings to bring value from the first sprints — without overwhelming the team with too many suggestions or rules that don’t make sense yet.
1. Define where Kody should start reviewing
When activating Kody for the first time, it’s best to take a gradual approach — focusing on areas that bring immediate value and are easy for the team to understand. You can use the ready-to-go rules from the library without worrying about writing custom rules at this stage.
You don’t need to turn everything on right away. Start with rule categories that already help raise the technical bar without overwhelming the team:
✅ Security rules — to cover critical risks from the start
✅ Basic performance rules
✅ Best practice and style rules, but only the most straightforward and widely accepted ones
Avoid rules that deal with very superficial points or have low technical impact — like formatting tweaks, spacing, or import order. The goal at this stage is to focus on what actually improves code quality.
Select the types of analysis that make sense for the team
In addition to choosing which rules to enable, you can also configure which types of analysis Kody should run on PRs. This helps avoid suggestions that aren’t a priority for the team at this point.
The ideal setup here is to activate only the types of analysis that bring practical value right away, such as:
✅ Security – to catch more serious technical risks
✅ Performance – to avoid obvious bottlenecks
✅ Maintainability – to build a more sustainable codebase
Other types, like Code Style or Documentation, can be saved for later — once the team is more familiar with the process and wants to start refining the technical standard.
2. Set the minimum severity level to Medium
This setting controls what types of suggestions Kody will automatically comment on in PRs.
With the level set to Medium, it will only surface suggestions labeled as Medium, High, or Critical.
Low severity suggestions still exist, but they only show up if someone looks them up manually.
This is a good starting point because it prevents Kody from commenting on very superficial details — like style or organization — that tend to create more noise than technical value early on.
3. (Optional) Limit the maximum number of suggestions per PR
If the team is just getting started with the review process, limiting the number of suggestions per PR can help keep the conversations focused and avoid flooding the PR with too many comments from Kody.
This doesn’t block a full analysis of the PR, but it makes Kody prioritize the most relevant points first.
Tip: Start with a limit of 10 suggestions per PR and adjust based on the team’s feedback. Too many suggestions can feel overwhelming for someone just getting started. Too few might miss important issues.
4. Let the team work with these suggestions for a few sprints
No need to rush to fix everything at once.
The focus right now isn’t to “eliminate all issues,” but to build technical awareness and start creating consistency in reviews.
If devs start applying some suggestions naturally, great. If they ignore others, that’s fine too — it’ll help you understand what really matters in that context.
5. Use the Implemented Rate to track how the team is responding
In Kody’s Cockpit, you can see the Implemented Rate — the percentage of Kody’s suggestions that were actually applied by the team. It’s a simple metric, but it already gives a sense of whether the suggestions are making sense in practice or if they’re still being ignored.
That number works as an early signal to see if the process is gaining traction or not.
Use Code Health to see where to adjust or evolve
To go deeper, you can check the Code Health tab. There, you can see how many suggestions Kody has made for each type of analysis (e.g., security, performance, maintainability, etc.), both overall and by repository.
With that, you get a clearer view of:
- Where Kody is focusing most
- Which areas might be worth enabling more rules
- Or where it makes sense to adjust the severity of existing rules
You’ll also get a good sense of which areas are still weak in the code and could be a focus for upcoming sprints.
6. Adjust later based on real usage
After a few weeks running with these settings, you can:
- Raise the severity level to focus only on what’s truly critical
- Disable or tweak rules that are still being ignored in reviews
Little by little, you’ll start refining the team’s technical standard based on what actually works day to day.
The goal here isn’t to apply everything at once, but to start with what brings value — and tweak the process based on what actually happens in the real world.
