Todo commit que envio agora é revisado por uma IA antes de qualquer humano vê-lo. Não porque eu não confie no meu próprio código — mas porque eu não confio na minha própria atenção às 23h de uma sexta-feira, quando estou tentando enviar uma correção antes do fim de semana.
A revisora de IA capta coisas que eu perco: uma variável declarada mas nunca usada, uma chave de API acidentalmente deixada em um comentário, uma função que gerencia o caminho feliz mas falha com entrada vazia. Coisas pequenas. O tipo de coisas que a revisão de código existe para detectar, mas que revisores humanos cansados também perdem.
Aqui está como conectei o OpenClaw ao GitHub Actions para revisão de código assistida por IA automatizada.
A Configuração
Gatilho: Um fluxo de trabalho do GitHub Action que é executado em cada pull request. Quando um PR é aberto ou atualizado, o fluxo de trabalho é acionado.
O que faz: O fluxo de trabalho extrai a diferença do PR, envia para o OpenClaw para revisão e publica a revisão como um comentário do PR. Tempo total de execução: 30-60 segundos, dependendo do tamanho da diferença.
O que o OpenClaw revisa:
1. Bugs: referências nulas, erros off-by-one, casos extremos não tratados
2. Segurança: segredos hardcoded, padrões de injeção SQL,Defaults inseguros
3. Estilo: inconsistências com a base de código, nomes de variáveis confusos, comentários ausentes em lógicas complexas
4. Desempenho: ineficiências óbvias, loops desnecessários, consultas não otimizadas
O que não revisa: Decisões de arquitetura, design de recursos, correção de lógica de negócios. Essas requerem contexto humano que a IA não tem.
O Fluxo de Trabalho do GitHub Action
O fluxo de trabalho é simples:
1. Fazer checkout do código
2. Extrair a diferença entre o branch do PR e o main
3. Enviar a diferença para o OpenClaw através de sua API (ou CLI)
4. Formatando a resposta como um comentário do PR
5. Publicar o comentário
A extração da diferença é o passo importante. Você não envia toda a base de código — apenas as mudanças. Isso mantém a contagem de tokens razoável (e o custo baixo) enquanto foca a revisão no que realmente mudou.
Para PRs grandes (mais de 500 linhas de mudanças), eu divido a diferença por arquivo e reviso cada arquivo separadamente. Isso produz um feedback mais focado do que jogar tudo no modelo de uma vez.
A Qualidade da Revisão
Depois de 3 meses e cerca de 200 PRs revisados:
Verdadeiros positivos (captaram problemas reais): Cerca de 25% das revisões. Aproximadamente um em cada quatro PRs tem algo que a IA capta e que importa. Mais comum: ausência de tratamento de erros, nomeação inconsistente, variáveis não utilizadas.
Sugestões úteis (não bugs, mas melhorias): Cerca de 40% das revisões. Melhorias de estilo, sugestões de legibilidade, lacunas na documentação. Não críticas, mas úteis.
Falsos positivos (errados ou irrelevantes): Cerca de 35% das revisões contêm pelo menos uma sugestão incorreta. A IA mal interpreta o contexto, sugere mudanças que quebrariam a funcionalidade ou sinaliza padrões intencionais como problemas.
A taxa de 35% de falsos positivos parece alta, mas na prática é gerenciável. Os comentários são claramente rotulados como gerados por IA, e os desenvolvedores rapidamente aprendem quais sugestões levar a sério e quais ignorar.
Tornando Útil em vez de Inconveniente
A diferença entre uma revisora de IA útil e uma irritante:
Priorizar descobertas. Rotule cada descoberta como: 🔴 Bug (corrigir antes de mesclar), 🟡 Aviso (considere corrigir), 🟢 Sugestão (melhoria opcional). Os desenvolvedores abordam os itens vermelhos, consideram os amarelos e leem rapidamente os verdes.
Ser específico. “Pode haver um problema com o tratamento de erros” é inútil. “A função `processOrder()` na linha 47 não trata o caso onde `order.items` é indefinido, o que gerará um TypeError” é acionável.
Não repetir o óbvio. Os desenvolvedores sabem que devem escrever testes. Não diga isso em cada PR. Foque em descobertas específicas e não óbvias.
Limitar a contagem de comentários. Limite a revisão da IA a 5 comentários por PR. Se houver mais problemas do que isso, priorize e mostre os 5 principais. Um PR com 20 comentários da IA é totalmente ignorado; um PR com 3-5 comentários focados é lido.
Além da Revisão de Código
Uma vez que a integração do GitHub Actions esteja funcionando, você pode estendê-la:
Geração de descrição do PR. Quando um PR é aberto com uma descrição vazia, a IA lê a diferença e gera um resumo: o que mudou, por que provavelmente mudou, e o que observar durante a revisão.
Análise da cobertura de testes. A IA verifica se o código alterado tem mudanças de teste correspondentes. “Você modificou `auth.js`, mas não atualizou `auth.test.js` — a atualização do teste foi intencional ou esquecida?”
Sugestão de entrada do changelog. Com base no diff, a IA sugere uma entrada de changelog no formato apropriado. O desenvolvedor aprova ou edita.
Compilação de notas de lançamento. Quando chega a hora de lançar, a IA compila todos os PRs mesclados desde o último lançamento e gera notas de lançamento. Isso economiza de 30 a 60 minutos por lançamento.
O Custo
Custo médio por revisão de PR: cerca de R$0,08.
Custo mensal para 200 PRs: cerca de R$16.
Para contextualizar, um humano que gasta 15 minutos revisando cada um desses PRs gastaria 50 horas por mês em revisão de código. A IA não substitui a revisão humana — ela pré-processa, capturando os problemas mecânicos para que os humanos possam focar em design e lógica.
O processo de revisão da minha equipe agora: revisão da IA primeiro (automatizada, 30 segundos). Revisão humana em segundo lugar (focada no que a IA não pode avaliar, tipicamente de 5 a 10 minutos em vez de 15). Qualidade total da revisão: maior do que antes, em menos tempo.
🕒 Published: