SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks

Resumo Técnico: SlopCodeBench

1. O Problema

O desenvolvimento de software é inerentemente iterativo, envolvendo a extensão e modificação contínua de código existente sob especificações em evolução. No entanto, os benchmarks atuais de agentes de codificação (LLMs) avaliam predominantemente soluções de "um único tiro" (single-shot) contra especificações completas.

Essa abordagem falha em capturar um modo de falha crítico: o código pode passar nos testes iniciais, mas tornar-se progressivamente mais difícil de estender, gerando "slop" (código de baixa qualidade, redundante e desorganizado). Benchmarks iterativos existentes frequentemente:

• Restringem demais as decisões de design do agente (fornecendo interfaces internas pré-definidas).
• Usam repositórios humanos maduros, onde o agente não paga o custo de suas próprias decisões arquiteturais iniciais.
• Medem apenas a taxa de aprovação (pass-rate), ignorando a degradação estrutural ao longo do tempo.

O artigo identifica a necessidade de um benchmark que force o agente a construir sobre seu próprio código anterior, sob especificações que definem apenas o comportamento externo, deixando a arquitetura interna livre para que o agente cometa (e pague pelos) erros de design.

2. Metodologia: SlopCodeBench (SCBench)

Os autores introduzem o SlopCodeBench, um benchmark agnóstico à linguagem (focado em Python neste estudo) composto por 20 problemas e 93 checkpoints.

Princípios de Design:

1. Sem Interfaces Internas Prescritas: O agente recebe apenas contratos externos (CLI ou API), forçando-o a tomar decisões arquiteturais que influenciarão a facilidade de futuras extensões.
2. Sem Suite de Testes Explícita: O agente nunca vê os testes reais; ele deve inferir casos de borda apenas a partir da descrição da especificação e exemplos.
3. Ciclo de Feedback Realista: O agente começa do zero no Checkpoint 1 (C1) e, em cada checkpoint subsequente (C2, C3...), recebe uma nova especificação e deve estender o seu próprio código anterior. Se uma decisão arquitetural ruim for tomada no C1, ela se torna a base para o C2, criando um efeito de "bola de neve" de degradação.
4. Agnóstico à Linguagem: Os problemas são definidos por comportamento observável, permitindo implementação em qualquer linguagem (embora o estudo foque em Python).

Métricas de Qualidade (Trajetória):
Além da correção (passar nos testes), o benchmark mede dois sinais de qualidade ao longo da trajetória:

• Verbosidade (Verbosity): A fração de código redundante ou duplicado. Medida pela densidade de violações de padrões (regras AST-Grep) e duplicação estrutural (clone lines).
• Erosão Estrutural (Structural Erosion): A concentração de complexidade em funções de alta complexidade. Calculada como a fração da "massa de complexidade" (Cyclomatic Complexity $\times \sqrt{SLOC}$) que reside em funções com CC > 10. Isso detecta quando a lógica é "empilhada" em funções gigantes em vez de ser distribuída modularmente.

3. Principais Contribuições

1. Novo Benchmark Iterativo: O SCBench é o primeiro a medir a evolução da qualidade do código onde o agente herda as consequências de suas próprias decisões de design iniciais ao longo de múltiplos checkpoints.
2. Métricas de Degradação: Introdução de Erosion e Verbosity como métricas trajectórias, demonstrando que a correção (pass-rate) não garante manutenibilidade futura.
3. Calibração com Humanos: Comparação direta entre o código gerado por agentes e repositórios Python humanos mantidos (48 repositórios, variando de nicho a grandes projetos como Django e Scikit-learn).
4. Estudo de Intervenção por Prompt: Análise de se prompts de "anti-slop" ou "planejamento primeiro" podem mitigar a degradação.

4. Resultados Chave

O estudo avaliou 11 modelos (incluindo Claude 3.5/4, GPT-4o/5, e variantes Codex) em 20 problemas.

• Falha Generalizada em Longo Prazo: Nenhum agente resolveu completamente qualquer um dos 20 problemas do início ao fim. A taxa de resolução estrita (todos os testes passando em todos os checkpoints) máxima foi de apenas 17,2% (Opus 4.6).
• Degradação Inevitável:
  • A Erosão Estrutural aumentou em 80% das trajetórias.
  • A Verbosidade aumentou em 89,8% das trajetórias.
  • O custo por checkpoint aumentou 2,9x do início ao fim, sem melhoria na correção.
• Comparação com Humanos:
  • O código dos agentes é 2,2x mais verboso e significativamente mais erodido do que em repositórios humanos mantidos.
  • Enquanto o código humano tende a estabilizar (métricas planas ao longo do tempo), o código do agente deteriora-se a cada iteração.
• Falha de Prompts de Intervenção:
  • Prompts que exigem "planejamento antes de codificar" ou que proíbem padrões verbosos conseguiram melhorar a qualidade inicial (intercepto mais baixo).
  • No entanto, não reduziram a taxa de degradação (a inclinação da linha de queda permaneceu a mesma).
  • A melhoria na qualidade estrutural não se traduziu em melhores taxas de aprovação de testes ou redução de custos.

Exemplo Concreto: No problema code_search, agentes que "hardcodearam" lógica específica de linguagem no C1 foram forçados a reescrever grandes partes do código no C2 (suporte a múltiplas linguagens), acumulando complexidade. No C5, funções principais como find_matches_in_file cresciam para centenas de linhas com alta complexidade ciclomática, tornando o código ininteligível, mesmo que passasse nos testes.

5. Significado e Conclusão

O SlopCodeBench demonstra que os benchmarks atuais de "taxa de aprovação" (pass-rate) submedem sistematicamente a robustez de extensão do código gerado por IA.

• O Paradoxo da Correção: Um agente pode gerar código que passa em todos os testes atuais, mas que cria uma "dívida técnica" estrutural imediata, tornando futuras extensões impossíveis ou extremamente custosas.
• Falta de Disciplina de Design: Os agentes atuais carecem da disciplina de design necessária para o desenvolvimento iterativo de software. Eles tendem a otimizar para o teste imediato, sacrificando a arquitetura de longo prazo.
• Implicações Futuras: A simples pressão via prompt não é suficiente para resolver esse problema. A pesquisa sugere que intervenções que enforce disciplina estrutural (seja no treinamento do modelo ou através de ferramentas de engenharia de software integradas) são necessárias para interromper a degradação, não apenas para atrasá-la.

Em suma, o trabalho alerta que, sem métricas de qualidade estrutural ao longo do tempo, os agentes de codificação atuais estão gerando "slop" que se acumula rapidamente, tornando-os inadequados para tarefas de desenvolvimento de software real e iterativo.