Android Bench 2: progresso parcial não é critério de entrega de aplicativo

O Google ampliou o Android Bench para a versão 2.0, com tarefas de longo horizonte, avaliação com agentes e pontuação contínua.[17] A avaliação inclui atualização de dependências, funcionalidades, construção de aplicativos e conversão de aplicações multiplataforma para Android.[17] A mudança permite enxergar progresso parcial, mas não deve ser usada para chamar uma aplicação incompleta de entregue.

O que muda para quem desenvolve

A taxa de conclusão combina funcionalidade, fidelidade visual e ausência de regressões, com penalidades para violações de instruções e restrições estruturais.[17] No recorte apresentado, a conversão de aplicativos multiplataforma chega a 80% de conclusão para o melhor modelo citado.[17]

Já a aprovação integral de tarefas longas aparece com 32% para Claude Opus 5.5 e 28% para GPT-6 Astra.[17] São métricas diferentes. Minha leitura é que a primeira ajuda a localizar o trabalho restante; a segunda responde se os critérios de aceitação foram todos atendidos. Nenhuma deveria substituir silenciosamente a outra.

A avaliação começa com agentes dos próprios fornecedores de modelos.[17] Portanto, o resultado descreve uma combinação de modelo, ferramentas e processo, não apenas os pesos isolados. Ao comparar opções no seu projeto, mantenha essa unidade de análise.

A matéria relata resultados melhores em código novo do que em refatoração e dificuldades em mudanças incompatíveis e problemas que exigem validação em runtime.[17] Use isso como hipótese para planejar testes, não como desculpa antecipada para aceitar uma migração sem funcionar.

Como aplicar

Escolha uma tarefa realista, delimite a revisão inicial e escreva critérios de aceitação antes de acionar o agente. Inclua build, jornada principal, navegação, permissões, comportamento sem conectividade quando exigido e ausência de regressões conhecidas.

Separe o relatório em duas partes. Na primeira, marque cada requisito como atendido, não atendido ou não verificado. Na segunda, determine se a tarefa pode ser aceita integralmente. Um requisito não verificado deve permanecer visível, não virar aprovação por falta de evidência.

Proponha um teste de comparação entre agentes usando a mesma base, a mesma tarefa e as mesmas verificações. Registre também intervenções humanas e tempo necessário para reparar o resultado. Isso permite avaliar o trabalho que a ferramenta realmente poupou, em vez de premiar apenas a quantidade de código produzida.

Para uma mudança de dependências, execute a aplicação e confira os fluxos afetados. Para uma interface nova, compare requisitos visuais e interação. Não aplique uma única métrica a tarefas que pedem evidências diferentes.

Cuidados e limites

Os rankings são um retrato da publicação, não uma garantia permanente de liderança.[17] Tampouco uma taxa alta de conclusão de partes comprova confiabilidade de entrega integral.

O trade-off da pontuação contínua é dar mais informação sobre progresso e exigir disciplina para não confundi-la com aceite. Minha recomendação é usar agentes para avançar uma tarefa e usar evidências independentes para encerrá-la. Um aplicativo que compila, mas não atende um requisito essencial, continua com trabalho pendente.

Fonte

[17] Fonte: InfoQ