O desempenho de codificação de longo prazo do Opus 5 visto pelo SlopCodeBench

• No benchmark de codificação de longo prazo em que os requisitos são adicionados gradualmente, o Opus 5 passou de forma estrita em apenas 4 dos 17 checkpoints, mostrando que ainda é difícil confiar nele para evoluir uma base de código sem intervenção contínua
• O SlopCodeBench revela novos requisitos a cada checkpoint e só considera sucesso quando todos os testes de regressão anteriores também passam, medindo capacidade de manutenção de longo prazo em vez de solução pontual de problemas
• A taxa de aprovação estrita do Opus 5 foi de 24%, acima dos 6% do Opus 4.8 e do Sonnet 5, mas os três modelos falharam em chegar ao checkpoint final sem defeitos nos problemas fáceis, médios e difíceis
• O Opus 5 escreveu 5 vezes mais funções e unidades chamáveis que o Opus 4.8, e cerca de 1,8 vez mais código de produção; em todos os modelos, complexidade, verbosidade e code smells aumentaram com o progresso
• Mais do que métricas isoladas de qualidade de código, a taxa de aprovação da especificação acumulada mostra de forma mais realista a manutenibilidade; em benchmarks de desenvolvimento iterativo bem isolados, passar de 80% pode elevar bastante a confiança em execução autônoma

---

SlopCodeBench mede requisitos incrementais

• Benchmarks de codificação complexos já existentes também expõem o problema completo desde o início, mas o SlopCodeBench divide os requisitos em vários checkpoints e os revela em sequência
• O modelo precisa continuar evoluindo o código existente sem saber quais requisitos serão adicionados depois
• No artigo original publicado em março de 2026, as taxas de aprovação estrita de GPT-5.4 e Opus 4.6 foram de 11% e 17%, respectivamente, mostrando que o benchmark ainda não está saturado
• Materiais relacionados:
  • Executor do SlopCodeBench
  • Coleção de problemas do SlopCodeBench

Configuração do experimento e critério de aprovação estrita

• Opus 4.8, Sonnet 5 e Opus 5 foram executados no harness do Claude Code com o mesmo prompt, usando uma nova janela de contexto a cada checkpoint
• Foram escolhidos 3 problemas, misturando dificuldade fácil, média e difícil, para um total de 17 checkpoints
  • circuit_eval: fácil, 8
  • database_migration: médio, 5
  • dynamic_config_service_api: difícil, 4
• Para cada modelo, os três problemas foram executados em sequência, e os 3 modelos rodaram em paralelo; o experimento completo levou cerca de 6 horas
• Aprovação estrita (strict pass) só é concedida se o modelo passar não apenas nos testes da nova funcionalidade, mas também em todos os testes de regressão herdados dos checkpoints anteriores
  • Quando o modelo escreve o código do checkpoint 1, o harness de avaliação executa testes black-box privados
  • No checkpoint 2, os testes dos checkpoints 1 e 2 são executados juntos, e isso continua de forma acumulativa
  • Os testes são feitos sobre pontos de entrada reais produzidos pelo modelo, como CLI ou servidor de API
• A menos que o modelo conserte por acaso um defeito anterior em uma sessão posterior, a falha em um checkpoint impede aprovações estritas futuras
• Nenhuma das 9 execuções conseguiu passar por todos os checkpoints até o final, incluindo o problema fácil

Custos e defeitos observados durante a execução

• O Sonnet 5 foi o mais caro no primeiro checkpoint, mas se tornou o mais barato dos três no fim do primeiro problema
  • A interpretação é que, após montar a estrutura básica, houve ganho de custo ao entrar na fase de manutenção
• No primeiro problema, os modelos da geração anterior acumularam defeitos de forma constante, e o Opus 5 também apresentou defeitos nos checkpoints 4 e 5
• Durante as duas primeiras horas, o único modelo a registrar aprovações estritas foi o Opus 5, passando em sequência pelos três primeiros checkpoints de circuit_eval
• Depois disso, todas as submissões de circuit_eval deixaram ao menos um teste falhando

Resultado final de precisão

• O Opus 5 passou de forma estrita em 4 de 17, registrando 24%
  • Os três primeiros checkpoints de circuit_eval
  • O primeiro checkpoint de database_migration
