Pular para o conteúdo
AI Benchmark · LEB

Uma IA consegue manter código legado sem quebrar nada?

O LEB — LLM Engineering Benchmark — entrega a um agente de IA um sistema legado em produção, com falhas plantadas e consumidores que dependem de como ele se comporta hoje. Ele mede o trabalho que domina a engenharia de verdade: achar as falhas, corrigi-las, manter todos os contratos intactos e explicar as decisões como um engenheiro sênior explicaria.

Por que mais um benchmark

A maioria dos benchmarks mede código escrito do zero, ou uma issue isolada resolvida. Nenhum dos dois é o que a engenharia é na maior parte do tempo: evoluir um sistema do qual outras pessoas já dependem. O LEB pontua segurança, arquitetura, bugs, performance, código limpo, compatibilidade e a qualidade da explicação — e tira pontos do agente que reescreve tudo, troca tecnologia sem necessidade ou quebra um contrato público.

Reescrever do zero não é engenharia. É fuga.

Como funciona um run

  1. 01

    Um sistema legado, com falhas plantadas

    O agente recebe o código, um manifesto da sua superfície pública — o contrato — e uma tarefa neutra: reportar os problemas, corrigir o que deve ser corrigido, manter a compatibilidade e justificar cada decisão. Ele nunca sabe quais falhas existem, quantas são nem onde estão.

  2. 02

    O agente trabalha sozinho

    No modo A ele tem ferramentas e um orçamento de turnos; no modo S, um prompt e uma resposta. Ele devolve o código alterado, um relatório técnico e um índice dos achados, cada um com uma confiança de 0 a 100.

  3. 03

    Máquinas conferem o código

    Testes de caracterização rodam no legado e na entrega: comportamento público que mudou é regressão. Depois, probes atacam cada falha corrigível — o payload de injeção, o conjunto vazio, o contador de queries — e dizem se ela ainda está lá.

  4. 04

    Um juiz confere o relatório

    Cada achado é comparado com a Matriz Oficial de Falhas, um gabarito oculto que também tem iscas: falhas plausíveis que não existem e custam pontos quando reportadas. Um segundo juiz avalia a explicação às cegas. Um montador determinístico transforma tudo em 0–1000.

1000 pontos, e como eles se perdem

Toda instância vale exatamente 1000: os pontos brutos de cada categoria são normalizados pelo seu peso, então as notas se comparam entre instâncias do mesmo nível.

Compatibilidade começa em 100 e só desce. Migrar de mysqli para PDO sem necessidade custa 20; mudar uma assinatura pública custa 30, por função.

Penalidades globais saem do total: bug novo −15, cada teste de caracterização quebrado −20, reescrita desnecessária −25, cada isca reportada −5.

  • Segurança SEC 250
  • Arquitetura ARCH 200
  • Bugs BUG 150
  • Performance PERF 150
  • Código limpo CLN 100
  • Compatibilidade COMP 100
  • Explicação EXPL 50

Selos

  • LEB Platinum 900–1000 · pronta para legado crítico
  • LEB Gold 750–899 · engenharia sólida
  • LEB Silver 600–749 · útil com supervisão
  • LEB Bronze 400–599 · requer revisão integral
  • Reprovada < 400 · risco ao sistema

Os runs acontecem longe do gabarito

Os agentes rodam numa VM Linux dedicada em que github.com e os hosts de conteúdo do GitHub resolvem para loopback, então um agente em teste não consegue abrir, clonar nem baixar o repositório do benchmark durante o run. O bloqueio é por nome: ele barra o acesso acidental e ingênuo, não um contorno deliberado, e não diz nada sobre o que um modelo viu no treinamento.

Resultados

Todas as entregas de uma tabela resolveram o mesmo pacote, byte a byte — o mesmo SHA-256 —, então os números se comparam em pé de igualdade.

LEB-100-A v1.1 · ai_benchmark.instances.LEB-100-A.name

ai_benchmark.instances.LEB-100-A.desc

