CodeRabbit em pt-BR: 3 defaults que fazem ruído

CodeRabbit instala em dois cliques. Você aprova o GitHub App, deixa o .coderabbit.yaml em branco e, no PR seguinte, aparece um bot comentando bastante coisa. Parece pronto.

Depois de escrever o capítulo 9 do meu book sobre revisão de código com IA, voltei para o YAML daquele capítulo e marquei o que ali é ajuste real e o que é ruído de default. 3 linhas trocam o comportamento de verdade. Uma quarta parece trocar e não troca nada — é o default escrito em cima de si mesmo.

Este post é sobre as 3 que valem, uma que não vale, e por que a resposta é diferente quando o time é pt-BR.

O default do CodeRabbit mira projeto em inglês

O schema oficial do .coderabbit.yaml tem default declarado para quase todo campo. Dá para abrir a referência YAML e ler linha por linha. Para um time pt-BR, 3 defaults batem logo no primeiro PR:

Os 3 juntos somam o que o seu time percebe como “o CodeRabbit comentou demais nesse PR”. Nenhum deles é o fato “a IA é ruim”. É o fato “o default não foi feito para o seu time”.

Ajuste 1 — language: pt-BR

language: pt-BR

O que o default faz: en-US. Todo comentário do bot sai em inglês.

O que a troca faz: CodeRabbit suporta mais de 100 códigos ISO, inclusive pt-BR. O walkthrough, o resumo de PR, as sugestões inline e as respostas no chat passam a vir em português do Brasil.

Por que a troca sozinha já corta ruído: não é “melhoria de qualidade”, é remoção de uma camada de tradução mental. Developer BR que lê 15 comentários em inglês por PR traduz 15 vezes antes de decidir se concorda. Em projeto onde a equipe conversa em português no Slack, no stand-up e na doc interna, continuar lendo review em inglês é fricção pura.

A linha, por si, é 1 token de ajuste. Mas é o único dos 3 ajustes que você sente antes mesmo do primeiro path_instructions entrar em cena.

Nota de precisão: CodeRabbit traduz o output do próprio bot, não o seu código. Comentários em código, nomes de função e commit messages continuam como você escreveu. Isso é bom — review não deve reescrever a convenção do repo, só comentar sobre ela.

Ajuste 2 — path_instructions com as regras do seu time

reviews:
  path_instructions:
    - path: "src/app/**"
      instructions: |
        Next.js App Router. Server Component é o padrão.
        Use "use client" só quando precisar de hook ou evento DOM.
        Data fetching no Server Component.
    - path: "src/repositories/**"
      instructions: |
        Repository Pattern. Importa os tipos de src/types/.
        Não escreva SQL puro — use o ORM.
    - path: "tests/**"
      instructions: |
        Arrange-Act-Assert. describe em português é aceito.
        Mock no mínimo, prefira integration test leve.

O que o default faz: []. O reviewer não sabe nada sobre convenções do seu time. Ele comenta o que modelos de linguagem acham que é “boa prática” numa aplicação genérica. Isso inclui renomear variáveis para o padrão que o modelo prefere, sugerir refactor que viola a arquitetura que você escolheu de propósito, e marcar como “problema” coisas que são regra interna.

O que a troca faz: cada path_instructions.path vira um glob que casa com arquivos do PR, e as instructions entram no contexto do reviewer só para os arquivos que casaram. Review de arquivo em src/repositories/ chega com a instrução “não escreva SQL puro — use o ORM” já embutida.

Por que isso corta mais ruído que parece: o volume de comentário “nitpick” do CodeRabbit vem de ele estar inventando convenção do zero a cada arquivo. Quando você escreve a convenção, ele para de inventar e passa a verificar. É o mesmo princípio do CLAUDE.md ou do AGENTS.md que você usa para o Claude Code — já falei disso no post sobre AGENTS.md como loop de feedback —, só que aplicado ao reviewer bot em vez de ao agente de desenvolvimento.

Dois cuidados valem a pena.

Instrução vale ouro quando é específica. "escreva código bom" não ajuda. "Server Component é o padrão, use 'use client' só quando precisar de hook" ajuda, porque é uma regra que o reviewer pode verificar lendo o arquivo. Se você não consegue imaginar o review-comment que a instrução vai gerar, provavelmente ela é genérica demais.

