Resumo Técnico: VISTA – Um Benchmark End-to-End para Agentes de Codificação de Aplicativos Web a partir de Especificações Visuais

Declaração do Problema

Enquanto os Modelos de Linguagem de Grande Escala (LLMs) demonstraram proficiência em tarefas de codificação isoladas (por exemplo, síntese de funções, correção de bugs), sua capacidade de atuar como agentes autônomos no desenvolvimento completo de aplicativos web permanece subavaliada. Benchmarks existentes frequentemente focam em problemas algorítmicos ou na reconstrução estática de design para código, falhando em capturar a complexidade dos fluxos de trabalho modernos de front-end. Especificamente, as avaliações atuais sofrem com quatro lacunas de design:

1. Conflação de Stack: Muitos benchmarks padronizam a pilha de implementação, confundindo a capacidade do modelo com a adequação da stack.
2. Homogeneidade de Entrada: As tarefas normalmente fixam uma única modalidade de entrada (texto, captura de tela ou arquivo de design), ignorando o espectro de fidelidade visual/estrutural disponível em especificações do mundo real.
3. Avaliação Desacoplada: As avaliações frequentemente separam o LLM do mecanismo de execução, ignorando como as interfaces agente-computador impactam materialmente o desempenho.
4. Instabilidade de Avaliação: A dependência de LLMs como juízes ou avaliadores baseados em agentes de navegador introduz sensibilidade à formulação de prompts e falhas de fundamentação, particularmente para tarefas de interface onde controles não rotulados podem alterar os resultados.

O VISTA aborda essas lacunas estabelecendo um benchmark rigoroso para avaliar agentes baseados em LLMs que devem gerar aplicativos web funcionais e visualmente coerentes a partir de entradas subespecificadas.

Metodologia

Construção do Benchmark

O VISTA define um conjunto de tarefas abrangendo 10 categorias de aplicativos (por exemplo, comércio eletrônico, reserva de viagens, chat) e 128 páginas. A verdade fundamental é derivada de designs do Figma, exportados como PNGs renderizados e estruturas JSON podadas para evitar contaminação a partir de crawlers web existentes.

Condições de Prompt-Informação:
O benchmark avalia agentes em cinco condições (C0–C4) que variam ao longo de dois eixos: fidelidade visual/estrutural e restrição de stack.

• C0: Apenas prompt de texto; o agente escolhe a stack livremente.
• C1: Texto + capturas de tela; o agente resolve a tarefa sob três stacks especificadas (média).
• C2: Texto + capturas de tela; o agente escolhe a stack livremente.
• C3: Texto + capturas de tela + JSON podado do Figma; o agente usa uma única stack especificada (modelo fornecido).
• C4: Texto + capturas de tela + JSON podado do Figma; o agente escolhe a stack livremente.

Anotação Humana:
Para superar as limitações dos testes automatizados em geração aberta, os autores anotaram manualmente 3.253 componentes interativos (botões, links, entradas) e 458 pontos de ancoragem visual em todo o conjunto de dados. Isso permite uma avaliação precisa e determinística, em vez de depender de fundamentação visual instável.

Métricas de Avaliação

O framework de avaliação combina três sinais complementares:

1. Pontuação Estrutura-Função Fundamentada no DOM ($S$): Uma métrica conjunta que mede o alinhamento estrutural e a correção comportamental.
   • Localização ($L_i$): Verifica se os alvos interativos existem como elementos DOM reais próximos às coordenadas de referência usando alinhamento afim e níveis de distância IoU/centro.
   • Comportamento ($B_i$): Executa verificações específicas (navegação, alternância de estado, tratamento de entrada) nos elementos correspondentes.
   • Fórmula: $S = \frac{1}{N} \sum L_i \cdot B_i$.