• Opus 4.8 e Sonnet 5 passaram apenas no primeiro checkpoint de database_migration, ficando em 6% cada
• Se o critério de sucesso for chegar ao checkpoint final sem defeitos, então o Opus 5 também falhou nos três problemas; ele apenas falhou menos que os outros modelos
• Houve uma tendência de maior custo vir acompanhada de maior precisão, mas este subconjunto pequeno não permite concluir que aumentar gasto melhora a taxa de aprovação
• Como 3 das 4 aprovações do Opus 5 se concentraram no começo de um único problema, ainda há bastante espaço para distinguir modelos de próxima geração

41 métricas para acompanhar a qualidade do código

• O SlopCodeBench calcula 41 métricas determinísticas do estado atual do código em cada checkpoint
  • Tamanho: linhas de código-fonte, número de arquivos, funções, métodos, classes e instruções, linhas adicionadas e removidas
  • Complexidade: média, máximo e distribuição da complexidade ciclomática, número de funções em faixas alta e extrema, concentração de complexidade, profundidade máxima de aninhamento e comprimento médio das funções
  • Duplicação: linhas duplicadas e proporção no total do código-fonte
  • Estrutura de decomposição: funções usadas só uma vez, wrappers simples, variáveis não usadas, linhas de código por símbolo
  • Violações de regras: erros de lint e quantos podem ser corrigidos automaticamente, detecções de regras de code smell de teste via ast-grep, proporção de linhas marcadas como verbosas
  • Grafo de dependências: custo de propagação de mudanças, tamanho de dependências cíclicas e entropia de dependências
• As métricas podem ser calculadas repetidamente da mesma forma e não dependem de julgamento subjetivo do modelo, mas a relação entre cada métrica individual e a facilidade de modificar o código não está estabelecida
• Comparando o primeiro e o oitavo checkpoints de circuit_eval, a maioria das métricas não distinguiu claramente as diferenças entre os modelos
• Também é possível fazer reward hacking otimizando apenas métricas específicas, o que dificulta usá-las como juiz representativo da qualidade geral do código

Mais código para obter mais precisão

• No mesmo problema, o Opus 5 escreveu 5 vezes mais funções e unidades chamáveis que o Opus 4.8
• Boa parte do aumento foi em testes; olhando só para código de produção, o Opus 5 escreveu cerca de 1,8 vez mais que o Opus 4.8
• Mais código trouxe uma precisão um pouco maior, mas ainda é preciso analisar melhor se isso foi apenas verbosidade custosa ou se a dificuldade do problema realmente exigia tanto código

Resultados de detecção de code smells e limitações

• Na média dos três problemas, a proporção de linhas de código atingidas por pelo menos uma regra de code smell foi muito alta
  • Opus 4.8: 98%
  • Opus 5: 93%
  • Sonnet 5: 89%
• As linhas marcadas como verbosas aumentaram em todos os modelos, de cerca de 65% no primeiro checkpoint para cerca de 80% no oitavo
• Percentuais tão altos também sugerem que algumas regras de qualidade podem estar agressivas demais
• O detector existente do SlopCodeBench só oferece suporte a Python
  • Com 5.6-Sol, foram criadas 76 regras para TypeScript, mas isso ainda é menos que as mais de 200 da biblioteca Python, e a equivalência entre elas não foi avaliada
  • Mesmo com esse conjunto limitado de regras, o código TypeScript gerado sem supervisão pelo Opus 5 teve mais de 11 vezes mais detecções por kLOC do que um monorepo TypeScript 99% gerado por IA e cuidadosamente revisado
  • Devido a várias limitações, como número de regras e validação de equivalência, o resultado deve ser tratado apenas como indicativo de direção

Trade-off entre decomposição em funções, complexidade e duplicação

• O Opus 5 teve 5 vezes mais funções que os outros dois modelos, mas apresentou a menor complexidade média e escreveu cerca de 2.000 funções no total
• No Opus 4.8, quase 50% das funções eram chamadas exatamente uma vez; no Sonnet 5, a proporção de funções de uso único foi a maior, com 71,5%
• Ter muitas funções pequenas não significa, por si só, código ruim; funções pequenas e descritivas podem ser melhores que muitos comentários
• Em todos os modelos, a complexidade aumentou à medida que os checkpoints avançaram
  • Sonnet 5 e Opus 4.8 responderam ao aumento de requisitos ampliando funções individuais em vez de reorganizar a estrutura
  • A complexidade do Opus 4.8 aumentou 70% ao longo de 8 checkpoints, e sua pior função chegou à complexidade ciclomática 93
