autoFixable: o padrão que corrige 40% dos comentários de PR antes do humano ver

Vou começar com uma opinião que não vai agradar metade dos revisores seniores que conheço: se o seu comentário de PR começa com “por favor, remova o import não utilizado”, você está cobrando R$200/hora para fazer o trabalho de um script de 10 linhas.

Não estou dizendo que a revisão humana é dispensável. Estou dizendo que 40% dos comentários que revisores humanos ainda escrevem no Brasil em 2026 não deveriam ter chegado até o humano. Existe um padrão simples para filtrar esses 40% antes do PR ser aberto. Chamamos ele de autoFixable. Este texto é sobre o que ele é, os 3 lugares onde ele quebra na prática, e quanto isso vale por hora.

O padrão em uma linha

autoFixable é uma classificação binária que você aplica a cada tipo de comentário de revisão. Duas caixas:

• autoFixable: a correção é mecânica, a resposta certa é única, e existe uma ferramenta que aplica sem julgamento humano.
• non-autoFixable: precisa de contexto de negócio, ou a resposta certa depende de decisão de design.

O padrão diz: antes de escrever qualquer comentário de PR, pergunte se ele é autoFixable. Se for, não escreva. Rode a correção.

Isso é tudo. A parte interessante começa quando você tenta operacionalizar.

Como isso vira 40% na prática

Rodei um levantamento no repositório principal de um cliente, com uns 40 mil commits e 6 revisores ativos. Peguei todos os comentários de PR dos últimos 90 dias e classifiquei manualmente por tipo.

Tipo de comentário	% do total	Categoria
Formato (indentação, aspas, ponto-e-vírgula)	18%	autoFixable
Import não utilizado ou desordenado	11%	autoFixable
Cast/tipagem inferível pelo TypeScript strict	6%	autoFixable
Regra de linter conhecida (no-console, prefer-const)	5%	autoFixable
Bug de lógica	22%	non-autoFixable
Sugestão de renomear	14%	non-autoFixable
Discussão de design	12%	non-autoFixable
Correção N+1	8%	non-autoFixable
Outros	4%	misto

Soma dos autoFixable: 40%.

Não é magia. É que quase toda equipe brasileira que eu vi ainda revisa import não utilizado no PR, e cada um desses comentários custa uma ida-e-volta.

O pipeline autoFixable de 3 camadas

Depois de aceitar o padrão, você precisa de um pipeline que o execute. Nossa versão tem três camadas.

Camada 1: pre-commit local (Biome ou Ruff)

A primeira barreira é local. Rodamos o Biome 2.5 (que já ultrapassou 500 regras em junho de 2026) via hook pre-commit.

// biome.json
{
  "$schema": "https://biomejs.dev/schemas/2.5.0/schema.json",
  "formatter": { "enabled": true },
  "linter": {
    "enabled": true,
    "rules": { "recommended": true }
  },
  "assist": {
    "actions": {
      "source": { "organizeImports": "on" }
    }
  }
}

# .husky/pre-commit
biome check --write --staged

Isso mata os 18% de formato + 11% de import na origem. O desenvolvedor nem chega a commitar código com esses problemas.

Se você acha que hook pre-commit é intrusivo, você está certo. Uma parte da equipe reclamou. Deixamos reclamar por duas semanas. Depois disso ninguém se lembrava, porque o hook rodava em 200ms e o commit continuava.

Camada 2: GitHub Actions auto-fix no PR

A segunda barreira roda quando alguém consegue driblar a camada 1 (Windows sem WSL, gente que edita direto no navegador, PRs de bot).

# .github/workflows/autofix.yml
name: Auto Fix
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  autofix:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.head_ref }}
          token: ${{ secrets.GITHUB_TOKEN }}
      - uses: biomejs/setup-biome@v2
      - run: biome check --write .
      - name: Commit if changed
        run: |
          git config user.name "autofix-bot"
          git config user.email "autofix@example.com"
          git diff --quiet || (
            git add -A &&
            git commit -m "chore: auto-fix (Biome)" &&
            git push
          )

Isso resolve mais 5-6%. Não é o dobro da camada 1 porque grande parte já foi filtrada antes.

