Vibe Code Bench: Evaluating AI Models on End-to-End Web Application Development

Este artigo apresenta o "Vibe Code Bench", um novo benchmark que avalia a capacidade de 16 modelos de IA de desenvolver aplicações web completas do zero, revelando que, apesar dos avanços, a geração confiável de software end-to-end ainda é um desafio significativo e depende criticamente de estratégias como auto-teste e de protocolos rigorosos de avaliação humana.

O essencial

Imagine que você tem uma ideia brilhante para um aplicativo: um site para organizar festas de aniversário, um sistema para gerenciar uma pequena loja ou um diário de hábitos. Antigamente, para tirar essa ideia do papel, você precisava contratar um programador, gastar meses e muito dinheiro.

Hoje, a Inteligência Artificial promete fazer isso sozinha. Mas será que ela realmente consegue? É aí que entra o "Vibe Code Bench", o "teste de direção" criado pelos autores deste artigo.

Aqui está a explicação do que eles fizeram, usando analogias do dia a dia:

1. O Problema: O "Teste de Matemática" vs. "Construir uma Casa"

Até agora, os testes de IA para programação eram como pedir para a IA resolver uma equação de matemática isolada (ex: "calcule 2+2"). A IA é ótima nisso.

• A realidade: Construir um software real não é só resolver uma conta. É como construir uma casa do zero. Você precisa da fundação, das paredes, da eletricidade, do encanamento, e depois garantir que a porta abre, a luz acende e o chuveiro funciona.
• O buraco: Ninguém tinha um teste que pedisse para a IA: "Aqui está o projeto da casa, construa-a inteira, do alicerce ao telhado, e me mostre que você pode morar nela".

2. A Solução: O "Vibe Code Bench" (O Grande Desafio)

Os autores criaram um "campo de provas" com 100 desafios.

• O Cenário: Eles deram para 16 das IAs mais inteligentes do mundo (como GPT-5, Claude Opus, Gemini) uma descrição simples em linguagem natural (ex: "Quero um app para dividir contas de restaurante entre amigos").
• A Regra de Ouro: A IA não pode apenas escrever código solto. Ela tem que:
  1. Criar o código.
  2. Instalar as ferramentas necessárias.
  3. Conectar bancos de dados.
  4. Testar o próprio trabalho (como um encanador que testa se não há vazamentos antes de entregar a obra).
  5. Entregar um aplicativo que funcione de verdade no navegador.

3. O Juiz: O "Robô Visitante"

Como saber se o aplicativo funciona? Eles não olharam o código (que pode ser bonito mas quebrado). Eles usaram um agente autônomo no navegador (um robô virtual).

• A Analogia: Imagine que você contrata um pedreiro. Em vez de ler o plano dele, você manda um inspetor (o robô) entrar na casa, tentar abrir a porta, ligar a luz, abrir a torneira e ver se o chuveiro joga água.
• Se o robô consegue fazer tudo o que o usuário faria (clicar, digitar, comprar algo, fazer login), o aplicativo passa no teste.

4. O Resultado: Ainda é um "Estagiário"

O resultado foi revelador e um pouco decepcionante, mas honesto:

• A Melhor IA (GPT-5.3-Codex): Conseguiu construir aplicativos que funcionavam perfeitamente em apenas 61,8% dos casos.
• O que isso significa? Se você pedisse para 10 IAs construírem um app, 4 delas provavelmente entregariam algo quebrado, que não abre ou que não salva os dados.
• A Lição: A IA é ótima em escrever pedaços de código, mas ainda falha em gerenciar o projeto inteiro do início ao fim.

5. O Segredo do Sucesso: "Auto-Teste"

Os autores descobriram algo crucial:

• As IAs que tinham mais sucesso eram aquelas que paravam para testar o próprio trabalho enquanto construíam.
• Analogia: É a diferença entre um aluno que escreve a redação e entrega imediatamente, e um aluno que escreve, relê, corrige erros de português, verifica se o tema foi atendido e só depois entrega. As IAs que "pensavam e testavam" (usavam o navegador para ver se o app funcionava) foram muito melhores.

6. O Perigo dos "Juízes"

O estudo também mostrou que quem avalia importa muito.