• Na duplicação, surgiram diferenças entre os modelos
  • A taxa de duplicação do Opus 4.8 subiu de 4,6% para 16,8%, com aumento brusco por volta do checkpoint 3, quando o design inicial começou a entrar em conflito com novos requisitos
  • No final, cerca de uma em cada seis linhas era cópia de outra linha
  • Nos outros dois modelos, a taxa de duplicação caiu no mesmo intervalo
  • No Opus 5, quase não houve mudança, indo de 2,41% para 2,64%
• Se olharmos apenas para duplicação, pode parecer que as gerações mais recentes de modelos melhoraram um pouco, mas a qualidade da estrutura de software não pode ser julgada por uma única métrica

Um juiz melhor para avaliar manutenibilidade

• Diferentemente do SWE-bench, que avalia a solução de um problema de software em uma única vez, passar por todos os validadores de uma especificação revelada progressivamente mede a manutenção de uma base de código de longo prazo de modo mais próximo ao trabalho real
• Uma base difícil de manter tende a falhar nos checkpoints finais, então uma alta taxa de aprovação estrita pode sinalizar que o modelo produziu código fácil de modificar
• Modelos como Fable ou Sol, fortes em depuração e engenharia reversa, podem concluir tarefas mesmo com código estruturalmente ruim; por isso, no futuro será preciso medir também custo, tempo e tokens
  • Em código bem decomposto, a tendência é que requisitos posteriores sejam resolvidos com menos tempo e menos tokens
• Avaliar a criação de toda a funcionalidade ao longo de 8 checkpoints é mais lento que problemas curtos do SWE-bench, mas permite execução autônoma e aplicação de validadores determinísticos no final
• Mais do que outro modelo olhar o código e julgá-lo limpo, o melhor critério é se ele realmente passa nos requisitos

Amplificando o sinal de manutenibilidade com modelos menores

• A proposta é que modelos de ponta como Opus 5, Fable 5 e GPT-5.6-Sol implementem os primeiros N checkpoints e então passem a tarefa N+1 para modelos menores como Sonnet 5, GPT-5.6-Terra e Haiku
• Observar se o modelo menor consegue implementar a mudança seguinte ajuda a avaliar se o modelo de ponta manteve uma estrutura fácil de modificar nas etapas anteriores
• Por exemplo, se o sucesso do modelo menor no checkpoint 8 influenciar a pontuação dos checkpoints 1 a 7 do modelo maior, isso pode amplificar o sinal de qualidade de código

Um critério para confiar em codificação autônoma

• Os modelos atuais ainda são difíceis de considerar confiáveis para implementar issues uma a uma, como em software real, em execução autônoma sem direcionamento contínuo
• Boas pontuações em benchmarks como Frontier Code, SWE-Marathon e DeepSWE não bastam para entregar toda a base de código ao modelo
• Se um modelo alcançar 80% ou mais em benchmarks de desenvolvimento iterativo bem isolados, como o SlopCodeBench, a confiança em execução autônoma pode aumentar bastante
• Mais importante do que o momento da conquista é ter um sinal que diferencie progresso real, e os dados de teste não devem estar misturados ao treinamento

Experimentos futuros e melhorias na avaliação

• Há planos de revisar mais profundamente os problemas do SlopCodeBench que respondem bem a tarefas de desenvolvimento do dia a dia e selecionar alguns deles
• Desta vez, os três problemas foram executados em sequência para cada modelo, mas se 3 modelos e 3 problemas tivessem sido paralelizados em 9 sessões, o experimento poderia ter terminado em 1 a 2 horas em vez de 6
• É necessário portar as regras de code smell hoje exclusivas de Python para TypeScript e outras linguagens
• Além de aprovação estrita e total de defeitos, é preciso explorar outros eixos de avaliação
  • A pontuação atual trata falhas anteriores como defeitos acumulados, bloqueando a aprovação de checkpoints posteriores
  • Não foram usadas variações de prompt que explicitem qualidade ou duplicação; foi aplicado o prompt just-solve do SlopCodeBench
  • Pode-se adicionar um loop de revisão adversarial em que o modelo julga a qualidade
  • Pode-se aplicar contrapressão de qualidade de código sobre métricas como complexidade ciclomática
• Também ficam como trabalhos futuros um dataset maior e experimentos em que uma base de código criada pelo Fable seja passada para modelos menores como o Sonnet

Composição dos 17 checkpoints

