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

Sobre os números deste texto. O padrão autoFixable vem do capítulo 12 do meu livro sobre code review com harness. Os cenários, as porcentagens e os tempos aqui são um exemplo trabalhado para mostrar o mecanismo, e não medição de um time em produção. Meça no seu repositório antes de adotar qualquer número daqui.

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. No meu livro eu chamo isso 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

Para dimensionar o problema, suponha um repositório grande, com dezenas de milhares de commits e meia dúzia de revisores ativos, e classifique por tipo os comentários de PR de um trimestre.

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. É comum uma parte da equipe reclamar nas primeiras semanas. A reclamação costuma sumir quando o hook roda em algumas centenas de milissegundos e o commit segue sem travar.

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 tipo de repositório que estamos supondo.
• 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