• Se você pedir para uma IA avaliar o trabalho de outra, elas podem concordar ou discordar totalmente, dependendo de qual IA você escolheu como juiz.
• Foi como ter três professores avaliando a mesma redação: um dá nota 10, outro dá nota 4. Isso mostra que precisamos de cuidado ao confiar apenas em testes automáticos.

Resumo Final

O "Vibe Code Bench" nos diz que a IA já não é apenas uma "máquina de escrever código". Ela está começando a ser uma "engenheira de software".

• Onde ela está: Consegue fazer 60% do trabalho sozinha, mas ainda precisa de supervisão humana para os 40% restantes (especialmente em tarefas complexas).
• O futuro: O objetivo não é mais saber se a IA sabe programar, mas se ela consegue entregar um produto final que funcione. Estamos perto, mas ainda não chegamos lá.

Em suma: A IA já sabe escrever as peças do quebra-cabeça, mas ainda está aprendendo a montar a imagem completa sem deixar peças faltando ou de cabeça para baixo.

Resumo técnico

Resumo Técnico: Vibe Code Bench

1. Problema e Motivação

O campo de geração de código por IA avançou significativamente em tarefas isoladas (como síntese de funções ou resolução de bugs em repositórios existentes). No entanto, existe uma lacuna crítica na avaliação da capacidade dos modelos de realizar o processo completo de "zero a um": criar uma aplicação web funcional e implantável a partir de uma especificação em linguagem natural.

Os benchmarks existentes (como HumanEval, SWE-Bench) focam em:

• Geração de funções isoladas.
• Correção de bugs em código existente.
• Tarefas de escopo limitado.

Nenhum deles avalia a construção de uma aplicação completa que envolva múltiplos arquivos, configuração, implantação, integração de serviços externos e fluxos de trabalho de usuário reais. O objetivo do Vibe Code Bench (VCB) é preencher essa lacuna, testando se os modelos podem atuar como desenvolvedores autônomos completos, permitindo que usuários não técnicos construam software de ponta a ponta.

2. Metodologia e Design do Benchmark

2.1. Estrutura do Dataset

O VCB consiste em 100 especificações de aplicações web realistas, divididas em:

• Conjunto de Validação (Público): 50 tarefas.
• Conjunto de Teste (Held-out): 50 tarefas.

As especificações cobrem três domínios principais:

1. Individual (24 apps): Ferramentas pessoais (ex: rastreador de hábitos), geralmente sem autenticação complexa.
2. Fundador Solo (45 apps): Aplicações para iniciar um negócio (ex: reserva de estacionamento), frequentemente com autenticação por e-mail.
3. Ferramenta Empresarial (31 apps): Sistemas internos com hierarquia de funções e aprovações.

2.2. Fluxo de Trabalho e Avaliação

Cada tarefa é acompanhada por 964 fluxos de trabalho automatizados baseados em navegador, totalizando 10.131 sub-etapas.

• Geração: Os modelos operam em um ambiente de desenvolvimento isolado (baseado no OpenHands), com acesso a terminal, navegador e serviços de produção (Supabase, MailHog, Stripe).
• Restrições: O tempo máximo é de 5 horas por aplicação. O stack tecnológico é padronizado (React + Vite, Tailwind, Supabase) para garantir comparabilidade.
• Integrações: 28% das tarefas exigem integração com serviços externos (e-mail e/ou Stripe), aumentando a complexidade além de simples CRUDs.

2.3. Pipeline de Avaliação Automatizada

A avaliação não utiliza testes unitários ou verificações de DOM frágeis. Em vez disso, emprega um agente autônomo de navegador (usando Browser Use) que:

1. Implanta a aplicação via Docker Compose.
2. Navega pela interface do usuário como um humano faria (clicar, preencher, navegar).
3. Executa sub-etapas específicas definidas nos fluxos de trabalho.
4. Critério de Sucesso: Um fluxo de trabalho é considerado aprovado se ≥90% de suas sub-etapas forem concluídas com sucesso. A precisão final é a porcentagem de fluxos aprovados por aplicação.

3. Principais Contribuições