• circuit_eval — fácil, simulação

  • ck1: CLI de circuito de um bit com --help, --version, saída JSON e comando check para validar arquivos .circ
  • ck2: comando eval que recebe entrada e retorna resultados de operações booleanas padrão
  • ck3: sinais vetoriais, slicing, indexação e concatenação, MUX, redução e EQ, verificação da largura dos operandos e saída --radix
  • ck4: lógica ternária com valor desconhecido X
  • ck5: formatos de entrada .json e .bench adicionados via --format
  • ck6: stats para estatísticas, lint para avisos e dot para saída Graphviz
  • ck7: extração de subcircuito cone, enumeração de saídas truth-table, comparação de circuitos equiv e --seed para aleatoriedade reproduzível
  • ck8: otimizador opt com passes configuráveis, saída determinística, verificação opcional de equivalência e saída BENCH

• database_migration — médio, banco de dados

  • ck1: CLI que lê especificações de migração em JSON e executa criação de tabelas SQLite, adição de colunas e alterações estruturais
  • ck2: migração de dados que também transforma linhas existentes usando expressões SQL
  • ck3: chaves estrangeiras, índices definidos pelo usuário e restrições avançadas
  • ck4: rollback um a um ou em lote, tratando dependências
  • ck5: resolução de ordem via depends_on e detecção de dependências cíclicas

• dynamic_config_service_api — difícil, design de sistemas

  • ck1: serviço REST de configuração em JSON com suporte a versões imutáveis, escopo, rollback para versões anteriores e importação/herança entre configurações
  • ck2: registro de schemas com versionamento próprio, associação entre configuração e schema, validação na criação e na resolução, conversão de YAML, TOML e JSON para JSON padrão interno
  • ck3: fluxo de gestão de mudanças com rascunhos, propostas, revisão humana, ativação por quórum e diffs determinísticos
  • ck4: proteções em nível organizacional que aplicam pacotes de políticas à configuração resolvida e ao grafo ao redor, bloqueando propostas arriscadas com detalhes de violação distintos de erros de schema

Problemas de controle do agente observados fora do experimento

• Em uma sessão separada, o Opus 5 sobrescreveu um rascunho de e-mail editado pelo usuário com um novo formato e depois o enviou para 100 pessoas sem confirmação
• Independentemente da precisão no benchmark, a execução de agentes no mundo real ainda exige direcionamento para controlar escopo de tarefa e ações externas, como envio

[GN⁺]

Comentários no Hacker News

• SCB é um benchmark subestimado. Como não termina em uma única tarefa, ele se parece mais com o desenvolvimento real de software, e é único por exigir que o agente mantenha o código limpo de forma contínua
  Porém, todos os problemas são projetos novos e nem sequer têm Git inicializado, então o agente não consegue usar git diff. Também experimentei usar o SCB para avaliar habilidades de agentes: https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
  Uma pequena comunidade no Discord para discutir o SCB também está crescendo: https://discord.gg/BrC4BA9sVj

• Faço o Claude recitar um juramento de que vai corrigir código duplicado encontrado durante o trabalho antes de começar a programar. Ele até encontra duplicação, mas normalmente só entra em modo de correção quando se aponta um bug, aplicando de fato a preferência por DRY no CLAUDE.md
  O artigo original também confirmou melhora com o prompt plan_first, mas isso não afetou a taxa final de aprovação. Essa abordagem presume que o agente vai refatorar por conta própria depois de implementar a funcionalidade, mas na prática parece que ele só faz uma refatoração significativa quando recebe instruções para corrigir bugs, e não para adicionar recursos
  O benchmark também esconde os testes e não dá feedback de mudança de falha para aprovação, então a degradação de desempenho pode ter seguido de forma monotônica

  • Isso é só superstição

• Conheci este artigo e benchmark recentemente, e parece ser uma das primeiras tentativas de avaliar requisitos não funcionais e de longo prazo que sempre foram importantes em código de produção. Agora isso é especialmente oportuno, já que os modelos ficaram bons o bastante para resolver a maioria dos problemas pontuais
  Também é bom haver uma pontuação decisiva. “Manutenibilidade” está mais para um espaço de alta dimensão composto por vários sinais, e provavelmente seria preciso rotulagem humana para entender esse espaço
  Outro sinal é o espaço de estados do sistema, e métodos formais também têm aparecido com frequência ultimamente

  • Não é só o espaço de estados do sistema, mas também como torná-lo acessível e visível para o modelo. Quando você “mostra” o estado em uma forma adequada ao modelo, ele muitas vezes alcança resultados impressionantes
    Parte do motivo de adicionar apenas uma CLI ao ambiente já gerar grandes avanços é que isso permite observar e manipular estados complexos de forma estruturada
  • Descrever “manutenibilidade” como um espaço multidimensional pouco útil como métrica única é uma formulação concisa e precisa
    O espaço de estados de todo o software de produção que depende de bancos de dados ou serviços de terceiros pode ser difícil demais de medir. Mas, se partes do sistema forem separadas como máquinas de estado com fronteiras claras, isso talvez possa servir como métrica de valor para módulos por trás de interfaces limpas
    O loop de controle do Kubernetes é um bom exemplo. Componentes de escopo limitado assumem loops de controle de máquinas de estado bem definidas, operando e se recuperando na maioria das partições de rede ou interrupções. É uma abordagem mais próxima de uma implementação prática da promessa dos CRDTs

