HumanEval morreu: entender os benchmarks de código para LLMs em 2026

#Por que o HumanEval morreu

HumanEval é o benchmark de código mais citado na história dos LLM. Publicado pela OpenAI em 2021, foi referência por quatro anos. O problema: em 2026, ele está saturado. Os melhores modelos de código com pesos abertos obtêm nele entre 96 e 98% de « pass@1 », ou seja, resolvem quase todos os exercícios na primeira tentativa. Quando todos têm 20/20, a nota já não classifica ninguém.

Um benchmark saturado não mede mais o progresso: ele mede principalmente o ruído. Uma diferença entre 96% e 98% entre dois modelos pode se dever a três exercícios em cada cem, muitas vezes ambíguos ou mal formulados. Isso não é uma diferença de competência, é margem de erro. Continuar escolhendo um LLM de código com base em sua pontuação no HumanEval em 2026 é como decidir qual de dois corredores de longa distância é melhor usando uma corrida de velocidade de dez metros.

Não é que o HumanEval tenha se tornado ruim. É que os modelos ultrapassaram o que ele consegue medir. Ele continua útil como teste de regressão — um modelo que cai para 70 % tem um problema real — mas já não serve para diferenciar os melhores modelos.

#O que o HumanEval realmente mede

Entender por que o HumanEval chega à saturação exige ver o que ele testa concretamente. O benchmark contém 164 pequenos problemas de programação em Python. Cada um fornece uma assinatura de função e uma docstring que descreve o comportamento esperado; o modelo deve escrever o corpo da função, que é então validado por uma bateria de testes unitários ocultos.

Formato

164 funções Python independentes para completar, cada uma com sua docstring e seus testes unitários.

Natureza das tarefas

Algoritmos básicos: manipular listas, strings e fazer um pouco de matemática. Cada problema cabe em uma única função, sem dependências externas.

O que isso testa

A capacidade de traduzir uma especificação curta e sem ambiguidade em código correto. Um exercício escolar, não uma tarefa do mundo real.

O que isso NÃO testa

Navegar por um repositório existente, ler vários arquivos, entender código já escrito, corrigir um bug real, escrever testes, gerenciar dependências. Em outras palavras: o trabalho de verdade.

A diferença está aí. Escrever uma função isolada a partir de um enunciado claro é um exercício que os modelos de 2026 dominam. O trabalho real de um desenvolvedor — ou de um assistente de código local conectado ao seu editor — consiste em modificar um repositório existente com milhares de linhas. É isso que os novos benchmarks buscam medir.

#SWE-bench Verified explicado

SWE-bench é o benchmark que substituiu o HumanEval como referência séria. A ideia é radicalmente diferente: em vez de exercícios simplificados, ele parte de verdadeiras "issues" do GitHub tiradas de projetos Python open source populares (Django, scikit-learn, Flask, sympy...). O modelo recebe o repositório completo e o texto do bug a ser corrigido. Ele deve produzir um patch — um diff — que realmente resolva o problema.

A correção não é avaliada por um humano nem por outro modelo: o patch é aplicado ao repositório e, em seguida, a suíte de testes do projeto é executada. Se os testes que falhavam passam e os que passavam não quebram, o problema está resolvido. É um critério objetivo e próximo do trabalho real.

SWE-bench Verified

500 problemas validados manualmente. O padrão atual para comparar modelos na correção de bugs reais.

SWE-bench Lite

300 problemas mais simples e menos caros de avaliar. Útil para testar rapidamente, mas menos discriminante.

SWE-bench full

Mais de 2.000 problemas, alguns deles defeituosos. Pontuações mais baixas e com ruído; evitar para comparações.

As ordens de grandeza dizem muito sobre a dificuldade. Enquanto o HumanEval chega ao teto de 98%, os melhores modelos agênticos atingem 60 a 70% no SWE-bench Verified, e os bons modelos com pesos abertos que podem ser instalados localmente ficam, em geral, entre 40 e 55%. Finalmente há espaço para melhorar — e, portanto, para distinguir os modelos.

#LiveCodeBench e a contaminação

SWE-bench mede a correção de bugs em código real. LiveCodeBench responde a outro problema: a contaminação. Seu princípio está no nome — “live”. O benchmark coleta continuamente novos problemas de programação competitiva (LeetCode, AtCoder, Codeforces) e registra a data e a hora de cada um. Assim, é possível avaliar um modelo apenas com problemas publicados APÓS sua data de treinamento.

Isso é fundamental. Se um problema existia na internet antes do treinamento de um modelo, esse modelo talvez tenha visto a solução durante seu aprendizado. Sua pontuação não reflete então um raciocínio, mas uma memorização. Ao filtrar por data, o LiveCodeBench garante que o modelo resolva problemas que nunca poderia ter visto.

Natureza

Problemas de programação competitiva, com registro de data e hora, renovados continuamente.

Recorte temporal

Escolhemos um intervalo de datas posterior ao treinamento do modelo testado. Não há possibilidade de vazamento.

O que isso mede

Raciocínio algorítmico puro em problemas inéditos — próximo ao espírito do HumanEval, mas sem saturação nem contaminação.

Cuidados na leitura

Sempre verificar a janela de datas anunciada. Uma pontuação LiveCodeBench em uma janela anterior ao modelo não tem valor.

