Software Slop: O Problema Não É Código Ruim. É Atenção Insuficiente.

O termo “software slop” circula como sinônimo de código ruim. Gerado por IA sem cuidado, cheio de bugs, colado no repositório sem revisão. A maioria das pessoas para nessa definição. E a maioria das pessoas erra.

Software slop não é um problema de qualidade. É um problema de atenção.

Atenção como recurso finito

Antes dos geradores de código, existia uma restrição natural: escrever código custava tempo. Cada linha exigia que o desenvolvedor pensasse sobre o que estava construindo. O ato de digitar era lento o suficiente para forçar compreensão. Não porque desenvolvedores fossem virtuosos, mas porque a ferramenta impunha esse custo.

Essa restrição desapareceu.

Ferramentas de geração de código produzem centenas de linhas por minuto. O volume de código que entra no repositório cresceu. Mas a capacidade humana de atenção não acompanhou. Continua igual. Talvez esteja diminuindo, dado que dívida cognitiva se acumula silenciosamente em equipes que delegam decisões de design à IA sem documentar o raciocínio.

O resultado: a distância entre o código que precisa ser compreendido e o código que realmente é compreendido aumentou. Slop é essa distância.

A fórmula que torna visível

Tentar medir slop é útil, mesmo que imperfeito. Uma abordagem possível:

Slop Score = 5 × (1 - min(atenção_gasta / custo_atenção, 1))

Onde:

• custo_atenção é o esforço necessário para compreender e verificar o código
• atenção_gasta é o esforço realmente investido

A escala vai de 0 (atenção adequada) a 5 (negligência total). Funciona como um termômetro, não como diagnóstico definitivo.

Três exemplos ilustram o espectro.

React (score: 0.6). Um projeto com governança forte, processo de revisão rigoroso e comunidade ativa que questiona cada pull request. A atenção investida é alta. O score reflete isso.

SQLite (score: 3.0). Código sólido, mas com uma base de testes tão extensa que humanos não conseguem auditar tudo. A atenção que o projeto exige supera o que qualquer equipe consegue dedicar consistentemente. Slop acontece não por descuido, mas por escala.

OpenClaw (score: 3.8). Um projeto de código gerado por IA com revisão humana mínima. Alto volume de produção, baixo investimento em compreensão. O score alto não surpreende.

A ferramenta admite suas próprias falhas. O custo de atenção é difícil de estimar com precisão. A atenção gasta é ainda mais difícil. Os números são aproximações. Mas aproximações que apontam na direção certa são melhores que nenhuma medição.

O vínculo que a IA rompeu

Como documentamos ao analisar a dívida de verificação, 96% dos desenvolvedores não confiam totalmente no código gerado por IA. Apenas 48% verificam sistematicamente. Esse dado conta a mesma história por outro ângulo.

O ato de escrever código sempre funcionou como mecanismo de verificação embutido. O programador que escrevia uma função entendia suas premissas, seus limites, seus modos de falha. A atenção era intrínseca ao processo. Não precisava ser adicionada depois porque nunca tinha sido removida.

IA removeu essa restrição. Código aparece pronto. O desenvolvedor que o aceita pode não entender por que aquela abordagem foi escolhida, quais alternativas foram descartadas, quais premissas estão implícitas. A verificação que antes era automática agora precisa ser deliberada. E verificação deliberada, em escala, exige infraestrutura.

Sem essa infraestrutura, o que temos é previsível: código funcional que ninguém compreende. Repositórios que crescem mais rápido que a capacidade de qualquer equipe de auditá-los. Bugs que não são encontrados porque ninguém sabe onde procurar.

Slop não é defeito. É déficit.

A distinção importa porque determina a resposta.

Se slop fosse código ruim, a solução seria ferramentas melhores. Linters mais inteligentes. Modelos mais capazes. Testes automatizados mais abrangentes. E essas ferramentas ajudam. Mas não resolvem o problema central.

Se slop é déficit de atenção, a solução é governança. Processos que garantem que o código receba a atenção proporcional ao risco que representa. Políticas que definem qual código exige revisão humana e qual pode passar por verificação automatizada. Métricas que tornam o déficit visível antes que ele se transforme em incidente.

Linters não sabem que um trecho de código gerenciando transações financeiras exige mais atenção que um script de formatação. Modelos de IA não sabem que a função que acabaram de gerar contradiz uma decisão arquitetural tomada dois anos atrás. Apenas governança contextual pode fazer essa triagem.

O termômetro e o tratamento

A fórmula do slop score tem valor como ferramenta de diagnóstico. Permite que equipes identifiquem onde a atenção está sendo subalocada. Mas o diagnóstico sem tratamento é curiosidade acadêmica.

O tratamento envolve três disciplinas:

Classificação de risco por contexto. Nem todo código merece a mesma atenção. Código que toca dados de clientes, transações financeiras ou decisões regulatórias exige verificação humana rigorosa. Código utilitário pode passar por revisão automatizada. A governança define os critérios. Sem ela, tudo recebe a mesma (in)atenção.

Orçamento de atenção explícito. Se uma equipe gera 10x mais código com IA, mas o tempo de revisão permanece constante, o déficit é matemático. Governança significa reconhecer que atenção é recurso finito e alocar esse recurso proporcionalmente ao risco.

Rastreabilidade de compreensão. Quem revisou este código? Qual era o nível de compreensão? Quais premissas foram validadas? Sem esse registro, dívida de verificação se acumula invisível até o dia em que um incidente exige respostas que ninguém tem.

O que muda

Software slop não é um problema novo. Código mal revisado sempre existiu. O que mudou é a escala. Quando a produção de código dependia de digitação humana, o volume era naturalmente limitado. A atenção disponível, embora imperfeita, era proporcional.

IA removeu o limite de produção sem ampliar o limite de compreensão. Pela primeira vez, organizações podem gerar código em volume industrial sem que nenhum humano compreenda o que foi construído.

Essa é a definição operacional de slop: a distância entre produção e compreensão. Fechar essa distância não é problema de engenharia. É problema de governança.

---

Fontes

• Nuno Job. “Can We Measure Software Slop?” pscanf.com. Abril 2026.
• Simon Willison. “Slop is the New Spam.” Maio 2024.
• Sonar. “State of Code 2026.” Janeiro 2026.

Victorino Group ajuda organizações a construir governança de IA que mantém a atenção humana proporcional ao risco: contato@victorino.com.br | www.victorino.com.br