A IA consegue mesmo corrigir falhas de CI?

Muitas vezes sim, em testes quebrados, erros de tipo, falhas de lint e problemas de configuração do CI, como uma versão ou uma variável de ambiente. O agente encontra o primeiro erro real no log, reproduz localmente e corrige. Você ainda revisa o resultado.

O agente faz push direto na main?

Não. O AgentVera nunca faz push direto na branch padrão. Uma falha na main volta como pull request; uma falha em uma branch de feature recebe push nessa branch com a entrega padrão.

O agente pode ficar preso em um loop de correções?

Não. No máximo 2 correções automáticas são tentadas por branch por dia, e só uma correção por branch roda ou espera de cada vez. Cada regra também tem seu próprio limite diário.

Com quais agentes funciona?

As regras de automação rodam o Claude Code ou o Codex. Você escolhe um no campo Agent da regra.

Quais sistemas de CI são suportados?

O gatilho “CI turned red” observa os provedores GitHub Actions, GitLab CI e Jenkins que você adiciona na aba CI/CD. Os gatilhos de comentário de PR e de issue precisam do repositório no GitHub e de um login no GitHub no seu computador.

Qual plano inclui isso?

As automações estão nos planos Pro e Team. No app desktop, elas ficam em Details → Automation → Automations.

Corrigir falhas de CI e comentários de PR com IA

Conseguir corrigir falhas de CI com IA automaticamente tira das suas mãos uma das tarefas mais repetitivas. Você faz push e, dez minutos depois, o GitHub Actions está vermelho. Você abre o log, rola duzentas linhas, encontra um erro de tipo ou um snapshot desatualizado, corrige e faz push de novo. Com comentários de PR é a mesma história: notas pequenas como “renomeie esta variável” ou “falta uma checagem de null aqui” se acumulam, e cada uma tira você do que estava fazendo.

Este post explica como passar esse trabalho para um agente de IA: o que o aciona, os limites sob os quais ele roda, como ele entrega e o que olhar antes de chegar à main.

Por que corrigir na mão sai caro

Corrigir um build vermelho raramente é difícil. O que custa caro é a troca de contexto:

Você está no meio de outra coisa. A notificação de CI vermelho tira você dela.
Ler logs leva tempo. O erro real está enterrado em centenas de linhas, e a primeira linha vermelha muitas vezes não é o erro real.
Você precisa reproduzir localmente. Encontrar o comando do CI, rodá-lo e resolver diferenças de ambiente é um trabalho à parte.
Os comentários chegam aos pedaços. Uma revisão com seis comentários significa ler os seis e responder a cada um.

O que essas tarefas têm em comum é um conjunto conhecido de passos. Trabalho com passos conhecidos é trabalho que dá para entregar a um agente.

Gatilhos: quando o agente começa?

No AgentVera, as automações ficam em Details → Automation → Automations. Uma regra começa a trabalhar sozinha quando um evento acontece. Dois gatilhos importam aqui.

CI ficou vermelho