LiveCodeBench e SWE-bench são complementares, não concorrentes. O primeiro mede o raciocínio algorítmico em problemas novos; o segundo, a capacidade de atuar em um repositório real. Um bom LLM de código deve ter bom desempenho em ambos — um modelo forte em algoritmos, mas incapaz de navegar por um projeto, será um mau assistente no dia a dia.

#O problema da contaminação explicado de forma clara

A contaminação é A razão pela qual é preciso desconfiar das pontuações anunciadas. Os LLMs são treinados com enormes porções da web, incluindo o GitHub. Se os problemas de um benchmark e suas soluções estiverem disponíveis on-line, provavelmente acabarão nos dados de treinamento. O modelo não resolve mais o problema: ele o recita.

Um sinal de alerta: um modelo que supera todos os demais com folga em um benchmark antigo e estático, mas tem um desempenho comum em um benchmark « live » ou recém-publicado. A diferença entre os dois é uma boa medida da parcela da pontuação atribuível à memorização. É exatamente isso que o LiveCodeBench foi criado para revelar.

#Ler as pontuações de um modelo local

Quando você consulta a ficha de um modelo com pesos abertos (no Hugging Face ou no anúncio do fornecedor), as pontuações em programação quase sempre recebem destaque. Veja como interpretá-las para não ser enganado.

1. 01
   Identifique a versão exata do benchmark

   “SWE-bench” sozinho não significa nada. Procure “Verified”. Para o LiveCodeBench, procure a versão (v5, v6...) E a janela de datas. Sem essas especificações, o número não é comparável a outro.
2. 02
   Verifique o pass@k

   Os resultados em pass@1 e pass@10 nunca devem ser comparados diretamente. Os desenvolvedores às vezes divulgam o mais favorável dos dois. Na falta de informações precisas, presuma o pior para o seu uso real: o que importa no dia a dia é a primeira resposta.
3. 03
   Identifique o scaffolding para o SWE-bench

   Uma pontuação no SWE-bench é inseparável do agente que a produziu. '52% com OpenHands' não é '52% com Aider'. Se o fornecedor não especificar o agente, o número é pouco útil.
4. 04
   Desconfie das pontuações publicadas pelos próprios fornecedores

   Os números da ficha do modelo vêm do desenvolvedor, que tem interesse em causar uma boa impressão. Procure uma reprodução independente (ranking público, artigo de terceiros). Uma pontuação nunca reproduzida continua sendo uma alegação comercial.
5. 05
   Compare pelo menos dois benchmarks

   Um modelo forte em todos os testes é um bom sinal; um modelo que brilha em apenas um benchmark e desaparece nos outros sugere especialização — ou contaminação.

#Quais considerar para escolher seu LLM de código

Os benchmarks relevantes mudam conforme o que você espera do seu assistente local. Veja como priorizá-los de acordo com o uso.

Assistente agêntico (Aider, Cline, Continue)

SWE-bench Verified em primeiro lugar. É o benchmark mais próximo de "modificar meu repositório sozinho". É aí que se define a utilidade real de um agente.

Autocompletação e pequenas funções

LiveCodeBench e, em menor medida, HumanEval como verificação adicional. Para completar código à medida que você digita, o raciocínio algorítmico conta mais do que a navegação pelo projeto.

Geração de código do zero

LiveCodeBench (raciocínio em problemas inéditos) combinado com um benchmark que abranja várias linguagens de programação se você não programar apenas em Python — HumanEval e SWE-bench são muito centrados em Python.

Revisão de código e detecção de bugs

Menos bem coberto pelos benchmarks públicos. O SWE-bench continua sendo o melhor indicador indireto, mas, neste caso, é indispensável fazer um teste próprio com seus próprios diffs.

#Armadilhas a evitar

Comparar diferentes k

pass@1 versus pass@10: o erro mais comum. O segundo infla mecanicamente a pontuação. Sempre alinhar o k antes de concluir.

Esquecer a quantização

As pontuações publicadas são medidas com precisão total (BF16/FP16). Localmente, você rodará modelos em Q4_K_M ou Q5_K_M, com uma pequena perda de qualidade. Um modelo com pontuação de 50% no SWE-bench em FP16 ficará um nível abaixo depois de quantizado.

Confundir o benchmark com o objetivo final

Um modelo otimizado PARA passar em um benchmark («benchmark hacking») pode decepcionar ao trabalhar com código real. A pontuação é um indicativo, não uma garantia.

Ignorar a data do benchmark

Uma pontuação no LiveCodeBench referente a uma janela anterior ao treinamento do modelo provavelmente está contaminada. Sempre verificar se a janela é posterior.

Confundir modelo e agente

“Este modelo alcança 55% no SWE-bench” muitas vezes esconde “este modelo NESTE agente específico”. Troque de agente e o número muda.

#Para se aprofundar

Depois de entender como interpretar os benchmarks, o próximo passo lógico é escolher um modelo, instalá-lo e testá-lo no seu próprio código:

Melhor LLM local para codar em 2026

Nosso comparativo de modelos de código que podem ser hospedados por você (Devstral, Qwen3-Coder e alternativas), com as pontuações, a VRAM necessária e qual escolher de acordo com sua GPU.

Escolher sua quantização (Q4, Q5, Q8, FP16)

Para entender quanta qualidade um modelo perde ao passar para Q4_K_M — a diferença entre a pontuação anunciada e o que você realmente vai rodar.

Instalar Ollama (Windows, macOS, Linux)

O pré-requisito para testar um modelo de código localmente na porta 11434 e conectá-lo ao seu editor em poucos minutos.