Camada 3: revisor com filtro mental “autoFixable? não abra a boca”

A terceira barreira é humana. Todo revisor recebeu uma orientação escrita: se você está prestes a comentar algo que a camada 1 ou 2 deveria ter pego, escreva no canal de infra e não no PR.

Isso muda a natureza dos comentários. Passamos de “6 comentários, 4 sobre estilo” para “3 comentários, todos sobre lógica ou design.” O autor do PR passa a receber feedback que ele não conseguiria automatizar sozinho.

Esta camada é a mais barata de implementar (uma frase em um doc de integração inicial) e a que mais melhora a percepção da revisão pela pessoa que abriu o PR.

Os 3 lugares onde autoFixable quebra

Se fosse tão simples, não teria um post. Aqui é onde eu levei porrada.

Quebra 1: regras “quase-autoFixable” que exigem julgamento

prefer-const parece autoFixable. Substituir let x = 5 por const x = 5 é mecânico. Mas se x for reatribuído em um bloco alcançado só em runtime (via eval, ou reflexão), o --fix do linter estraga o código.

Solução: aplicamos apenas fixes que o Biome ou o ESLint marcam como safe. Fixes unsafe (que o próprio linter admite não ter certeza) ficam desligados. Você troca cobertura por confiança, e no ponto que estamos rodando esse trade-off vale.

Quebra 2: PRs de fim de sprint com hotfix

No apagar das luzes, alguém abre um PR crítico às 23h com o rótulo “hotfix”. O auto-fix do PR roda, faz reformat em 340 arquivos que não deveriam ter sido tocados no hotfix (porque a última rodada de auto-format tinha sido pulada), e o PR fica ilegível.

Solução: excluímos rótulos hotfix e emergency da camada 2. Se o autor sabe que é emergência, ele não quer o robô mexendo.

Quebra 3: o “eu já tinha corrigido” duplicado

O auto-fix da camada 2 commita depois do push do desenvolvedor. Se o desenvolvedor já tinha aberto uma segunda edição local, ele volta e faz git pull --rebase, entra em conflito com um commit de bot, e reclama que “o CI me atrapalhou de novo.”

Solução: documentamos o fluxo (pull --rebase sempre antes de continuar editando, ou desligar a camada 2 nesse repo). Também comunicamos no README que o bot vai commitar. Uma semana de dor, depois some.

Quanto isso vale por hora em BRL

Vamos ao número que a maioria dos posts sobre revisão de código não mostra.

• Revisor senior no Brasil em 2026: entre R$150 e R$250 por hora cheia (contratação PJ, faixa média de mercado em SP/RJ).
• Uma equipe de 6 pessoas gera cerca de 80 comentários de revisão por semana no repositório que medi.
• 40% autoFixable = 32 comentários/semana que não precisariam existir.
• Cada comentário desses custa, olho na munheca, 4 minutos entre escrever e o autor responder e o revisor validar.
• 32 × 4 min = 128 minutos/semana = ~2,1 horas.
• A R$200/h: R$420/semana, ou ~R$1.680/mês por equipe de 6.

Isso é só o custo direto. O custo indireto (autor esperando um ciclo, contexto perdido, PRs empilhados) é maior e mais difícil de medir. O número mesmo assim é embaraçoso o suficiente pra você abrir o biome.json amanhã.

Onde eu ainda estou errado

Duas honestidades finais.

Primeira: 40% é a taxa em uma equipe que ainda comentava muito estilo. Uma equipe já disciplinada tem menos comentários totais, e o autoFixable relativo cai. Ainda vale, mas o retorno absoluto é menor.

Segunda: o padrão pressupõe uma equipe que aceita bot commitando no branch do PR. Cultura de “só humanos commitam” mata a camada 2 inteira. Nesse caso, dobre a camada 1 e a camada 3.

Se você já rodou um pipeline sem IA para revisão, este outro post que escrevi mostra como Tree-sitter entra antes ainda, para reduzir o token gasto pelo agente de revisão. autoFixable é o irmão barato e chato desse pipeline: não precisa de IA nenhuma, resolve 40% dos comentários, e ninguém escreve sobre ele porque “rodar Biome” não vende curso.

---

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