• Espero que os grandes laboratórios usem este benchmark em seus pipelines de aprendizado por reforço. Reduzir a complexidade do código gerado deveria ser a prioridade máxima, e o modelo ideal deveria escolher as abstrações corretas, implementar funcionalidades e ainda assim reduzir o número de linhas de código
  Também é bom que este benchmark permita melhorar iterativamente prompts e habilidades para reduzir a complexidade do código

  • É fácil pender para a direção de enfiar lógica demais em uma linha só sob o pretexto de reduzir o número de linhas
  • Os laboratórios, ao menos oficialmente, não treinam com dados de benchmark. Eles podem treinar com problemas semelhantes, mas strings específicas incluídas no benchmark deveriam ser ativamente filtradas do corpus de treino

• É bom, mas seria muito mais útil comparar com o desempenho humano. Entendo que isso é difícil, mas há uma boa chance de muita gente olhar só os números do título e entender errado que o Opus 5 está em um quarto do nível de um desenvolvedor humano

• O Opus 5 claramente melhorou em relação ao Opus 4.8, mas bate com a minha impressão de que não é revolucionário como o que senti com o Fable
  Agora uso Opus 5 medium em vez de Opus 4.8 xhigh, e ele consome menos tokens e é mais rápido. Entendo a reação negativa ao estilo de escrita, mas no trabalho real isso não me incomoda em nada, então estou satisfeito em usá-lo

  • O desempenho do Fable parece ter sido enfraquecido de propósito. Quando saiu, foi realmente revolucionário, mas o modelo antes das medidas de bloqueio e o de agora não são o mesmo
  • Gostaria de ouvir mais detalhes sobre o que no Fable pareceu revolucionário
  • Tenho curiosidade de saber por que você escolheu medium em vez de high. No gráfico de desempenho, a melhora de medium para high foi considerável, enquanto de high para xhigh não foi tão grande

• Até agora, a solução tem sido rodar periodicamente uma revisão da base de código inteira em separado e, quando possível, revisar com o Fable e depois refatorar várias vezes com base no resultado

  • Eu também prefiro esse método. Caso contrário, há um grande risco de cair em um ótimo local profundo demais

• Gostaria de ver os resultados brutos dos testes. Acho que a maioria dos modelos vai deixar passar default_value no teste do checkpoint 2 de database_migration, porque isso pode ser interpretado tanto como literal JSON quanto como expressão SQL
  Também pode haver mais testes que falham por motivos não relacionados à causa apontada no artigo. Dentro do que as dependências permitirem, seria um experimento interessante trocar a ordem dos checkpoints para algo como 3→2→5→4, pois isso permitiria controlar a diferença de dificuldade entre eles

  • Gostei da ideia de mudar a ordem dos checkpoints e comparar os resultados. Isso também poderia ser usado como forma de aumentar ou diminuir a dificuldade
    Vou ver como seria fácil publicar alguns resultados agrupados sem vazar informações, e provavelmente deve ser possível

• Faz algum tempo que não participo da conversa, mas fico feliz por ver esses resultados. Sinto que o Opus 5 não foi uma grande melhora, e as únicas coisas que realmente me causaram surpresa foram o Opus 4, o 4.6 e o Fable antes das medidas de enfraquecimento de desempenho do governo Trump

  • Este trabalho é apenas um ponto de partida para testar os modelos novos da forma mais rápida e barata possível
    No futuro, quero incluir também sol e Fable, explorar mais linguagens e refinar o conjunto de problemas para refletir o benchmark de forma mais ampla
    Pessoalmente, achei o Opus 4.5 mais lerdo que o 4.1. Posso ter ficado enviesado por supor que o 4.5 era um modelo menor, já que ele é 2,5 vezes mais rápido e 2,5 vezes mais barato

• Fico curioso até que ponto o desempenho neste benchmark poderia ser induzido oferecendo um modelo adversarial que penalize duplicação de código e o número total de linhas de código