A quantidade ideal de slop não é zero

O conceito de 'slop', conteúdo gerado por IA de baixa qualidade e alta quantidade, não é novo, mas sua aplicação prática na engenharia de software ganhou urgência com o avanço dos agentes de programação. O artigo atual vai além da crítica moral ou técnica: ele propõe um critério operacional para decidir quando aceitar, reduzir ou eliminar o slop, a proporção entre risco de falha e rigor de verificação. Isso não é uma questão de 'usar ou não usar IA', mas de calibrar intencionalmente o nível de intervenção humana conforme o domínio do software: casual (ex.: app pessoal para organizar janelas no macOS), business (ex.: ferramenta interna de monitoramento de APIs) e acute (ex.: sistema de controle de dispositivos médicos).

A distinção crucial está na natureza do software como 'credence good': o usuário final, e até o próprio desenvolvedor, se delegar totalmente a revisão a um LLM, não consegue avaliar a qualidade interna apenas pela funcionalidade aparente. Um código que roda hoje pode ser um pesadelo de manutenção amanhã, especialmente quando depende de comportamentos não documentados de modelos, APIs ocultas ou interações frágeis entre componentes. É por isso que o autor rejeita a ideia de 'zero slop' como dogma: ela ignora custos reais de tempo, atenção e trade-offs estratégicos de entrega.

Essa abordagem muda a conversa sobre IA no desenvolvimento: de 'será que confiamos?' para 'em quais condições confiamos, e com quais salvaguardas?'. Para equipes técnicas, significa que políticas de uso de LLMs não podem ser genéricas, um time de fintech precisa de gateways de revisão em pull requests que um time de pesquisa acadêmica pode dispensar. Para líderes de engenharia, é um alerta contra a otimização cega por velocidade: entregar rápido com slop elevado pode acelerar o primeiro lançamento, mas também aumenta a dívida técnica exponencialmente, e essa dívida não aparece nos dashboards de deploy, só no tempo gasto para corrigir um bug em produção três meses depois.