Benchmarking Opus 5 no SlopCodeBench
Resultados de benchmark no SlopCodeBench sugerem que o novo modelo Claude Opus 5 da Anthropic oferece apenas ganhos modestos sobre o Opus 4.x em tarefas de programação multi-etapas, enquanto muitas vezes gera código mais complexo e “mais bagunçado”. Comentadores argumentam que os LLMs atuais ainda têm dificuldade com manutenibilidade de longo prazo, refatoração e evitar abstrações desnecessárias, e que o design do harness e os prompts podem ser tão importantes quanto o modelo subjacente. Muitos pedem benchmarks melhores, baselines humanos e sinais de RL que recompensem explicitamente simplicidade e saúde do código, especialmente porque alguns desenvolvedores relatam preferir modelos mais antigos ou o Fable da Anthropic para trabalhos complexos e prolongados.
Reação geral ao Opus 5 vs. modelos anteriores
- Muitos dizem que o Opus 5 parece apenas ligeiramente melhor que o Opus 4.8, não um salto “uau”.
- Alguns preferem o comportamento e o tom do 4.8; o Opus 5 é descrito como excessivamente confiante, prolixo e escolástico, gerando “slop” e revisões pedantes.
- Uma minoria relata ganhos reais de produtividade, especialmente usando o Opus 5 medium como substituto mais rápido e barato do 4.8 x-high, com o Fable reservado para as tarefas mais difíceis.
SlopCodeBench e manutenibilidade de código
- O SlopCodeBench é elogiado como um benchmark raro que testa comportamento longitudinal: múltiplas adições de funcionalidades e como a qualidade do código evolui.
- Destaca-se a taxa de aprovação estrita de ~24% do Opus 5 versus ~17% do Opus 4.6; alguns veem isso como um ganho modesto, porém real, outros como ainda inaceitavelmente baixo.
- Preocupação central: os modelos adicionam muitas funções e complexidade ao longo do tempo; o RL/benchmarks atuais raramente penalizam a complexidade, então os modelos não aprendem a simplificar.
Harnesses, prompts e fluxos de trabalho de agentes
- Vários argumentam que “slop” muitas vezes é um problema de harness/system prompt: agentes com liberdade demais e sem restrições sobre onde editar acumulam bagunça.
- “Skills” estáticas ou fluxos de trabalho templatizados às vezes prejudicam o desempenho no SlopCodeBench, provavelmente por desperdiçar contexto e forçar fluxos subótimos em tarefas greenfield.
- Outros relatam sucesso com:
- Restringir edições a seams estreitas.
- “Passes” periódicos dedicados de “refatoração” ou revisões de toda a base de código.
- Instruções explícitas que priorizam simplicidade e código DRY nos arquivos de configuração do projeto.
Comportamento do modelo, degradação e benchmarking
- Alguns usuários sentem que os modelos (incluindo o Fable) pioram após o lançamento, possivelmente por mudanças motivadas por custo, como quantização; outros citam rastreadores públicos mostrando melhora majoritariamente monotônica.
- Há preocupação de que laboratórios possam tratar de forma especial entradas parecidas com benchmarks, tornando os benchmarks públicos menos confiáveis.
- Os participantes pedem suítes de avaliação mais robustas (incluindo métricas de manutenibilidade) e observam que a maioria das equipes não tem expertise para construí-las.
“Slop” realmente importa?
- Um tópico pergunta se feiura/complexidade importa se os defeitos permanecem baixos e os clientes estão satisfeitos.
- As respostas conectam isso diretamente ao custo de mudanças de longo prazo e à eficiência de agentes de IA: código bagunçado é mais difícil de modificar tanto para humanos quanto para modelos.
- Artigos recentes (mencionados, mas não detalhados) supostamente descobrem que código mais “limpo” melhora a navegação e a eficiência dos agentes.