Cada commit que eu envio agora é revisado por uma IA antes que um humano o veja. Isso não é porque eu não confio no meu próprio código — é porque eu não confio na minha atenção às 23 horas de uma sexta-feira quando estou tentando implantar um patch antes do fim de semana.
A IA revisora detecta coisas que eu perco: uma variável declarada mas nunca utilizada, uma chave API acidentalmente deixada em um comentário, uma função que lida com o caminho feliz mas que falha com uma entrada vazia. Coisas pequenas. O tipo de coisas que uma revisão de código deveria capturar, mas que revisores humanos cansados também perdem.
Aqui está como eu conectei o OpenClaw ao GitHub Actions para uma revisão de código automatizada assistida por IA.
A Configuração
Disparador: Um workflow do GitHub Action que é executado em cada pull request. Quando uma PR é aberta ou atualizada, o workflow é acionado.
O que ele faz: O workflow extrai o diff da PR, envia para o OpenClaw para revisão e publica a revisão como um comentário da PR. Tempo total de execução: 30 a 60 segundos, dependendo do tamanho do diff.
O que o OpenClaw examina:
1. Bugs: referências nulas, erros de desvio, casos limite não tratados
2. Segurança: segredos codificados, padrões de injeção SQL, valores padrão inseguros
3. Estilo: inconsistências com a base de código, nomes de variáveis pouco claros, comentários ausentes em uma lógica complexa
4. Desempenho: ineficiências evidentes, loops desnecessários, consultas não otimizadas
O que ele não examina: Decisões arquitetônicas, design de funcionalidades, precisão da lógica de negócios. Isso requer um contexto humano que a IA não possui.
O Workflow do GitHub Action
O workflow é simples:
1. Verificar o código
2. Extrair o diff entre a branch da PR e main
3. Enviar o diff para o OpenClaw via sua API (ou CLI)
4. Formatar a resposta em um comentário da PR
5. Publicar o comentário
A extração do diff é a etapa importante. Você não envia toda a base de código — apenas as alterações. Isso mantém o número de tokens razoável (e o custo baixo) enquanto concentra a revisão no que realmente mudou.
Para PRs grandes (500+ linhas de alterações), eu divido o diff por arquivo e reviso cada arquivo separadamente. Isso produz um feedback mais direcionado do que enviar tudo para o modelo de uma só vez.
A Qualidade da Revisão
Após 3 meses e cerca de 200 PRs revisadas:
Verdades positivas (problemas reais detectados): Cerca de 25% das revisões. Basicamente, uma PR em quatro tem algo que a IA detecta que realmente conta. Os mais comuns: tratamento de erros ausente, nomes inconsistentes, variáveis não utilizadas.
Dicas ú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 (erros ou não pertinentes): Cerca de 35% das revisões contêm pelo menos uma sugestão incorreta. A IA não entende o contexto, sugere alterações que quebrarão a funcionalidade ou sinaliza padrões intencionais como problemas.
A taxa de falsos positivos de 35% parece alta, mas na prática, é gerenciável. Os comentários são claramente rotulados como gerados pela IA, e os desenvolvedores aprendem rapidamente quais sugestões levar a sério e quais ignorar.
Fazendo Isso Útil em vez de Perturbador
A diferença entre um revisor de IA útil e um perturbador:
Priorizar as constatações. Rotule cada constatação como: 🔴 Bug (corrigir antes de mesclar), 🟡 Aviso (considere corrigir), 🟢 Sugestão (melhoria opcional). Os desenvolvedores abordam os itens vermelhos, consideram os amarelos e passam pelos verdes.
Ser específico. “Pode haver um problema com o tratamento de erros” é inútil. “A função `processOrder()` na linha 47 não lida com o caso em que `order.items` é indefinido, o que acionará um TypeError” é acionável.
Não repetir o óbvio. Os desenvolvedores sabem que devem escrever testes. Não diga a eles em cada PR. Concentre-se em constatações específicas e não óbvias.
Limitar o número de comentários. Limite a revisão de IA a 5 comentários por PR. Se houver mais problemas do que isso, priorize e mostre os 5 melhores. Uma PR com 20 comentários de IA é completamente ignorada; uma PR com 3 a 5 comentários direcionados é lida.
Além da Revisão de Código
Uma vez que a integração das Ações do GitHub esteja operacional, você pode expandi-la:
Geração de descrição de PR. Quando uma PR é aberta sem uma descrição, a IA lê o diff e gera um resumo: o que mudou, por que isso provavelmente mudou e o que observar durante a revisão.
Análise da cobertura dos testes. A IA verifica se o código modificado tem testes correspondentes. “Você modificou `auth.js`, mas não atualizou `auth.test.js` — a atualização do teste foi intencional ou foi esquecida?”
Sugerir uma entrada de changelog. Com base no diff, a IA sugere uma entrada de changelog no formato apropriado. O desenvolvedor a aprova ou edita.
Compilação das notas de versão. Quando chega a hora de publicar, a IA compila todas as PRs mescladas desde a última publicação e gera notas de versão. Isso economiza de 30 a 60 minutos por publicação.
O Custo
Custo médio por revisão de PR: cerca de 0,08 $.
Custo mensal para 200 PRs: cerca de 16 $.
Para dar uma visão geral, um humano passando 15 minutos revisando cada uma dessas PRs gastaria 50 horas por mês na 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 se concentrar no design e na lógica.
O processo de revisão da minha equipe agora: revisão de IA primeiro (automatizada, 30 segundos). Revisão humana em seguida (focada no que a IA não pode avaliar, geralmente 5 a 10 minutos em vez de 15). Qualidade total da revisão: superior à anterior, em menos tempo.
🕒 Published: