Melhores agentes de IA passam em até 98% dos testes, mas entregam um produto funcional em no máximo 65% das builds

Imagine pedir a um agente de IA que crie um aplicativo de táxi. Primeiro ele faz a solicitação de corridas. Depois você pede multas por cancelamento, motoristas com vários carros, ganhos por corrida e pagamento dividido.

Cada nova função se apoia no código que o agente escreveu antes. Se ela quebra uma função antiga (por exemplo, se o cálculo de ganhos deixa de considerar as multas), o produto fica inutilizável, mesmo que quase todo o resto funcione. É assim que se faz hoje o "vibe coding" na plataforma Replit.

Já os benchmarks tradicionais verificam apenas uma tarefa bem definida, e muitos deles estão quase esgotados. Por isso a Replit lançou o ViBench 2.0.

O resultado: os três melhores modelos passam em até 98% dos cenários de teste, mas entregam um produto totalmente funcional em no máximo 65% das builds. A fatia de builds totalmente funcionais de primeira é chamada de pass@1. Se você constrói um produto com um agente, é ela que deve acompanhar.

Como o teste funciona

O agente começa de um projeto vazio e recebe os requisitos uma função por vez, em um único diálogo longo. Cada produto tem de 9 a 18 pedidos, o diálogo pode passar de 200 mil tokens, e cada etapa tem limite de 300 passos do agente e de duas horas. No total, o benchmark reúne 17 produtos web completos inspirados em Amazon, Asana, Discord, Figma, GitHub, Google Docs, Jira e Uber. Eles somam 241 pedidos de novas funções e 544 cenários de teste, sendo que 85% dos cenários verificam várias funções ao mesmo tempo.

Ninguém confere o resultado entre um pedido e outro. A nota é dada uma só vez, quando o produto está pronto, e quem dá é um agente de navegador: ele abre o aplicativo em um Chromium de verdade e age como um usuário. A build só é aprovada se todos os cenários do produto passarem, e cada produto tem de 26 a 41. A arquitetura é escolhida pelo próprio agente, então os testes avaliam o resultado, e não um design específico. Um rótulo "Waiting at stop" no lugar de "At Stop" não conta como erro.

Os autores também testaram o próprio verificador. Quando um cenário falha, ele o reavalia até quatro vezes, até que três avaliações coincidam. Ele pegou todos os 34 bugs inseridos de propósito e registrou apenas 0,8% de aprovações falsas. O verificador e a preparação dos dados de teste rodam no Opus 5.5.

A distância entre "quase" e "pronto"

Os autores testaram nove modelos. Os líderes, GPT-6.1 Sol, GPT-6 Astra e Opus 5.5, passam em até 98% dos cenários. Mas entregam um produto totalmente funcional em no máximo 65% das builds. A maioria das builds malsucedidas desses três falhou em apenas um ou dois cenários. O espaço para evolução está na confiabilidade, não na capacidade de fazer alguma coisa. Nenhum modelo aberto entregou, nem uma vez, um produto totalmente funcional.

A evolução, porém, é rápida. Em três lançamentos de uma mesma família de modelos, o pass@1 em produtos públicos subiu de 3% para 53%, e o custo de cada build caiu mais da metade. Isso vale também para outros benchmarks: no Vibe Code Bench, o melhor resultado subiu de 61,8% em março de 2026 para mais de 90% em seis modelos até o fim de outubro. Testes em que o agente faz uma única tarefa rapidamente chegam ao teto. A build longa, com verificação do produto pronto, ainda não chegou.

O que fazer com isso

O percentual médio de testes aprovados esconde o essencial: uma única função antiga quebrada torna a build inutilizável. Avalie os modelos pela fatia de builds impecáveis. Teste o produto inteiro, como um usuário faria, e não apenas etapas isoladas. A própria Replit usa o ViBench 2.0 para escolher os modelos da plataforma e avaliar mudanças em seu agente de produção.

Há ressalvas. A Replit é a autora do teste e também quem o utiliza. Mas a execução foi verificada por uma equipe externa, a Fireworks: ela subiu o benchmark publicado e rodou cada modelo com um único comando, sem ajustes. Oito produtos estão publicados no GitHub, junto com o executor e o verificador. Outros nove ficam ocultos, para que os modelos não sejam treinados no próprio teste. Os arquivos públicos levam uma linha especial de marcação, que permite filtrá-los dos dados de treinamento.