⚡ Mapeie os eventos que acionam agentes
O fluxo básico de qualquer automação é sempre o mesmo: evento → classificação → seleção do agente → execução → validação → decisão → entrega. Começar pelo evento evita o erro comum de construir um robô sem gatilho claro.
Como ler: só o miolo em ciano é realmente automático. Classificar e decidir continuam sendo governança — sua ou de uma regra sua. Automatizar o miolo é barato; automatizar as pontas é onde as equipes se machucam.
📋 Eventos que valem automação
Gatilho claro
Sem ele não há automação
Classificar
Nem todo evento é igual
Validar
Sempre antes de decidir
Decisão
Tem dono, tem critério
🔗 Integre com issues, repositórios e pipelines
A automação precisa viver onde o trabalho já acontece. Se o resultado do agente aparece num chat paralelo, ele não é revisado nem cobrado — e a automação morre por desuso, não por defeito.
✓ Integração que pega
- ✓O resultado chega como pull request, com diff revisável
- ✓O agente tem identidade própria (dá para filtrar e auditar)
- ✓O PR referencia o evento que o originou
- ✓A evidência (logs, testes) vem anexada, não resumida
✗ Integração que morre
- ✗Saída num canal de chat que ninguém acompanha
- ✗Push direto na branch principal
- ✗Agente usando a credencial pessoal de alguém
- ✗Nenhum rastro do evento que disparou a mudança
PR é a superfície
Onde a revisão existe
Identidade
Do agente, não sua
Rastro
Evento → mudança
Evidência
Anexada, não narrada
🔧 Automatize a correção de falhas de CI
É o melhor caso para começar: o gatilho é objetivo (o pipeline falhou), o verificador já existe (o próprio CI) e o resultado é reversível (um PR que você não precisa aceitar).
🧪 Exercício copiável — agente que investiga uma falha de CI
Objetivo: transformar um log de falha em diagnóstico e proposta com evidência. Pegue uma falha real do seu CI e cole o prompt abaixo no agente, com o repositório aberto.
Contexto: o pipeline falhou. Log completo abaixo. <cole aqui o log da falha> Faça, nesta ordem: 1. identifique a falha REAL (a primeira causa, não o último erro impresso); 2. diga se é: (a) bug no código, (b) teste instável, (c) ambiente/infra, (d) dependência — e qual evidência do log sustenta isso; 3. reproduza localmente com <comando de teste> e cole a saída real; 4. só se for (a): implemente a menor correção e rode os testes de novo; 5. se for (b), (c) ou (d): NÃO corrija — descreva o problema e pare. Restrições: - não altere testes existentes; - não adicione dependências; - não faça push na branch principal; deixe tudo na branch atual.
Como verificar: a classificação no passo 2 é o que interessa. Se o agente chamou de "bug no código" uma falha de rede intermitente, sua automação ainda não pode rodar sem supervisão — e você acabou de descobrir isso de graça.
💡 Dica prática
Teste instável é o inimigo silencioso da automação: ele ensina o agente (e o time) a tratar vermelho como ruído. Antes de automatizar correção de CI, elimine ou quarentene os testes que falham sozinhos.
Primeira causa
Não o último erro
Classificar
Antes de corrigir
Instável
Quarentena, não retry
Proposta
PR, nunca push direto
📦 Trate dependências e vulnerabilidades
Atualização de dependência é trabalho recorrente, chato e bem definido — o perfil ideal para automatizar cedo. O que diferencia uma automação boa de um robô irritante é a evidência que ela anexa.
Ler o changelog antes de subir a versão
O agente resume o que mudou entre as versões e destaca as quebras declaradas. Sem isso, atualizar é apostar.
Ajustar o código quebrado, uma dependência por PR
PRs com uma dependência cada são revisáveis e reversíveis individualmente. PR "atualiza tudo" é irrevisável por construção.
Provar com testes e anexar a saída
A suíte completa roda contra a nova versão e a saída real vai no corpo do PR. Sem prova, a atualização não é proposta — é sugestão.
Changelog
Leitura obrigatória
Um por PR
Revisão e rollback
Prova
Saída real anexada
CVE crítica
Prioridade, não fila
🚨 Use agentes na análise de incidentes
Nos primeiros minutos de um incidente, o gargalo é reunir informação: logs de vários serviços, mudanças recentes, correlação de horário. É exatamente onde um agente ajuda muito — e mitigar sozinho em produção é exatamente onde ele atrapalha.
🧭 Diagnóstico inicial automático
- •Coletar logs do período e agrupar por tipo de erro.
- •Listar deploys, feature flags e migrações nas últimas horas.
- •Correlacionar início do sintoma com a mudança mais próxima.
- •Apresentar hipóteses ordenadas, cada uma com a evidência que a sustenta.
- •Preservar as evidências antes que rotação de log as apague.
⚠️ Atenção
Durante incidente, o agente propõe — quem aplica é humano. Uma mitigação automática errada no meio de uma crise transforma um problema em dois, e destrói a linha do tempo que a análise posterior precisa.
Coletar
É o gargalo real
Correlacionar
Sintoma × mudança
Preservar
Antes de mexer
Não mitigar
Sozinho, em produção
⚖️ Decida o que automatizar e o que exige aprovação
Nem toda tarefa deve ser totalmente autônoma. Mudanças em produção, banco de dados, infraestrutura, permissões e segurança precisam de controles adicionais — sempre.
A matriz de decisão em duas perguntas
| reversível | irreversível
--------------------|-------------------|---------------------------
verificável | AUTOMATIZE | agente propõe, humano aplica
não verificável | agente rascunha, | NÃO AUTOMATIZE
| humano revisa |
Frequência entra depois: dentro do quadrante "automatize", comece pelo que acontece toda semana.
Checagem rápida: qual destas é a melhor primeira automação para um time que está começando?
Reversível
Primeiro critério
Verificável
Segundo critério
Frequente
Define a ordem
Dono
Automação sem dono apodrece
📌 Resumo do Módulo
Próximo Módulo:
3.2 - Code Review com IA: por que quem implementa não pode ser quem revisa.