1. Novo Benchmark e Pipeline: O primeiro dataset focado exclusivamente na geração de aplicações web completas ("zero-to-one") com avaliação baseada em comportamento do usuário final via navegador.
2. Avaliação Abrangente de Modelos: Teste de 16 modelos de ponta (incluindo GPT-5, Claude Opus/Sonnet, Gemini, Qwen, etc.), fornecendo análises de custo, latência e taxas de erro.
3. Protocolo de Alinhamento de Avaliadores: Um estudo detalhado sobre como a escolha do modelo avaliador impacta os resultados, incluindo validação cruzada com anotação humana.
4. Análise de Comportamento Agêntico: Investigação sobre como o uso de ferramentas (especialmente o "auto-teste" via navegador) correlaciona-se com o sucesso.

4. Resultados Chave

4.1. Desempenho Geral

O desempenho na tarefa de desenvolvimento end-to-end permanece desafiador:

• O melhor modelo (GPT-5.3-Codex) atingiu 61,8% de precisão no conjunto de teste.
• Modelos de peso aberto (Open-weight) geralmente performaram pior (entre 1% e 24%), embora alguns como o GLM-5 tenham mostrado resultados notáveis em custo/latência, mas com baixa precisão.
• A diferença de desempenho entre os modelos é muito mais discriminativa no VCB do que em benchmarks tradicionais (ex: a diferença entre o melhor e o pior no VCB é de ~60 pontos, enquanto no SWE-Bench é de apenas ~2,8%).

4.2. Fatores de Desempenho e Comportamento

• Auto-Teste (Self-Testing): Há uma forte correlação positiva (Pearson r = 0,72) entre o uso da ferramenta de navegador durante o desenvolvimento (para testar a própria aplicação) e a precisão final. Modelos que iteram e testam mais tendem a ter mais sucesso.
• Volume de Edição vs. Qualidade: O volume de edições de código não é preditivo de sucesso (correlação fraca), indicando que a qualidade e a estratégia das edições importam mais que a quantidade.
• Dificuldade e Integrações: O desempenho cai drasticamente em tarefas "Difíceis" e aquelas que exigem integrações complexas (ex: Stripe + E-mail simultaneamente).

4.3. Análise de Erros

As falhas mais comuns não são de inicialização, mas de funcionalidade:

• Recursos Ausentes (46,7%): A aplicação não implementou uma funcionalidade especificada.
• Problemas de Autorização (20,4%): Falhas no login, registro ou controle de acesso.
• Bloqueios de Validação/Política (14,8%): Configurações incorretas de segurança (ex: RLS no Supabase) impedindo ações válidas.

4.4. Alinhamento Humano-AI

O estudo de alinhamento revelou que a escolha do avaliador é crítica:

• Alinhamento Humano-Humano: Alto (88,6% - 93,6%).
• Alinhamento Modelo-Humano: Variável. Modelos como Claude Sonnet 4.5 e Claude Sonnet 4.6 mostraram forte alinhamento com juízes humanos (86%), enquanto o GPT-5.2 teve um alinhamento muito baixo (36%).
• Conclusão: A seleção do modelo avaliador altera materialmente os resultados reportados, tornando-a uma preocupação de primeira ordem na avaliação de benchmarks.

5. Significado e Conclusão

O Vibe Code Bench demonstra que, embora a IA possa escrever código, a capacidade de construir software completo e confiável a partir de uma ideia em linguagem natural ainda é um desafio de fronteira.

• Limitações Atuais: Os modelos ainda falham frequentemente em integrações complexas e em manter a consistência de longo prazo em aplicações multi-arquivo.
• Direção Futura: A melhoria nos modelos não vem apenas de "adicionar mais código", mas de reduzir falhas catastróficas (aplicações que não iniciam) e adotar comportamentos de auto-verificação iterativa.
• Impacto: Este benchmark estabelece um novo padrão para medir o progresso rumo a agentes de IA capazes de substituir ou amplificar significativamente o trabalho de desenvolvimento de software, focando na entrega de valor funcional ao usuário final em vez de apenas na correção sintática do código.

O artigo fornece artefatos de reprodutibilidade, incluindo o dataset, o pipeline de avaliação e os prompts de sistema, permitindo que a comunidade científica e a indústria continuem a iterar sobre essa capacidade crítica.