2. Fidelidade Visual: Utiliza similaridade de imagem baseada em CLIP para medir a semelhança visual de alto nível entre o aplicativo gerado e a verdade fundamental do Figma, interpretada juntamente com as pontuações estruturais.
3. Eficiência do Agente e Trajetória: Analisa trajetórias de ação (inspecionar, escrever, verificar, falhar) e define uma Pontuação de Diferença Cirúrgica. Esta métrica quantifica a proporção do trabalho de edição entregue via patches localizados versus reescritas de arquivo completo, distinguindo entre fluxos de trabalho "cirúrgicos" e "pesados em reescrita".

Configuração Experimental

O benchmark avaliou quatro sistemas de agentes de duas famílias de modelos (GPT-5.4, GPT-5.5) e dois mecanismos (Codex orientado a patches; Claude Code com ferramentas Write/Edit/MultiEdit).

Principais Resultados

Impacto das Condições de Entrada

• Liberdade de Stack é Crítica: O desempenho mais alto (Pontuação Combinada) foi alcançado sob condições de stack livre (C2 e C4). Embora adicionar entradas visuais (capturas de tela, JSON do Figma) tenha melhorado as pontuações de localização, fixar a stack (C1, C3) frequentemente reduziu a correção funcional, sugerindo que os agentes lutam para compor comportamentos corretos sobre andaimes rígidos.
• Desacoplamento Visual vs. Funcional: A fidelidade visual (CLIP) e a correção funcional (Comportamento) estão parcialmente desacopladas. Por exemplo, o GPT-5.5 alcançou a maior localização (0,602) e pontuações CLIP (0,853), mas a menor pontuação de comportamento (0,283), indicando que reproduz bem a estrutura visual, mas falha em implementar interações corretas. Por outro lado, o Claude Opus alcançou a maior correção funcional (0,336) e pontuação combinada (0,261), apesar de pontuações de similaridade visual mais baixas.

Análise do Estilo de Edição

• Ortogonalidade de Estilo e Qualidade: A Pontuação de Diferença Cirúrgica (medindo edição localizada) mostrou uma correlação negativa fraca ($\rho = -0,145$) com o sucesso da tarefa.
• Estratégias Específicas do Modelo:
  • Claude Opus: Alcançou a melhor qualidade de tarefa, mas dependeu fortemente de reescritas de arquivo completo (98,8% de participação em reescrita), indicando uma estratégia de "gerar e substituir".
  • GPT-5.5: Apresentou a maior Pontuação de Diferença Cirúrgica (33,6), mas a menor qualidade de tarefa, sugerindo que um estilo de edição "cirúrgico" não garante melhores resultados.
• Padrões de Fluxo de Trabalho: A análise de trajetória revelou que os modelos da família Claude exibem transições mais fortes de "inspecionar $\to$ inspecionar" e "falhar $\to$ inspecionar" (loops diagnósticos), enquanto os modelos da família GPT mostram transições mais dispersas após falhas.

Significado e Alegações

O artigo posiciona o VISTA como uma fundação para avançar a pesquisa em engenharia de software baseada em agentes ao:

1. Desacoplar Capacidades: Demonstrar que a reprodução visual e a correção funcional são capacidades distintas que devem ser avaliadas separadamente.
2. Validar o Acoplamento Agente-Mecanismo: Mostrar que a interação entre o modelo e o mecanismo de codificação (por exemplo, disponibilidade de ferramentas, affordances de edição) influencia significativamente tanto o estilo de edição quanto a qualidade final da tarefa.
3. Fornecer Avaliação Robusta: Oferecer um pipeline de avaliação reproduzível e anotado por humanos que mitiga a instabilidade de LLMs como juízes e testes baseados em scripts na geração aberta de interfaces.

Os autores concluem que, embora entradas estruturais mais ricas (JSON do Figma) melhorem a fundamentação, elas não melhoram automaticamente a qualidade funcional, a menos que sejam acompanhadas pela flexibilidade de escolher ou adaptar a stack de implementação. Além disso, o estilo de edição de um agente (cirúrgico versus pesado em reescrita) é amplamente ortogonal ao seu sucesso na tarefa, sugerindo que as métricas de avaliação atuais devem focar na utilidade do aplicativo final, em vez da eficiência do processo de edição.