A geração agêntica de código muda a unidade de trabalho. Em vez de uma pessoa escrever e revisar um PR pequeno, um agente pode criar dezenas de implementações candidatas, estruturas iniciais para vários serviços e migrações automatizadas. O resultado: o volume e a diversidade ampliam a superfície que precisa ser revisada. As equipes enfrentam duas pressões — produtividade (continuar entregando funcionalidades) e segurança (evitar regressões ou problemas na cadeia de suprimentos). Esta seção explica como a automação amplia a superfície de revisão, por que os revisores se tornam um gargalo e quais funções organizacionais são mais afetadas: engenheiros de lançamento, equipes de segurança e responsáveis pela manutenção de bibliotecas críticas.

Os testes validam o comportamento esperado nos cenários escolhidos e são mais eficazes para evitar regressões contempladas pelos casos de teste. A análise estática e os linters detectam erros de tipo, problemas de memória e muitos usos incorretos de APIs antes da execução. A revisão de código por IA ajuda a avaliar a legibilidade, possíveis bugs de lógica e regressões de estilo em grande escala, mas pode não detectar erros semânticos sutis ou lógica alucinada. Já a verificação formal prova propriedades para todas as entradas quando há especificações precisas. Na prática: use testes para cobrir comportamentos, ferramentas estáticas para problemas estruturais, revisão por IA para triagem e provas para invariantes e garantias de concorrência ou criptografia que os testes, estatisticamente, não conseguem esgotar.

Os métodos formais são poderosos, mas não servem para tudo. Exigem especificações precisas — uma tarefa de projeto nada trivial — e muitas vezes precisam que o código seja escrito em subconjuntos adequados à prova ou tenha contratos anotados. São menos úteis para problemas de layout de interface, ajustes de desempenho ou expectativas de comportamento que dependem de entradas imprecisas do mundo real. O uso excessivo de provas pode criar gargalos quando as equipes tentam verificar formalmente bases de código grandes e em rápida mudança. Esta seção aborda armadilhas comuns: divergência entre especificações e implementação, custo de manutenção das provas, atritos de integração com CI e o risco de uma confiança indevida quando há provas, mas as premissas estão incorretas.

Adote um pipeline em camadas: 1) Geração guiada pela especificação — escreva contratos de API precisos, tipos e testes baseados em propriedades antes de pedir que os agentes implementem; 2) Síntese em ambiente isolado — execute os agentes em runners de CI isolados que instrumentem e façam fuzzing nos módulos gerados; 3) Barreiras automatizadas — exija testes unitários, de integração e de propriedades, além das verificações de segurança do GitHub AI Scan, antes da revisão humana; 4) Provas formais direcionadas — aplique provas a invariantes críticos (consenso, criptografia, autorização) ou a módulos com grande impacto potencial; 5) Verificação humana — concentre os revisores no projeto, na conformidade com as especificações e na análise adversarial, em vez de verificar linha por linha. Integre as ferramentas de modo que cada etapa seja visível nos painéis de PR e não bloqueie o fluxo de trabalho.

Comece aos poucos: faça um projeto-piloto de provas em um serviço crítico, monitore métricas para medir o tempo de exposição a defeitos e o tempo de revisão e capacite engenheiros de SRE e segurança para escrever especificações e estruturas de prova. Crie novas funções ou rodízios — como engenheiros de provas ou responsáveis por verificação — que possam traduzir requisitos de produto em contratos verificáveis por máquina. A longo prazo, espere uma divisão: a maior parte do código será validada por ferramentas rápidas e probabilísticas e por revisores humanos; um conjunto menor de módulos de alto valor será reforçado com provas formais. Essa combinação preserva a velocidade e reduz drasticamente os riscos sistêmicos onde isso mais importa.