Quando o time nunca teve um processo claro de revisão, é comum as PRs passarem com só uma leitura rápida — sem padronização, sem critério técnico e sem visibilidade do que realmente importa. A ideia aqui é começar leve, mas com impacto real.
Se a Kody vai ser usada como ponto de partida pra estruturar esse processo, dá pra ativar as configurações certas pra gerar valor logo nas primeiras sprints — sem sobrecarregar o time com sugestões demais ou regras que ainda não fazem sentido.
1. Defina por onde a Kody deve começar a revisar
Quando for ativar a Kody pela primeira vez, o ideal é começar de forma gradual — focando nas áreas que trazem valor imediato e são fáceis do time entender. Você pode usar as regras prontas da biblioteca, sem precisar se preocupar em escrever regras customizadas nesse início.
Você não precisa ativar tudo de uma vez. Comece com categorias de regra que já ajudam a elevar o padrão técnico sem sobrecarregar o time:
✅ Regras de segurança — pra cobrir riscos mais críticos desde o início
✅ Regras de performance básica
✅ Regras de boas práticas e estilo, mas só as mais diretas e consensuais
Evite regras que tratam de pontos muito superficiais ou que têm baixo impacto técnico — como ajustes de formatação, espaçamento ou ordenação de imports. A ideia nesse começo é focar no que realmente melhora a qualidade do código.
Selecione os tipos de análise que fazem sentido pro time
Além de escolher as regras que vão ser ativadas, você também pode configurar quais tipos de análise a Kody vai executar nos PRs. Isso ajuda a evitar sugestões que ainda não são prioridade pro time nesse estágio.
O ideal aqui é ativar só os tipos de análise que trazem valor prático logo de início, como:
✅ Security – pra identificar riscos técnicos mais graves
✅ Performance – pra evitar gargalos óbvios
✅ Maintainability – pra garantir uma base mais sustentável
Outros tipos, como Code Style ou Documentation, podem ser deixados pra depois — quando o time já estiver mais acostumado com o processo e quiser ir refinando o padrão técnico.
2. Configure o nível mínimo de severidade como Medium
Essa configuração define quais tipos de sugestão a Kody vai comentar automaticamente nos PRs.
Com o nível ajustado pra Medium, ela só vai trazer sugestões classificadas como Medium, High ou Critical.
Sugestões de severidade Low continuam existindo, mas só aparecem se alguém buscar manualmente.
Esse é um bom ponto de partida porque evita que a Kody comente sobre detalhes muito superficiais — como estilo ou organização — que costumam gerar mais distração do que valor técnico nesse início.
3. (Opcional) Limite o número máximo de sugestões por PR
Se o time estiver começando agora com o processo de revisão, limitar o número de sugestões por PR pode ajudar a manter as discussões mais focadas e evitar que a Kody traga um volume de comentários difícil de acompanhar.
Isso não impede a análise completa do PR, mas faz com que a Kody priorize os pontos mais relevantes primeiro.
Dica: comece com um limite de 10 sugestões por PR e ajuste com base no feedback da equipe. Muitas sugestões de uma vez podem assustar quem está começando. Poucas demais podem deixar passar pontos importantes.
4. Deixe o time trabalhar com essas sugestões por algumas sprints
Não precisa correr pra corrigir tudo de uma vez.
O foco nesse momento não é “zerar os problemas“, mas criar consciência técnica e começar a estabelecer consistência nos reviews.
Se os devs começarem a aplicar algumas sugestões de forma natural, ótimo. Se ignorarem outras, tudo bem — isso vai ajudar a entender o que realmente importa praquele contexto.
5. Use o Implemented Rate pra acompanhar como o time está respondendo
No Cockpit da Kody, você consegue ver o Implemented Rate — a porcentagem de sugestões da Kody que foram realmente aplicadas pelo time. É uma métrica simples, mas que já dá uma noção se as sugestões estão fazendo sentido na prática ou se ainda estão sendo ignoradas.
Esse número serve como termômetro inicial pra avaliar se o processo está ganhando tração ou não.
Use o Code Health pra entender onde ajustar ou evoluir
Pra se aprofundar, você pode acessar a aba Code Health. Lá, dá pra ver quantas sugestões a Kody fez em cada tipo de análise (ex.: segurança, performance, manutenção etc), tanto no geral quanto por repositório.
Com isso, dá pra ter uma visão mais clara de:
- Onde a Kody está atuando mais
- Em quais áreas pode valer a pena ativar novas regras
- Ou onde faz sentido ajustar a severidade das regras existentes
Além disso, já dá pra ter uma ideia de quais pontos ainda estão fracos no código e podem virar foco das próximas sprints.
6. Ajuste depois com base no uso real
Depois de algumas semanas rodando com essas configurações, você pode:
- Subir o nível de severidade pra focar só no que for realmente crítico
- Desativar ou ajustar regras que continuam sendo ignoradas nas revisões
Aos poucos, dá pra ir refinando o padrão técnico do time com base no que realmente funciona no dia a dia.
A ideia aqui não é aplicar tudo de uma vez, mas começar com o que gera valor — e ir ajustando o processo com base no que realmente acontece no dia a dia.
