Semana passada eu vi um agente gerar em quinze minutos uma feature que eu levaria uma tarde inteira para escrever. Código limpo, nomes de variável decentes, até um comentário explicando uma decisão de design que eu nem tinha pedido. E aí veio a pergunta que estragou meu entusiasmo: como é que eu sei que isso está certo? Não "parece certo". Certo de verdade, do jeito que eu confiaria para ir pra produção sem ficar checando o deploy a cada cinco minutos.
A pesquisa da JetBrains de 2026 mostrou que cerca de 90% dos desenvolvedores profissionais já usam agentes de IA pelo menos uma vez por semana no trabalho. Isso não é mais novidade, é infraestrutura. O gargalo deixou de ser "quem escreve o código" — porque agora qualquer um com um prompt decente escreve bastante código, rápido. O gargalo virou outra coisa, bem mais incômoda: quem garante que aquilo funciona, continua funcionando daqui a três meses, e não quebra silenciosamente quando alguém mexer do lado.
E é aqui que eu quero chegar: testes automatizados deixaram de ser aquela tarefa chata que a gente empurra pro final do sprint. Eles viraram o contrato de confiança entre você e o agente. A única coisa que separa "o agente disse que funciona" de "eu sei que funciona".
Por que o teste virou a estrela da festa
Agente de IA é ótimo pra produzir. É péssimo pra assumir responsabilidade. Ele não vai ficar de madrugada debugando um incidente, não vai levar bronca do cliente, não tem pele em jogo. Ele entrega o código e segue em frente, feliz, sem noção nenhuma do que aconteceu depois. Isso não é uma crítica moral à IA, é só a natureza da coisa: ausência de consequência não produz cautela.
Então a pergunta nunca foi "o agente escreve bom código?". Às vezes escreve, às vezes escreve uma função que parece ótima e esconde um edge case homicida. A pergunta certa é: existe alguma afirmação executável, verificável, que prova que o comportamento esperado acontece? Documentação não prova nada, ela descreve intenção e já vi muita documentação mentir descaradamente. Revisão humana ajuda, mas não escala no volume que esses agentes produzem agora. Teste automatizado é diferente: ele roda, ele falha ou passa, não tem meio-termo, não tem interpretação subjetiva. É a única coisa no fluxo inteiro que não aceita "mais ou menos".
A inversão que muda o jogo: teste como prompt executável
Isso me levou a inverter a ordem que eu trabalho há anos. Antes eu escrevia a função, depois (se sobrava tempo, sejamos honestos) escrevia o teste. Hoje faço o oposto, e de propósito: descrevo o comportamento esperado primeiro — os testes, os critérios de aceite, os casos de borda que eu já sei que vão doer — e só depois deixo o agente implementar contra aquilo.
Na prática isso significa: "essa função precisa devolver erro quando o CPF é inválido, precisa tratar string vazia, precisa ser idempotente se chamada duas vezes com o mesmo payload" vira um punhado de testes escritos antes de qualquer linha de implementação existir. O agente recebe o teste como alvo, não como checklist opcional. Ele implementa, roda, ajusta, repete até passar. Eu não preciso ler cada linha do código gerado linha por linha torcendo pra não ter passado nada batido — eu leio o teste, que é muito mais curto, muito mais legível, e confio no resultado porque ele foi verificado contra uma especificação que eu mesmo escrevi.
Teste virou prompt executável. Não é metáfora bonitinha, é literal: em vez de escrever um parágrafo de instrução em linguagem natural e torcer pra interpretação do agente bater com a minha, eu escrevo uma asserção. Zero ambiguidade. O agente não pode "interpretar" um assertEquals de um jeito diferente do outro.
O que muda no dia a dia
A pirâmide de testes, aquela coisa que todo mundo cita em entrevista e ninguém respeita na prática, voltou a importar de verdade. Muitos testes unitários rápidos e baratos na base, menos testes de integração no meio, poucos end-to-end no topo. Por quê? Porque quando o agente itera em cima de um teste, ele precisa de feedback em segundos, não em minutos. Uma suíte de testes de integração lenta e pesada não dá sinal rápido o suficiente pra guiar a geração — o agente fica girando, tentando coisas, sem saber rápido se acertou.
Agora, um ponto que pouca gente fala: teste frágil é inimigo do agente, não amigo. Teste que quebra por mudança de formatação, que depende de ordem de execução, que faz mock de implementação interna em vez de comportamento observável — isso confunde o agente tanto quanto confunde um dev júnior. Ele vai "consertar" o teste pra passar em vez de consertar o código, porque pra ele os dois caminhos são indistinguíveis: ambos fazem a asserção virar verde. Se seu teste está acoplado a detalhe de implementação, você está ensinando o agente a trapacear sem querer.
Cobertura de código também precisa de uma reavaliação dura. Noventa por cento de cobertura não significa nada se metade dos testes só chama a função e confere que ela não lançou exceção. Isso sempre foi teatro, mas na era dos agentes o teatro fica mais caro, porque agora tem muito mais código passando por essa cobertura de mentirinha, com muito mais velocidade. Vale a pena olhar pra mutation testing — ferramentas que injetam bugs propositais no seu código e checam se os testes pegam — e pra testes baseados em propriedade, que descrevem invariantes ("para qualquer entrada válida, essa função nunca deve retornar negativo") em vez de casos fixos. Ambos são formas de fazer a suíte de testes realmente provar algo, em vez de só existir.
Opinião que vai incomodar alguém
Time sem cultura de teste vai sofrer muito mais com agentes de IA, não menos. Essa é a parte que eu acho que ninguém quer ouvir. A narrativa confortável é "a IA vai escrever os testes pra gente, relaxa". Só que agente de IA amplifica o que já existe no repositório. Se a cultura já era de testar por obrigação, fingir cobertura, deixar suíte quebrada no CI "porque é só aquele teste flaky mesmo", o agente vai aprender exatamente esse padrão e reproduzir em escala industrial. Você não ganha disciplina de graça só porque trocou quem digita.
Já vi equipe que achava que ia "acelerar com IA" e no fim das contas acelerou a produção de dívida técnica, porque a rede de segurança que deveria pegar os erros simplesmente não existia, ou existia só de fachada. Quanto mais rápido você gera código, mais rápido você precisa de algo que separe o que presta do que não presta. Sem teste de verdade, agente de IA não é multiplicador de produtividade — é multiplicador de bagunça, só que com confiança falsa embutida porque "ah, mas passou no CI".
Código gerado ficou barato. Isso é fato, e é ótimo. Mas confiança continua cara, e vai continuar sendo cara por muito tempo — ela não escala com modelo maior nem com prompt mais esperto. Teste automatizado, bem escrito, não acoplado a implementação, rodando rápido, é a forma mais direta que a gente tem hoje de comprar essa confiança. Não é burocracia que sobrou do mundo pré-IA. É o contrato que diz pro agente exatamente o que "certo" significa, e é a prova que você mostra pra si mesmo — e pro seu time — de que aquele código que saiu em quinze minutos realmente faz o que deveria fazer.