Novo benchmark da Alibaba: agentes de IA cumprem parte dos requisitos, mas não a tarefa inteira

A Alibaba, junto com a Universidade Chinesa de Hong Kong, a Universidade Jiao Tong de Xangai e a Universidade Tecnológica de Nanyang, apresentou o Co-Design Bench. Trata-se de um conjunto de tarefas para agentes de IA que escrevem código. Os modelos são avaliados naquilo que os usuários realmente pedem: pegar um aplicativo web que já funciona e alterá-lo conforme uma descrição, às vezes com captura de tela, gravação de voz, vídeo ou documento. O resultado para os dez modelos testados é este: o melhor deles cumpre uma parcela considerável dos requisitos, em média por tarefa, mas resolve por completo apenas uma fração menor das tarefas. Ele executa itens isolados, mas não consegue juntar tudo.

Tarefas de sessões reais, e não de dados sintéticos

Muitos testes para agentes de programação são construídos de forma artificial: quebram uma página de referência e pedem o conserto, ou entregam um conjunto predefinido de edições. Os autores do Co-Design Bench seguiram outro caminho. Eles coletaram pedidos de sessões reais de usuários, removeram duplicatas e mantiveram aqueles que têm algo a ser verificado. Para cada tarefa, reconstruíram o aplicativo executável "antes da edição", além do histórico da sessão e dos anexos.

O teste tem dois trilhos:

• Multimodal Editing (ME) — edições locais: aparência, estrutura, conteúdo. O agente recebe a página, uma área selecionada e um pedido, às vezes com imagem, áudio, vídeo ou documento. Exemplo: um recibo traz um valor, e é preciso atualizá-lo de forma consistente na tabela e nos resumos finais. • Repository Editing (RE) — mudanças coordenadas em um repositório de front-end: componentes, rotas, estado, fluxo de dados. Exemplo: um editor de clipes de vídeo esportivo, em que é preciso limitar o número e a duração dos clipes, alinhar a linha do tempo ao mudar a escala e reativar a inserção depois de excluir ou dividir um clipe.

As tarefas são avaliadas em três eixos: compreensão do contexto (Grounded Understanding), transformação da interface (UI Transformation) e implementação de funcionalidades (Functional Implementation).

Antes de entrar no conjunto, o aplicativo precisa ser compilado, executado em contêiner e renderizado no Playwright (ferramenta de automação de navegador). Tarefas que dependem de serviços externos indisponíveis foram excluídas. Os pedidos foram ordenados por complexidade, verificabilidade e sinais de fracassos anteriores, como reformulações e reversões. Em seguida, especialistas deixaram os pedidos com redação clara e escreveram critérios de aceitação ocultos.

Como verificar sem código de referência

A tarefa não tem solução de referência, porque uma mesma edição pode ser feita de várias maneiras. Por isso, os critérios descrevem o resultado: o que deve aparecer e como deve se comportar. Eles não ditam a implementação. A comparação com o aplicativo original ajuda a entender o que mudou e o que precisava ser preservado.

A verificação tem várias etapas:

• Primeiro, um agente avaliador examina o aplicativo final: a diferença no código-fonte, as páginas renderizadas e as ações gravadas no navegador. Um manipulador no código não prova nada se o usuário não consegue chegar até ele pela interface. • Depois, um verificador LLM independente recebe os veredictos e as evidências coletadas e tenta refutá-los. Ele procura stubs, respostas fixadas no código, pontos de entrada inalcançáveis, falhas com outros dados de entrada e divergências em relação ao pedido. • Uma auditoria obrigatória exige renderização bem-sucedida e capturas de tela para afirmações visuais, além de logs de ações no navegador para as interativas. Sem evidências, a avaliação é interrompida antes mesmo da contagem de pontos.

Todos os veredictos e logs são armazenados, então qualquer nota pode ser rastreada até as provas. Dois especialistas em front-end também revisaram manualmente parte das avaliações. Os autores reconhecem com franqueza que isso não elimina por completo os erros dos juízes.

O que os dez modelos mostraram

Dez endpoints de modelos passaram por uma estrutura agêntica comum: o agente pode ler o código, editar arquivos, compilar e executar o aplicativo. Dos resultados saem algumas conclusões.

• A proporção de critérios cumpridos e a de tarefas totalmente resolvidas divergem de forma notável. O usuário que teve a maior parte do pedido implementada ainda fica com um fluxo que não funciona. • O ranking dos modelos muda de um trilho para outro: o melhor em edições locais não é necessariamente o melhor em edições de repositório. • Nos dez modelos, a completude da execução é pior em tarefas de repositório com três ou quatro tipos de mudança (estrutura, estilo, interatividade, conteúdo) do que em tarefas com um ou dois.

Os autores também mostraram que o modo de operação altera a avaliação. Nas tarefas do WebCompass-edit, passar de uma única tentativa para o modo agêntico com ferramentas elevou de forma notável a proporção média de funcionalidades cumpridas, embora a rubrica, o juiz e a renderização tenham permanecido os mesmos. Isso significa que números de testes com modos diferentes não podem ser comparados diretamente.

Os autores comparam o Co-Design Bench com outros benchmarks. Design2Code, WebSight-Test e WebRenderBench verificam a conversão de captura de tela em código. O IWR-Bench acrescenta vídeo de interação. WebGen-Bench e FrontendBench testam sites criados do zero. DesignBench, MT-Web2Code, WebCompass e FronTalk tratam de edições e diálogo. SWE-bench, SWE-bench Multimodal e SWE-Lancer usam tarefas do GitHub e de freelancers. A novidade do Co-Design Bench está na combinação de sessões reais, anexos multimodais, estado inicial executável, verificação sem referência e um verificador adversarial.

Para equipes que adotam agentes de programação, a conclusão é prática. A métrica de "porcentagem de itens cumpridos" superestima a prontidão: é mais importante contar a proporção de tarefas resolvidas por completo e olhar separadamente para edições complexas e compostas. Para verificar código gerado por IA, vale exigir evidências como capturas de tela e gravações de ações no navegador. O código no diff não prova que a função funciona.