Agente da Momentic encontrou 269 bugs em uma hora, tres vezes mais que o Codex

Testes automatizados sao bons para detectar aquilo de que a equipe ja suspeita. Se um desenvolvedor escrever o cenario “abrir o carrinho, clicar em pagar e ver a confirmacao”, o sistema repetira fielmente exatamente esses passos. Mas ele nao tentara clicar duas vezes em um botao, voltar no meio do pagamento ou abrir um formulario em uma tela estreita, a menos que alguem adicione explicitamente essas etapas.

A startup Momentic propoe outra abordagem. Seu agente de QA, o Mo, recebe acesso a um aplicativo em funcionamento e se comporta como um usuario persistente: inspeciona as telas, mapeia as acoes disponiveis, executa verificacoes em paralelo e documenta os problemas encontrados. Para isso, ele nao precisa do codigo-fonte.

Em um benchmark publicado pela empresa, o Mo encontrou 269 bugs confirmados em 60 minutos. O Codex com Playwright MCP detectou 86, o Claude Code encontrou 59 e o Devin, 27. Parece impressionante, mas a principal conclusao nao e que “um agente venceu os demais”. O ponto mais interessante e outro: os testes estao gradualmente se desvinculando de cenarios escritos de antemao e se transformando em uma exploracao autonoma do produto.

Como o agente encontra o que nao esta no caso de teste

Imagine um servico de entregas. Depois de mais uma atualizacao, os testes convencionais verificam o login, a busca por restaurantes e a realizacao do pedido. Tudo esta verde. No entanto, ao voltar da janela de pagamento, o endereco selecionado e subitamente redefinido. A equipe nao previu esse caminho e, portanto, nao ha um teste para ele.

Primeiro, o Mo cria um grafo do aplicativo: quais telas estao disponiveis e quais acoes as conectam. Ele distribui grandes secoes entre agentes separados. Um explora a autenticacao, outro o carrinho e um terceiro o pagamento. Componentes especializados analisam a imagem da tela, localizam os elementos necessarios da interface e acompanham as mudancas de estado.

Para impedir que verificacoes paralelas corrompam os dados umas das outras, os agentes reservam recursos compartilhados. Varios processos podem ler o mesmo objeto simultaneamente, mas apenas um tem permissao para modifica-lo. Isso e importante em cenarios com uma conta compartilhada, pedidos e registros de teste no banco de dados.

Essa abordagem nao exige definir rigidamente um XPath, o texto de um botao ou um atributo aria especifico para cada acao. O agente recebe um objetivo em linguagem natural e descobre sozinho como cumpri-lo. Quando o layout muda, isso pode tornar as verificacoes menos frageis, embora nao elimine por completo o problema dos testes instaveis.

Os numeros parecem fortes, mas este e um benchmark do fornecedor

O conjunto incluiu 1.396 bugs rotulados em quatro aplicativos de codigo aberto: Gitea, Metabase, Twenty e Saleor. Em uma hora, o Mo alcancou recall de 19,3%, com precisao de 84%. O Codex obteve recall de 6,2%, mas sua precisao foi ligeiramente maior: 86%.

Em outras palavras, o Mo encontrou um numero significativamente maior de defeitos conhecidos, mas seus relatos continham um pouco mais de falsos positivos. Tambem ha uma diferenca de custo: cada bug confirmado custou $2,67 com o Mo, contra $0,80 com o Codex. Com base nesses dados, o Mo e mais eficiente para uma exploracao ampla do produto, enquanto o Codex parece mais economico para um orcamento limitado.

Os resultados devem ser tratados com cautela. A Momentic preparou o benchmark, o conjunto de condicoes e o sistema de avaliacao. Um modelo de linguagem realizou a verificacao inicial, e depois uma pessoa revisou os resultados. A empresa disponibilizou o conjunto de dados e o ambiente de testes, portanto o experimento pode ser reproduzido, mas os numeros apresentados ainda nao substituem uma comparacao independente no produto da propria equipe.

O que a equipe deve fazer agora

Nao e necessario abandonar o Playwright ou o Selenium. Testes baseados em cenarios continuam sendo uteis para caminhos criticos e previsiveis: login, pagamento, concessao de permissoes e persistencia de dados. A exploracao por agentes faz mais sentido como uma segunda camada, voltada a encontrar problemas desconhecidos.

Um piloto pratico e simples: executar o agente no preview de cada pull request importante, limitar seu tempo e orcamento e confirmar manualmente os defeitos encontrados. Depois, comparar quantos bugs unicos ele detectou, quantos relatos eram falsos e quantas horas de QA manual foram economizadas.

Se o agente encontrar de forma consistente falhas que os testes existentes nao detectam, ele podera ser incorporado ao processo de release. Se apenas repetir verificacoes ja conhecidas e gerar ruido, os numeros impressionantes do benchmark de outra empresa nao trarao nenhum valor para a equipe.