Este gatilho observa os provedores que você adicionou na aba CI/CD: GitHub Actions, GitLab CI e Jenkins. Deixe Branches vazio para observar todas as branches, ou liste-as, como main, release/*.

Algumas execuções são ignoradas de propósito. Execuções de pull requests vindos de forks e execuções de merge requests do GitLab não disparam a regra. A branch e o log de um fork pertencem a alguém de fora do seu repositório, então a regra só reage a branches nas quais você pode fazer push de uma correção.

PR recebeu um comentário

Novos comentários de revisão e de conversa em pull requests abertos são lidos a cada 2 minutos, com filtros:

Só contam comentários do dono, dos membros ou dos colaboradores do repositório. Um comentário de passagem não inicia um agente.
Comentários de bots não contam. As próprias respostas do AgentVera são marcadas e nunca são lidas de novo.
Se um agente já está trabalhando naquele PR, os novos comentários vão para ele; nenhum segundo agente é aberto.
Se o limite diário foi atingido, os comentários não se perdem; eles são lidos de novo mais tarde.

Os gatilhos de comentário de PR e de issue precisam do origin do repositório no GitHub e de um login no GitHub no seu computador.

Os eventos são observados pelo app desktop, então o AgentVera precisa estar aberto no seu computador para que as regras rodem.

Presets

Quando um projeto ainda não tem regras, o AgentVera oferece presets. Dois deles fazem exatamente este trabalho:

Preset	O que faz
Fix CI when it breaks	Lê o log da execução vermelha e corrige; faz push em branches de feature e abre um PR para a branch principal
Handle PR comments	Aplica comentários de revisão em PRs abertos, faz push na branch do PR e responde

Os outros dois tratam issues com a label “ajan” e atualizam dependências toda segunda-feira.

O que o agente faz

Quando uma regra dispara, o agente começa em uma nova worktree, em uma nova branch que começa com ajan/. A branch parte da branch do evento: a branch da execução vermelha ou a branch do PR. A sua pasta de trabalho fica intocada. Arquivos .env ignorados pelo git são copiados para a worktree para que os testes rodem, mas nunca recebem push.

O agente segue os passos do Playbook da regra. Para CI, o playbook padrão é “Fix a CI failure”:

Encontrar o primeiro erro real no log.
Rodar o comando do CI localmente e reproduzir o erro.
Corrigir a causa raiz; se o problema está na configuração do CI (workflow, versão, variável de ambiente), corrigir isso.
Rodar de novo os comandos do CI localmente e vê-los passar.

Para comentários de PR, o padrão é “Address PR comments”: ler cada comentário e o código para o qual ele aponta, aplicar os que estão certos, explicar o raciocínio onde discordar, rodar os testes e, na resposta, listar o que foi feito para cada comentário.

Você pode alterar os playbooks. Salve os seus neste computador ou no repositório; os playbooks do repositório são gravados em .agentvera/playbooks/, compartilhados com a equipe pelo git, e substituem o playbook embutido de mesmo nome.

Use Extra instructions para restringir a regra. Por exemplo: “Corrija só testes e erros de tipo; não mude o contrato da API.”

No campo Agent, escolha Claude Code ou Codex.

Limites: o que segura o agente?

Um agente que roda sozinho precisa ser limitado, não só bom. No AgentVera, os limites são:

Um limite diário. Toda regra tem um valor Max per day de 1 a 50, 5 por padrão, contado nas últimas 24 horas. Execuções que você inicia na mão não contam para ele.
Um limite por branch. No máximo 2 correções automáticas de CI são tentadas por branch por dia, e só uma correção por branch roda ou espera de cada vez. Se uma correção quebrar o CI de novo, o agente não fica girando para sempre.
Texto de fora não é instrução. Logs de CI, comentários de PR e textos de issues são entregues ao agente como texto externo não confiável, que só descreve o trabalho. O agente é instruído a não compartilhar segredos, não rodar comandos sem relação com a tarefa e não enviar dados para nenhum outro lugar.
O agente não faz push. Ele só faz commit. O push e a abertura do PR são trabalho do AgentVera, feitos depois que o agente entrega.
Uma varredura de arquivos de segredos. Antes do push, cada commit e o estado final são verificados em busca de arquivos de segredos: arquivos .env, chaves como .pem e .key, id_rsa, .npmrc, .netrc, credentials.json e similares. Arquivos de exemplo como .env.example são permitidos. Se algum for encontrado, nada recebe push e a execução falha.
Um agente travado para. Se o agente pede ajuda, fica em silêncio ou fecha, a execução passa para “needs attention” e você recebe uma notificação.

Entrega: para onde vai o trabalho?

O que acontece quando o agente termina é definido em On delivery:

Opção	O que acontece
Automatic (push to the CI branch, PR to the main branch)	Push se a falha foi em uma branch de feature, PR se foi na branch padrão
Open a PR	Sempre um PR
Push to the same branch	Push na branch do evento; na branch padrão continua sendo um PR
Add to the merge queue	A branch entra na fila e o resultado do merge é testado
Leave on the branch	Nada recebe push; a branch fica com você

Uma regra nunca muda: o AgentVera nunca faz push direto na branch padrão. Se o agente não fez mudanças, a execução termina com uma nota de “sem mudanças”.

Para comentários de PR, o trabalho recebe push na branch do PR e o AgentVera publica uma resposta no PR descrevendo o que o agente fez para cada comentário.

Escolher a merge queue significa que a correção é testada mais uma vez em cima da main mais recente. Explico como a fila funciona no post sobre merge queue.

Revise antes de chegar à main

Uma correção automática não é uma aprovação automática. Há algumas formas de revisar o trabalho do agente:

O próprio pull request. Falhas na main já voltam como PRs. Leia o diff, veja o CI ficar verde e faça o merge como qualquer outro PR.
Aprovação na merge queue. Land passing branches automatically vem desligado por padrão, então o trabalho que passa na checagem espera por você.
Deixar na branch. Nas primeiras semanas de uma regra nova, escolher Leave on the branch e revisar na mão é a opção mais cautelosa.
A aba Runs. Veja o status de cada execução, o agente dela e o PR que ela abriu.

Para os seus próprios agentes, o AgentVera também tem revisão automática de código: quando o turno de um agente termina, um modelo Claude escolhido por você revisa o código e reporta os achados com severidade e arquivo:linha. Mais no post sobre revisão de código com IA.

Ao revisar, olhe com atenção:

Foi corrigido o teste ou o código? Se o agente mudou um valor esperado para fazer um teste passar, é um sinal de alerta. Você pode proibir isso em Extra instructions.
A configuração do CI mudou? Uma edição de workflow pode ser legítima, ou pode ser um passo pulado.
Ele ficou dentro do escopo? Um erro de tipo não deveria voltar como uma refatoração de dez arquivos.

Correções com um clique no centro de CI/CD

Talvez você não queira uma regra para cada execução vermelha. A aba CI/CD lista as 25 execuções mais recentes por provedor; você pode rodar uma execução de novo, rodar de novo só os jobs que falharam (não no Jenkins) ou cancelá-la. Em uma execução vermelha, Have an agent fix it abre um agente com os detalhes da execução e o final dos logs dos jobs que falharam. Desta vez você está ali junto com o agente.

Erros comuns

Observar a main com “Push to the same branch” e esperar um push direto. O AgentVera não faz push na branch padrão; a correção continua vindo como PR.
Colocar o limite diário no máximo. O limite é uma rede de segurança. Mantenha-o baixo até a regra ganhar a sua confiança.
Deixar Extra instructions vazio. Dizer ao agente o que não tocar restringe os resultados de forma perceptível.
Entregar testes instáveis ao agente. Para um teste que falha de vez em quando, o agente pode mudar coisas que não precisam ser mudadas. Resolva os testes instáveis você mesmo primeiro.
Guardar segredos no repositório. A varredura impede o push, mas a correção de verdade é nunca colocar segredos no repositório.

Um dia de exemplo

Manhã

O commit de alguém tarde da noite na main quebrou o CI. A regra “Fix CI when it breaks” pegou: o agente encontrou o erro de tipo no log, reproduziu localmente e corrigiu. Como era a branch padrão, o trabalho voltou como PR. Você lê o diff tomando café e faz o merge.

Meio-dia

Um colega deixa quatro comentários em um dos seus PRs. Em até dois minutos, a regra “Handle PR comments” entra em ação. O agente aplica três, discorda de um e explica por quê. O AgentVera faz push na branch do PR e deixa uma resposta no PR. Tudo o que você faz é ler aquele do qual ele discordou e decidir.

Tarde

O CI continua falhando em uma branch de feature. O agente tenta duas vezes, e os testes continuam vermelhos nas duas. Não há terceira tentativa; você vê o status na aba Runs. O log mostra que o problema é uma variável de ambiente de teste, então você mesmo corrige.

Checklist

O seu provedor de CI está adicionado na aba CI/CD?
Para repositórios do GitHub, você está logado no GitHub neste computador?
O campo Branches está certo? Vazio significa todas as branches.
As Extra instructions dizem o que o agente não deve tocar?
O Max per day está definido de forma conservadora?
O On delivery combina com a forma como você gosta de revisar?
Os seus segredos estão fora do repositório?

Conclusão

Entregar falhas de CI e comentários de PR a um agente de IA devolve a parte mais interrompida do seu dia. O que importa não é o agente ser rápido, mas ser limitado: no AgentVera, ele trabalha na própria worktree, não faz push sozinho, nunca escreve direto na branch padrão, não faz push de trabalho que contenha arquivos de segredos e recebe um número limitado de tentativas por branch. A palavra final continua sendo sua, no PR ou na merge queue.