path_instructions é por glob, não por linguagem. Se seu monorepo mistura TypeScript e Python, use globs por diretório (src/api/**, scripts/**), não por extensão. A regra “não use SQL puro” só se aplica onde faz sentido, não no repo inteiro.

Ajuste 3 — path_filters para o que não deveria ser revisado

reviews:
  path_filters:
    - "!**/*.lock"
    - "!pnpm-lock.yaml"
    - "!**/node_modules/**"
    - "!**/dist/**"
    - "!**/.next/**"
    - "!**/*.generated.ts"

O que o default faz: []. Todo arquivo que entra no diff do PR vira candidato ao review.

O que a troca faz: CodeRabbit respeita um padrão parecido com .gitignore dentro de path_filters. Prefixo ! exclui.

Por que isso é menos óbvio do que parece: você provavelmente já tem .gitignore cuidando de node_modules/ e dist/. Então por que o CodeRabbit comentaria eles? Resposta: porque em algum momento alguém versionou um dist/ por acidente, ou porque o lockfile mudou junto com o package.json, ou porque o Next.js subiu .next/cache em um PR antigo. O .gitignore evita entrar no repo, mas quando entra, o reviewer olha. Review de pnpm-lock.yaml é um dos tipos de comentário mais inúteis que o CodeRabbit emite — “esta dependência foi atualizada”, sim, foi, essa é a razão do PR.

A linha "!**/*.generated.ts" é o caso que mais pega de surpresa times que usam gen de API (OpenAPI, Prisma Client, GraphQL Code Generator). Arquivo gerado não tem contexto humano, o reviewer tenta aplicar heurística humana em cima dele, e sai nitpick sobre nomenclatura de uma coisa que nenhum humano vai editar à mão. Barre pelo nome do arquivo.

O yaml inteiro, para colar

# .coderabbit.yaml
language: pt-BR

reviews:
  path_filters:
    - "!**/*.lock"
    - "!pnpm-lock.yaml"
    - "!**/node_modules/**"
    - "!**/dist/**"
    - "!**/.next/**"
    - "!**/*.generated.ts"

  path_instructions:
    - path: "src/app/**"
      instructions: |
        Next.js App Router. Server Component é o padrão.
        Use "use client" só quando precisar de hook ou evento DOM.
    - path: "src/repositories/**"
      instructions: |
        Repository Pattern. Importa os tipos de src/types/.
        Não escreva SQL puro — use o ORM.
    - path: "tests/**"
      instructions: |
        Arrange-Act-Assert. describe em português é aceito.

  auto_review:
    enabled: true

Pouco mais de 20 linhas. Troca os 3 defaults que custam mais caro num projeto pt-BR com Next.js. Troque os globs de path_instructions pelos diretórios reais do seu repo, mas o esqueleto é esse.

O default que já funciona (a armadilha de 1 linha)

reviews:
  auto_review:
    drafts: false   # ← parece ajuste. É cópia do default.

Em versões anteriores do meu capítulo 9 eu descrevi essa linha como “para que draft não seja revisado”. Lendo o schema oficial com calma: o default de auto_review.drafts já é false. Escrever drafts: false não troca nada. É yaml bonito que não faz trabalho nenhum.

Esse tipo de linha vira um pequeno pior-que-nada: ela ocupa espaço no arquivo e dá a sensação de que o yaml está “configurado”. Quando o próximo dev olhar o repo e perguntar “por que o draft não é revisado?”, a resposta é “porque é o default, não por causa dessa linha”.

Como separar ajuste de redundância no .coderabbit.yaml:

• Abra o YAML template oficial ao lado do seu arquivo
• Para cada linha do seu yaml, confira se o valor difere do default declarado
• Se for igual ao default, ou apaga a linha, ou transforma em comentário explicando a decisão (“estamos deixando o default por tal razão”)
• A segunda opção é melhor em time grande, onde outro dev pode achar que a ausência da linha é esquecimento

O ajuste real sobre draft é o oposto: se você quer que o bot revise draft (minha preferência, porque é no draft que o custo de errar é mais baixo), aí sim precisa escrever.

reviews:
  auto_review:
    drafts: true    # ← este sim é ajuste. Default é false.

É o mesmo valor com polaridade oposta. Só que agora a linha tem efeito.

O que esses 3 ajustes não resolvem

Dois comportamentos ficam quase inteiros no default — e são comportamentos que talvez você queira ajustar, mas não para “cortar ruído genericamente”. São escolhas de time.

reviews.profile. Default "chill". As outras opções documentadas são "quiet" (só o crítico) e "assertive" (nitpicky). chill é o meio-termo. Trocar para quiet reduz volume, mas também perde praise comments e summary. Trocar para assertive aumenta nitpick. Nenhum é “melhor” por default — depende do estágio do time. Em time novo com repo em formação, mais revisão é bom. Em time maduro com padrão estável, menos é melhor.

reviews.request_changes_workflow. Default false. Quando true, o bot emite Request Changes automático em issue grave, bloqueando merge até resolver. Isso é bom em pipeline onde PR não pode ir para main com flag de segurança levantada, e ruim em pipeline onde a decisão de merge é humana e você não quer que um bot segure o botão. Decisão de workflow, não de ruído.

Esses dois ficam fora da lista dos 3 porque, se eu colocasse “troque o profile” e “ligue o request_changes”, eu estaria dizendo que existe uma resposta certa. Não existe. Só os 3 ajustes acima (idioma, path_instructions, path_filters) têm resposta certa para quase todo time pt-BR com stack Node moderna. O resto é escolha.

O capítulo 9 do book

Harness Code Review tem o capítulo 9 inteiro sobre adoção e configuração do CodeRabbit, com o yaml que serviu de base para este post, além do request_changes_workflow, a função de chat, e como conectar o yaml com o AGENTS.md do seu time. Os outros capítulos cobrem a camada 1 (hooks), a camada 3 (humano), e como as 3 camadas se encaixam num funil de review que não deixa ninguém revisando lockfile.

Se você vai adotar CodeRabbit numa semana só, troque esses 3 defaults no primeiro dia e releia depois de 2 semanas de PRs reais. O custo de rever o yaml com uma semana de dados é baixo. O custo de deixar o default en-US + path_filters vazio por um mês é 4 sprints de review bilíngue com comentário sobre lockfile.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews