🔁 Fluxo & Qualidade

Os acontecimentos reais do processo que podem disparar trabalho automático: issue aprovada, falha de CI, dependência vulnerável, PR aberto, queda de cobertura, alteração de API, incidente, erro em produção.

Automação sem evento claro vira robô rodando à toa. O gatilho define o valor: quanto mais previsível o evento, mais confiável a automação.

Evento → classificação → agente → validação → decisão → entrega · Nem todo evento merece automação.

Conectar o agente às ferramentas onde o processo acontece — rastreador de issues, repositório, CI/CD — em vez de criar um fluxo paralelo em algum chat.

Automação que vive fora do fluxo do time morre em duas semanas. Dentro do PR, ela é vista, revisada e cobrada.

O PR é a superfície de revisão · Rastreabilidade evento→mudança · Identidade própria do agente nos sistemas.

Uma falha de pipeline inicia uma investigação automática: o agente lê o log, reproduz localmente, propõe correção e abre um PR com evidência.

É o caso ideal para começar: o gatilho é objetivo, o verificador já existe (o próprio CI) e o resultado é reversível.

Verificador pronto = automação segura · Proposta em PR, nunca push direto · Falha intermitente exige diagnóstico, não retry cego.

Uma dependência vulnerável gera uma proposta de atualização, com o agente lendo o changelog, ajustando o código quebrado e provando com testes.

É trabalho recorrente, chato e bem definido — exatamente o perfil que compensa automatizar primeiro.

Breaking change exige leitura do changelog · Atualização sem teste é aposta · Uma dependência por PR.

Um incidente gera diagnóstico inicial automático: coleta de logs, correlação temporal, mudanças recentes suspeitas e hipóteses ordenadas.

Nos primeiros minutos de um incidente, o gargalo é reunir informação. Aí a IA ajuda muito — e aplicar correção sozinha é onde ela atrapalha.

Diagnosticar é seguro; mitigar em produção não · Preservar evidência antes de mexer · Hipótese ordenada acelera o humano.

O critério de corte: automatiza-se o que é frequente, verificável e reversível; exige-se aprovação no que toca produção, banco, infraestrutura, permissões e segurança.

Sem esse corte explícito, a automação cresce até tocar algo que ninguém queria que ela tocasse — geralmente num fim de semana.

Nem toda tarefa deve ser autônoma · Frequência × risco decide · Automação também precisa de dono.

Um agente revisor pode explorar arquivos relacionados, verificar contratos, analisar testes, encontrar duplicações e comparar com os padrões do repositório — não só olhar as linhas alteradas.

Os defeitos caros raramente estão na linha alterada; estão na interação dela com o resto do sistema.

Diff é o começo, não o escopo · Duplicação semântica só aparece com busca · Padrão do repo é critério.

O fluxo recomendado: agente implementador → testes determinísticos → agente revisor independente → análise de segurança → quality gates → revisão humana.

O agente que revisa não deve depender das conclusões do que implementou — a separação reduz o risco de ambos repetirem a mesma suposição incorreta.

Independência > capacidade · Revisor recebe spec + diff, não o raciocínio do autor · Contexto limpo por revisão.

A checagem de que a mudança respeita fronteiras de módulo, não cria dependência indevida, não duplica capacidade existente e não fura camadas.

É o tipo de defeito que nenhum teste pega e que custa caro seis meses depois.

Violação de fronteira é achado de revisão · Duplicação semântica > duplicação textual · Regra arquitetural pode virar teste.

A revisão explícita de falhas de segurança, impacto de desempenho e custo de manutenção futura — cada uma com sua lista própria.

Um revisor genérico ("revise este PR") encontra estilo. Um revisor com lente definida encontra o que dói.

Uma lente por passagem · Segredo exposto e injeção são bloqueio, não sugestão · Manutenção é custo futuro real.

O que o revisor automático não vê: intenção de negócio, contexto histórico, acordos não escritos — além da tendência a gerar comentários de baixo valor em volume.

Revisor que comenta trinta ninharias por PR treina o time a ignorar revisão — inclusive a boa.

Precisão > recall na revisão · Achado sem severidade é ruído · Falso positivo tem custo de confiança.

A revisão humana focada no que só ela decide: intenção, prioridade, risco de negócio e aceitação da consequência.

A IA filtra e prepara; a responsabilidade continua com quem aprova. Isso não é formalidade — é o que mantém alguém pensando no problema.

Responsabilidade não se delega · Humano revisa intenção, máquina revisa forma · PR pequeno é revisável de verdade.

O princípio central: uma regra escrita em texto é útil; a mesma regra transformada em teste automático é muito mais confiável.

Com IA gerando volume, regras que dependem de alguém lembrar param de funcionar na primeira semana movimentada.

Gate = condição obrigatória, não recomendação · Automático > disciplina · O código só avança se passar.

Os três primeiros portões: compila, segue o padrão, e os testes unitários e de integração passam.

São os gates que o agente consegue usar sozinho dentro do loop — quanto mais rápidos, mais útil o ciclo de correção automática.

Teste lento não entra no loop · Teste instável destrói confiança · Lint automático elimina discussão de estilo.

Testes que fixam o contrato com quem consome sua API, mais um piso mínimo de cobertura que bloqueia queda.

Quando o volume de mudanças cresce, o contrato é a primeira vítima silenciosa — e quem descobre é o cliente.

Cobertura é piso, não meta · Contrato preservado é requisito · Queda de cobertura bloqueia o merge.

Verificação automática de vulnerabilidades críticas, segredos comitados, dependências com CVE e padrões perigosos de código.

São achados objetivos e de alto custo — o tipo perfeito de regra para virar bloqueio automático, sem depender de revisor atento.

Nenhum segredo no repositório, nunca · Vulnerabilidade crítica bloqueia · Ruído de scanner precisa ser calibrado.

Gates de desempenho dentro de um limite acordado e a exigência de que toda migração tenha caminho de rollback testado.

Degradação entra devagar, mudança por mudança; e migração irreversível é o item que transforma um erro pequeno em incidente longo.

Orçamento de desempenho explícito · Migração reversível é gate · Rollback não testado não existe.

O pipeline completo: build → lint → testes → cobertura → análise estática → segurança → revisão → aprovação → deploy. O código só avança quando todos os gates obrigatórios são atendidos.

Gate que pode ser pulado "só desta vez" não é gate — é sugestão. E a exceção vira regra em duas semanas.

Obrigatório significa obrigatório · Exceção registrada e com prazo · O gate protege o time, não atrapalha.