modo A · 30 turnos edição 2026 avaliado em 2026-09-29 matriz 68088abdb7bc…
  1. 1
    Claude Sonnet 5.5 Anthropic · esforço xhigh 1 de 3 runs · não oficial
    825 de 1000 LEB Gold
    • Segurança 250/250
    • Arquitetura 50/200
    • Bugs 129/150
    • Performance 150/150
    • Código limpo 100/100
    • Compatibilidade 100/100
    • Explicação 46/50

    Penalidades: nenhuma Descoberta 79.2 Brier 0.022 Scorecard

  2. 2
    Claude Fable 5.1 Anthropic · esforço xhigh 1 de 3 runs · não oficial
    781 de 1000 LEB Gold
    • Segurança 211/250
    • Arquitetura 25/200
    • Bugs 150/150
    • Performance 150/150
    • Código limpo 100/100
    • Compatibilidade 100/100
    • Explicação 45/50

    Penalidades: nenhuma Descoberta 91.7 Brier 0.020 Scorecard

  3. 3
    Claude Opus 5.5 Anthropic · esforço xhigh 1 de 3 runs · não oficial
    711 de 1000 LEB Silver
    • Segurança 233/250
    • Arquitetura 50/200
    • Bugs 139/150
    • Performance 150/150
    • Código limpo 25/100
    • Compatibilidade 70/100
    • Explicação 44/50

    Penalidades: nenhuma Descoberta 91.7 Brier 0.073 Scorecard

  4. 4
    GPT-6-astra OpenAI · esforço xhigh 1 de 3 runs · não oficial
    661 de 1000 LEB Silver
    • Segurança 224/250
    • Arquitetura 0/200
    • Bugs 150/150
    • Performance 150/150
    • Código limpo 25/100
    • Compatibilidade 70/100
    • Explicação 42/50

    Penalidades: nenhuma Descoberta 87.5 Brier 0.000 Scorecard

  5. 5
    GPT-5.6-terra OpenAI · esforço xhigh 1 de 3 runs · não oficial
    625 de 1000 LEB Silver
    • Segurança 211/250
    • Arquitetura 0/200
    • Bugs 129/150
    • Performance 150/150
    • Código limpo 0/100
    • Compatibilidade 100/100
    • Explicação 35/50

    Penalidades: nenhuma Descoberta 45.8 Brier 0.000 Scorecard

  6. 6
    GPT-5.6-sol OpenAI · esforço xhigh 1 de 3 runs · não oficial
    612 de 1000 LEB Silver
    • Segurança 246/250
    • Arquitetura 0/200
    • Bugs 129/150
    • Performance 150/150
    • Código limpo 0/100
    • Compatibilidade 70/100
    • Explicação 32/50

    Penalidades: -15 Descoberta 70.8 Brier 0.001 Scorecard

  7. 7
    GPT-5.5 OpenAI · esforço xhigh 1 de 3 runs · não oficial
    601 de 1000 LEB Silver
    • Segurança 198/250
    • Arquitetura 0/200
    • Bugs 150/150
    • Performance 150/150
    • Código limpo 0/100
    • Compatibilidade 70/100
    • Explicação 33/50

    Penalidades: nenhuma Descoberta 70.8 Brier 0.006 Scorecard

  8. 8
    GPT-5.6-luna OpenAI · esforço xhigh 1 de 3 runs · não oficial
    599 de 1000 LEB Bronze
    • Segurança 207/250
    • Arquitetura 0/200
    • Bugs 139/150
    • Performance 150/150
    • Código limpo 0/100
    • Compatibilidade 70/100
    • Explicação 33/50

    Penalidades: nenhuma Descoberta 83.3 Brier 0.003 Scorecard

Falha por falha

O que cada agente achou e corrigiu entre as falhas plantadas. As difíceis são falhas por ausência — uma checagem de autorização que falta, uma sessão nunca regenerada, um arquivo deixado aberto no caminho de erro.

  • corrigida
  • achada, não corrigida
  • não achada
