Medindo a desleixo do código

SlopCodeBench e o acúmulo de “slop”

• O benchmark inverte o padrão usual: várias tarefas iterativas com o contexto apagado entre as rodadas, imitando o uso real por agentes.
• Más decisões de design no início se acumulam; sob critérios estritos (todos os checkpoints passam), até os melhores modelos supostamente alcançam 0% de resolução.
• Métricas simples usadas: crescimento de LOC, complexidade ciclomática e “regras de verbosidade” heurísticas para detectar código excessivamente longo ou redundante.
• Muitos comentaristas apreciam finalmente ter uma forma quantitativa de lidar com um fenômeno que veem na prática.

O que é qualidade de código, afinal?

• Vários argumentam que correção é apenas uma linha de base; qualidade também inclui eficiência, segurança, manutenibilidade, legibilidade, observabilidade, portabilidade etc.
• Outros observam que grande parte do código empresarial produzido por humanos historicamente teve baixa qualidade; o slop da IA é visto como “mais do mesmo, só que mais rápido”.
• Alguns afirmam que a qualidade de código é fundamentalmente difícil ou intratável de medir (comparada ao problema da parada) e inerentemente baseada em vibe.

LLMs são bons programadores? Experiências conflitantes

• Lado entusiasta:
  • Para muitas tarefas, diz-se que a saída de LLMs é melhor do que a de um dev mediano ou júnior, especialmente com um humano competente guiando.
  • Pessoas relatam maior produtividade com qualidade aceitável, especialmente em linguagens de alto nível e em trabalho greenfield.
• Lado cético:
  • Agentes produzem código demais, duplicam lógica, evitam apagar código morto e quebram a arquitetura existente.
  • Frequentemente falham em mudanças não locais, sistemas complexos e bugs sutis, ou exigem muita microgestão.
  • Alguns dizem que bases de código escritas por LLMs “speedrunam” a si mesmas até estados impossíveis de manter.

Design global, manutenibilidade e modelos mentais

• Comentadores enfatizam que os problemas mais difíceis são globais: separação de responsabilidades, camadas, interfaces e evolução de longo prazo.
• Programar é descrito como uma forma de humanos construírem modelos mentais compartilhados; se agentes fizerem toda a programação, os humanos podem perder entendimento e controle.
• Outros argumentam que futuras ferramentas podem fornecer “views” sobre bases de código enormes, reduzindo a necessidade de modelos globais mantidos por humanos.

Métricas, lei de Goodhart e ideias de avaliação

• A mudança em LOC é amplamente vista como uma métrica de mau cheiro surpreendentemente eficaz, mas vulnerável à otimização e ao “code golfing” patológico.
• Sugestões: combinar LOC/tokens com complexidade ciclomática, churn, acoplamento, coesão, profundidade de indentação, padrões AST e custo de tokens para “grokar” o código.
• Alguns propõem:
  • “Número de rodadas resolvidas corretamente” iterativo como métrica central.
  • Usar um modelo base separado para julgar se o código de outro modelo é utilizável.
  • Benchmarks de domínio/arquitetura (por exemplo, aplicativos de “contador” progressivamente mais complexos) que meçam qualidade de design, e não apenas aprovação em testes.

Impacto na indústria e questões em aberto

• Muitos distinguem “programar” de “engenharia de software”; veem o primeiro se aproximando da automação mais rapidamente do que o segundo.
• Há debate sobre se os modelos atuais já superam “a maioria” dos desenvolvedores ou ainda são muito piores do que profissionais competentes.
• Custo e limites de tokens são restrições práticas; alguns relatam ter recuado de configurações agressivas com agentes por causa de custo e slop.
• Sentimento geral: medir o desleixo é valioso, mas definir e otimizar a verdadeira qualidade de código continua sem solução.