O problema nunca foi a IA errar uma correção de bug simples. O problema é que, durante anos, a indústria inteira mediu “inteligência de programação” com provas de múltipla escolha para crianças — e comemorou resultados acima de 90% como se isso significasse alguma coisa no mundo real. O Android Bench 2.0, anunciado pelo Google esta semana, joga essa régua fora. E, na minha experiência acompanhando benchmarks de IA desde o HumanEval, isso é o tipo de movimento que muda quem vence a próxima geração de modelos.
Segundo o Eurisko.com.br, o novo benchmark do Google foi desenhado para reproduzir o trabalho bruto de um engenheiro Android: tarefas que duram dias, exigem decisões intermediárias e não cabem num pull request de vinte linhas. É a primeira vez que um grande laboratório admite publicamente o que devs sêniores já desconfiavam — passar num teste fácil não quer dizer que o modelo sabe programar.
O que mudou de verdade entre o Android Bench 1.0 e o 2.0
O Android Bench original, lançado no início de 2025, era basicamente um SUITE de correções pontuais. Você entregava ao modelo um repositório, descrevia um bug ou uma feature pequena, e media se ele conseguia fazer a alteração mínima necessária. Nesse cenário, segundo a própria documentação, os modelos tops passavam de 90% das tarefas. Bonito no papel. Inútil na prática.
O 2.0 reescreve três regras do jogo:
- Duração realista: as tarefas são dimensionadas para consumir entre dois dias e uma semana de trabalho de um humano sênior. Não dá para resolver tudo em uma única chamada de LLM sem orquestração.
- Decisões encadeadas: cada etapa depende da anterior. Não existe mais “patch cirúrgico” — agora é fluxo de trabalho completo, com branches, refactorings intermediários e gerenciamento de dependências.
- Métrica revisada: o Google deixou claro que o simples “compila e roda” não basta. Os resultados passaram a considerar qualidade arquitetural, cobertura de testes legada e impacto em outras partes do sistema.
Quando li isso pela primeira vez, lembrei de um caso real que tive no início do ano. Pedi ao Claude para implementar uma tela de checkout em um app de e-commerce que já tinha cinco anos de código. Ele resolveu a feature em três minutos. Resultado: a tela renderizava, o checkout fechava, os testes novos passavam. Mas ele quebrou um cache de sessão que três squads usavam em produção. Levei dois dias para entender o estrago. O Android Bench 1.0 teria dado nota máxima para aquele modelo. O 2.0, com esperança, teria reprovado.
Por que benchmarks de programação sempre foram fracos
Quem programa há tempo sabe: existe um abismo entre resolver um exercício e entregar em produção. Os benchmarks clássicos — HumanEval, MBPP, até o famoso SWE-Bench — medem uma habilidade isolada que quase nunca corresponde ao trabalho diário. SWE-Bench, por exemplo, avalia se o modelo consegue gerar um patch que faz os testes do repositório passarem. Parece bom. O problema é que muitos dos patches passam nos testes mas introduzem más práticas, duplicação de lógica ou regressões silenciosas.
O WebArena, que avalia agentes web, sofre do mesmo mal: tarefas curtas, com ambiente controlado, longe do caos de um site real com caching, throttling de API e edge cases de CSS que fazem o layout explodir no Safari.
Quando o Google decide colocar tarefas de vários dias no centro da avaliação, ele está reconhecendo o óbvio: a unidade básica do trabalho de engenharia não é uma funçãozinha que retorna uma string. É um sistema inteiro, mantido por gente, com deuda técnica acumulada.
Comparando o Android Bench 2.0 com o que existe hoje
Vale colocar lado a lado os principais benchmarks que devs usam como referência em 2026, para entender onde o movimento do Google se encaixa:
| Benchmark | Foco | Duração típica da tarefa | Limite principal |
|---|---|---|---|
| HumanEval | Funções Python isoladas | Minutos | Não mede integração em sistemas |
| SWE-Bench Verified | Patches em repos reais do GitHub | Horas a 1 dia | Pode passar sem considerar arquitetura |
| WebArena | Tarefas web multi-etapa | Minutos a horas | Ambiente controlado, ignora edge cases reais |
| Android Bench 1.0 | Bugs/features incrementais Android | Horas | Tarefas curtas, fácil overfit |
| Android Bench 2.0 | Features completas Android | 2 a 7 dias | Recém-lançado, ainda sem massa crítica de comparação |
O detalhe mais importante: nenhum dos anteriores testa continuidade de trabalho. O Android Bench 2.0 exige que o modelo mantenha contexto arquitetural por dias, exatamente o que um agente de coding sério precisa fazer. Na minha visão, isso aproxima o benchmark do que seria um “estágio de engenharia real”, onde o estagiário tem que se virar sozinho com um JIRA grande no colo.
Na Prática: como devs devem interpretar esse novo benchmark
Pegar o resultado do Android Bench 2.0 e olhar só para o número final é o erro mais básico. O valor real está em três camadas. Vou listar o que eu faria se tivesse que avaliar uma IA programadora hoje.
- Olhar para tarefas longas individualmente. Procure os resultados separados por duração. Modelo que brilha em tarefas de 2 dias e quebra nas de 7 te diz que ele tem capacidade, mas falta memória e raciocínio sustentado.
- Verificar dependências encadeadas. Modelos com baixa performance em tarefas onde a etapa 4 depende de decisão tomada na etapa 1 vão te entregar código fragmentado. No dia a dia, isso vira PR com bug em produção.
- Comparar com fluxos multi-agente. Se você usa Claude Code, Cursor com Composer, GitHub Copilot Workspace ou o novo Jules do Google, rode a mesma feature nos três. Vários benchmarks recentes mostram que o “agent loop” dobra a performance em relação a um único prompt.
- Validar cobertura de testes legados. Essa é a parte que mais me interessou. O Android Bench 2.0 penaliza modelos que ignoram suítes de teste antigas. Isso bate de frente com o problema clássico de devs que adotam IA: o bot cria código novo, mas não roda o resto da suíte para garantir que nada quebrou.
Um snippet que mostra por que benchmarks simples mentem
Esse trecho apareceu num PR que recebi semana passada. Foi gerado por IA com base num prompt de “otimizar performance”. Compila, roda, e o Android Bench 1.0 daria nota máxima:
// "Otimização" gerada por IA — passa no build, falha no produto
class CheckoutViewModel(private val cartRepo: CartRepository) : ViewModel() {
private val _state = MutableStateFlow<CheckoutState>(CheckoutState.Idle)
val state = _state.asStateFlow()
fun loadCart() {
viewModelScope.launch {
// cache local — bom
val items = cartRepo.getCachedItems()
// chamada de rede em paralelo — vazou em prod
val shipping = async { api.fetchShipping() }
val coupon = async { api.fetchCoupons() }
// ❌ não trata timeout, não cancela async em cancelamento,
// ❌ ignora o estado de loading anterior
_state.value = CheckoutState.Ready(items, shipping.await(), coupon.await())
}
}
}Esse código parece decente para um benchmark isolado. Mas rodando em produção, ele quebra em três cenários reais: rotação de tela durante a chamada, perda de conectividade e concorrência entre loadCart() chamado duas vezes. Um benchmark sério, como promete ser o Android Bench 2.0, deveria detectar esse tipo de descuido. O 1.0 nunca detectaria.
Erros comuns que devs cometem ao usar IA para Android
Já revi código de mais gente do que consigo lembrar. Alguns padrões aparecem sempre que alguém delega demais para uma IA. Vale gravar esses pontos na parede.
- Confiar em benchmark como prova de competência. Ver modelo no topo do SWE-Bench não significa que ele vai sobreviver à sua codebase. Toda codebase tem regras não escritas — convenções de DI, padrões de erro, escolhas de state management — que não estão em nenhum teste padrão.
- Aceitar código que “só compila”. Código Kotlin em Android pode passar no compilador e ainda assim explodir em runtime. Foco no compilador é a pior heurística possível.
- Esquecer de auditar side effects. ViewModels geram StateFlows, escutam Flows, mantêm referências de contexto. Um pequeno “refactor” pode criar leak de memória que só aparece após horas de uso. O Android Bench 2.0 tenta capturar isso, mas no seu projeto é você quem precisa rodar o LeakCanary.
- Não validar com device real. Emulador mente. Testar em pixel real, com throttling de rede, com bateria baixa, com outro app em segundo plano — é isso que mostra onde a IA entrega código ruim.
- Tratar agente como estagiário brilhante. É mais perto de estagiário incansável que erra as mesmas coisas pela milésima vez. Sem revisão humana, você entrega lixo em escala industrial.
Implicações práticas: o que muda para quem programa Android em 2026
O Android Bench 2.0 vai mexer com três grupos diferentes. Primeiro, os laboratórios de IA: a corrida agora é por modelos que mantenham contexto longo e tomem decisões encadeadas. Isso favorece arquiteturas com janelas de contexto extensas e mecanismos explícitos de planejamento, tipo o o1-preview da OpenAI ou o Claude 3.7 Sonnet Extended Thinking.
Segundo, devs que usam IA no dia a dia: vão precisar ajustar suas expectativas. Ferramentas que pareciam mágicas em tarefas curtas vão mostrar suas costuras em fluxos longos. Cursor, GitHub Copilot e similares vão precisar evoluir para multi-step planning. Já estão evoluindo.
Terceiro, times de tech lead e engenharia: a decisão de adotar ou não IA em um projeto Android agora pode ser baseada em benchmark mais confiável. Antes, era achismo. Agora existe uma régua que mede o trabalho real.
Para fechar o raciocínio: o Google não está apenas publicando um benchmark melhor. Está sinalizando para o mercado o próximo gargalo. Se sua ferramenta favorita de IA não performar bem no Android Bench 2.0 daqui a seis meses, é hora de repensar a stack.
FAQ — Perguntas que devs reais vão fazer
O Android Bench 2.0 substitui o SWE-Bench?
Não. Os dois medem coisas diferentes. SWE-Bench continua sendo útil para medir patches pontuais em repositórios variados, com linguagens diferentes. O Android Bench 2.0 é específico para Android e focado em tarefas longas. Para um time Android, o 2.0 é mais relevante. Para um time poliglota, use os dois.
Modelos open source têm chance de ranquear bem no 2.0?
Depende da janela de contexto e da capacidade de planejamento. Modelos com reasoning explícito (tipo os variantes “thinking”) levam vantagem. Modelos pequenos, mesmo bem finos, vão sofrer nas tarefas de uma semana. A partir de 70B+ com bom tuning, dá para competir com modelos fechados de médio porte.
Posso rodar o Android Bench 2.0 nos meus próprios agentes?
O Google disponibilizou o framework, mas muitos datasets exigem autorização por envolverem apps proprietários. Para quem quer testar localmente em um subset, o ideal é começar com as amostras públicas e medir com critérios próprios alinhados ao seu fluxo.
Vale a pena trocar de ferramenta de IA agora ou esperar?
Se sua dependência de IA em Android for alta, aguardar os primeiros rankings públicos do Android Bench 2.0 antes de trocar é razoável. Seis meses é o que eu chuto para termos uma noção clara de quem lidera. Até lá, mantenha o que funciona e treine bons prompts de revisão.
O benchmark considera trabalho com Jetpack Compose e Kotlin Multiplatform?
A documentação oficial destaca tarefas típicas de apps Android modernos, incluindo arquitetura com Compose. Multiplatform ainda é citado como caso de teste futuro. Vale acompanhar atualizações trimestrais.
Se você chegou até aqui, é porque se importa em programar de verdade. Trabalhar com IA sem entender benchmark é igual trabalhar sem teste: vira evento de produção.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Se quiser, posso destrinchar o Android Bench 2.0 em um próximo post com os primeiros resultados oficiais.