Falha Claude Sonnet 5.5 Claude Fable 5.1 Claude Opus 5.5 GPT-6-astra GPT-5.6-terra GPT-5.6-sol GPT-5.5 GPT-5.6-luna
SQL injection na busca SEC-001 · crítica · fácil 10/10 corrigida 10/10 corrigida 10/10 corrigida 10/10 corrigida 10/10 corrigida 10/10 corrigida 10/10 corrigida 10/10 corrigida
XSS refletido na busca SEC-003 · alta · fácil 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida
Injeção de fórmula no CSV exportado SEC-008 · média · difícil 6/6 corrigida 2/6 achada, não corrigida 2/6 achada, não corrigida 6/6 corrigida 0/6 não achada 6/6 corrigida 0/6 não achada 2/6 achada, não corrigida
Session fixation no login SEC-013 · alta · difícil 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 5/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida
Senhas em MD5 sem salt SEC-014 · alta · fácil 8/8 corrigida 8/8 corrigida 8/8 corrigida 3/8 achada, não corrigida 8/8 corrigida 8/8 corrigida 3/8 achada, não corrigida 3/8 achada, não corrigida
Segredos fixos na configuração SEC-015 · alta · fácil 8/8 corrigida 3/8 achada, não corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida
Qualquer chamado legível pelo id (IDOR) SEC-017 · crítica · difícil 10/10 corrigida 10/10 corrigida 10/10 corrigida 9/10 corrigida 10/10 corrigida 9/10 corrigida 9/10 corrigida 9/10 corrigida
Divisão por zero na média de SLA BUG-001 · alta · moderada 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida
Arquivo deixado aberto no caminho de erro BUG-004 · média · difícil 4/6 corrigida 6/6 corrigida 5/6 corrigida 6/6 corrigida 4/6 corrigida 4/6 corrigida 6/6 corrigida 5/6 corrigida
Uma query por chamado para o técnico (N+1) PERF-001 · alta · moderada 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida 8/8 corrigida
Um dispatcher que faz tudo ARCH-002 · alta · fácil 4/10 achada, não corrigida 2/10 achada, não corrigida 4/10 achada, não corrigida 0/10 não achada 0/10 não achada 0/10 não achada 0/10 não achada 0/10 não achada
Números mágicos para status e prioridade ARCH-009 · baixa · moderada 0/6 não achada 0/6 não achada 0/6 não achada 0/6 não achada 0/6 não achada 0/6 não achada 0/6 não achada 0/6 não achada
Quatro níveis de if aninhado CLN-007 · média · fácil 8/8 corrigida 8/8 corrigida 2/8 achada, não corrigida 2/8 achada, não corrigida 0/8 não achada 0/8 não achada 0/8 não achada 0/8 não achada

O que chamou atenção

  • Ninguém corrigiu a injeção de fórmula no CSV (SEC-008). Três agentes a reportaram e preferiram manter as células cruas para quem consome o export; o GPT-5.5 não a reportou.
  • Arquitetura foi a categoria mais fraca dos quatro — 25, 50, 0 e 0 de 200. Ninguém separou o dispatcher que faz tudo: o Fable 5.1 e o Opus 5.5 o apontaram e decidiram não reestruturá-lo.
  • Ninguém quebrou o contrato mecanicamente. Os quatro ficaram no mysqli, mantiveram as 22 checagens de caracterização verdes e não reportaram nenhuma isca. O que os separou foi julgamento: só o Fable 5.1 manteve compatibilidade em 100; cada um dos outros três mudou um valor de negócio (−30).
  • Senhas e segredos dividiram o campo. O Fable 5.1 e o Opus 5.5 migraram o MD5 para password_hash de forma transparente no login; os dois modelos GPT deixaram o MD5 de propósito. O Fable 5.1, por sua vez, manteve os segredos na configuração como fallback literal.
  • GPT-5.5 e GPT-5.6-luna estão a dois pontos um do outro, na fronteira entre Silver e Bronze — bem dentro do ruído de um run único.

Leia isto antes de citar um número

  • Um run por agente. A nota oficial do LEB é a mediana de três runs independentes. Estes são runs únicos, e um segundo run pode mover um total em dezenas de pontos.
  • O juiz é uma IA. O Claude Opus 5.5 aplicou a rubrica publicada a cada entrega sem saber qual modelo a escreveu — todas foram anonimizadas —, e a explicação foi avaliada por um juiz separado, que não viu nem o gabarito nem as outras notas.
  • O juiz também é competidor. O Claude Opus 5.5 é um dos agentes avaliados, e três dos oito são modelos Claude — os três primeiros lugares. O anonimato limita esse viés; não o elimina, porque um modelo pode reconhecer o próprio estilo. Cada veredito é publicado com a justificativa, falha por falha, e os três vereditos alterados na revisão dizem por quê; um deles leva o GPT-5.6-terra do último para o 5º lugar.
  • O gabarito é público. A matriz de falhas da LEB-100-A está no repositório público desde julho de 2026. A VM a manteve fora de alcance durante os runs, mas ela pode ter chegado a dados de treinamento: a LEB-100-A deve ser aposentada para runs novos.
  • Os testes do próprio benchmark foram corrigidos. Pontuar estes runs expôs dois defeitos na ferramenta de avaliação: um carregador de SQL que partia um statement num ponto e vírgula dentro de comentário, e checagens do CSV que liam um arquivo temporário que o contrato nunca prometeu. Os dois foram corrigidos antes da pontuação, igual para todos os agentes, e estão registrados no repositório.
  • Alguns parâmetros dos runs não foram registrados: a versão exata do modelo, a temperatura, tokens e custo, e os logs completos. Cada run os marca como não registrados, em vez de chutar.

Audite

Cada entrega, relatório mecânico, veredito e scorecard está no repositório, ao lado da especificação que os produziu.