A produção dos agentes ultrapassou a capacidade de revisão humana. Equipes relatam aumento no volume de PRs sem crescimento equivalente na capacidade dos revisores ou rigor dos testes. Plataformas de verificação combatem isso vinculando cada alteração a evidências — sucesso na build, resiliência dos testes (incluindo tentativas e detecção de falhas intermitentes), achados estáticos/de segurança e conformidade com políticas — e então corrigindo automaticamente falhas comuns. A novidade não são os testes em si; é a capacidade do agente de iterar dentro do CI, diagnosticar causas raiz e apresentar um artefato pronto para mesclagem com procedência auditável. Isso muda as métricas de sucesso de ‘linhas geradas’ para ‘reversões evitadas’ e ‘tempo para mesclagem com confiança’.

Comece com runners efêmeros e execução em sandbox para isolar tarefas do agente. Use builds herméticos para determinismo e higiene de cache. Fortaleça suítes de teste com testes baseados em propriedades, testes de mutação para qualidade de asserção e deltas de cobertura como barreiras. Adicione análise estática, SAST/DAST e checagens de risco de dependência; exporte resultados como SARIF. Aplique política como código para segredos, tratamento de PII e acesso à infraestrutura. Emita SBOMs e atestações de build vinculadas a SHAs de commit. Forneça logs e artefatos reproduzíveis para que humanos (e agentes) possam reproduzir falhas. Por fim, conecte métricas — MTTV (tempo médio para validar), taxa de mesclagem, taxa de falhas intermitentes, taxa de reversão — em dashboards que a organização realmente usa para decisões.

Agentes podem aprender a otimizar sinais de aprovação em vez de confiabilidade real. Armadilhas comuns incluem barreiras permissivas que criam ‘teatro verde’, testes instáveis que mascaram regressões, vazamento de prompts/dados em logs de CI e deriva de dependências que quebra o determinismo. Mitigações: exigir paridade de ambiente entre verificação e produção; colocar segredos em quarentena e redigir logs; rotular assinaturas de falhas intermitentes e isolá-las do status verde; adicionar orçamentos de desempenho e testes de regressão na barreira; e exigir atestações de artefatos antes do deploy. Periodicamente, teste o pipeline com caos — quebre caches, rotacione dependências e assegure que o tecido de verificação falhe fechado, não aberto.

Priorize métricas ligadas à segurança em produção e carga dos revisores: tempo para primeiro verde, tempo médio para validar (MTTV), taxa de sucesso de mesclagem sem edições humanas, taxa de reversão/reversão em 7 dias, delta de cobertura no código tocado, taxa de falhas intermitentes e achados de vulnerabilidade por PR. Para SLAs, defina builds determinísticos (>99% de reprodutibilidade), testes estáveis (<1% de falhas intermitentes) e taxas de reversão abaixo de um limite definido. Vincule incentivos a esses resultados para que agentes aprendam a função objetiva correta. Dashboards públicos para esses indicadores ajudam a alinhar engenharia, segurança e equipes de plataforma sobre o que significa ‘bom’.

Exija integração nativa com seu VCS/CI, suporte para sandboxes efêmeros e compatibilidade com builds herméticos. Peça saída SARIF, geração de SBOM e atestações, e suporte a política como código. Verifique a reprodutibilidade: é possível reproduzir determinísticamente uma execução falhada com as mesmas entradas? Avalie a observabilidade: rastreamentos, logs e evidências anexadas a cada PR. Verifique o custo total da verificação (computação, tempo de runner, armazenamento) e controles de privacidade para código e dados de teste. Por fim, procure aprendizado em ciclo fechado — o sistema melhora a partir de rótulos de falha ou apenas repete o mesmo playbook?