A Epidemia de AI Slop: Por Que Precisamos Desacelerar e Ler Nosso Código

Ultimamente, tenho sentido uma crescente sensação de desconforto ao revisar Pull Requests (PRs) e Merge Requests (MRs). Estamos vivendo uma era onde entregar código nunca foi tão rápido, mas, ao mesmo tempo, estou demorando cada vez mais para entender a lógica colocada na minha frente. O que começou como uma ferramenta útil para nos ajudar com código repetitivo (boilerplate) se transformou silenciosamente em algo muito mais difícil de gerenciar (e de prever).

O Catalisador: Um Mundo de Slop#

Recentemente, assisti a uma palestra brilhante do Mario Zechner intitulada “Building pi in a World of Slop”¹, e ela deu nome exatamente ao que venho sentindo.

“And then there’s people that say, ‘Our product’s been 100% built by agents.’ Yes, we know, it f***ing sucks now. Congratulations.”

— E tem gente que diz: ‘Nosso produto foi 100% construído por agentes.’ Sim, nós sabemos, está uma merda agora. Parabéns.

Ele descreve como a internet, e nossos repositórios, estão sendo inundados com lixo gerado por IA (ele chama isso de slop — aquela enxurrada de conteúdo gerado de baixa qualidade). E como sabemos, com IA estamos alimentando um ciclo de garbage-in/garbage-out (lixo entra, lixo sai), impulsionado em grande parte pela promessa de produtividade infinita para entregar código ad nauseam. Ele também introduz o termo “clankers”, que particularmente amei, e vamos falar sobre eles também.

Esse conceito ressoou profundamente comigo. Precisamos conversar sobre o custo de longo prazo dessa epidemia, minha perspectiva sobre isso e esses clankers, e por que a habilidade mais importante para um engenheiro de software agora é a disciplina para desacelerar.

A Ascensão do “Clanker”#

Na palestra do Zechner, um “clanker” é essencialmente um agente de IA solto por um desenvolvedor para escrever, corrigir e submeter código autonomamente, sem supervisão humana. Eles vagam por issue trackers de projetos open source e bases de código das empresas, deixando um rastro de código de baixa qualidade, nunca lido, não revisado e confiantemente quebrado, que pode até funcionar para um cenário específico, mas quem realmente sabe?

Terceirizando o Pensamento#

Quando ouvi esse termo, instantaneamente fez sentido. Para mim, o clanker representa tudo de errado com nossa obsessão atual por velocidade em detrimento da qualidade. É a manifestação máxima da engenharia preguiçosa. O problema não é a IA em si; o problema é o ser humano do outro lado que trata a IA como um desenvolvedor sênior em vez de um vibe-coder (alguém que apenas descansa, deixando a IA codificar) que digita rápido, não tem intenção de construir software de qualidade e só quer fechar tickets/issues.

Estamos vendo desenvolvedores terceirizarem não apenas a digitação, mas o pensamento. Eles implantam um clanker para corrigir um bug, o agente gera um patch, e o desenvolvedor faz o merge sem nem ler o código, otimizando puramente para tickets fechados no Jira e alta quantidade de palavras por minuto (words-per-minute). Isso é uma traição fundamental da nossa responsabilidade como engenheiros.

A Ausência de Dor (Pain)#

Para entender completamente por que esse slop gerado por clankers é tão perigoso, precisamos olhar como os humanos realmente constroem software. Humanos são falíveis, altamente emocionais e facilmente irritáveis. E na engenharia de software, essa irritação é na verdade uma feature, não um bug.

Fricção (Friction) como Funcionalidade#

Quando um humano trabalha em uma base de código terrível e convoluta, ele sente dor (pain). Depois da terceira vez revisando e corrigindo um bug através de cinco camadas de abstração desnecessária, o humano se frustra. Ele pode reclamar em uma retro (retrospectiva), pressionar por uma sprint de refatoração, ou simplesmente reescrever o módulo por pura indignação. Essa fricção (friction) age como um gargalo natural contra o acúmulo de dívida técnica (tech debt).

Agentes não sentem dor! (Agents do not feel pain!)

Complexidade Composta#

Se você soltar um clanker em uma base de código complexa, ele vai felizmente mergulhar no spaghetti code (código confuso e mal escrito), adicionar mais uma camada de molho de abstração, e submeter o PR. Ele não se importa que o código seja ilegível. Ele não se importa com a pobre alma que terá que depurar aquilo às 3 da manhã daqui a seis meses. Como Zechner aponta, esses modelos aprenderam a programar varrendo a internet, e vamos ser honestos, 90% do código na internet é nosso lixo velho, não mantido e bagunçado.

Quando desenvolvedores deixam a IA “cuidar” da arquitetura, o que eles obtêm é complexidade de nível empresarial gerada em segundos. Os erros não apenas se somam; eles se multiplicam (e rápido).

A Ilusão do “Detailed Spec” (Especificação Detalhada)#

Uma defesa comum que ouço de colegas é: “It’s fine as long as you write a sufficiently detailed spec for the AI.” (Tudo bem, desde que você escreva uma especificação suficientemente detalhada para a IA).

Mas aqui está a realidade que frequentemente esquecemos: uma especificação suficientemente detalhada é um programa. Se você deixa espaços em branco no seu prompt, a IA precisa preenchê-los. E ela os preenche com a mediana do código lixo da internet (descanse em paz, StackOverflow).

A Base de Código como Caixa Preta#

Já vi isso pessoalmente. Um clanker vai escrever confiantemente um patch que corrige um bug local, mas como o agente não possui o contexto global da arquitetura do sistema, ele silenciosamente quebra algo no caminho (downstream). Quando o desenvolvedor não lê o código gerado, essa pílula envenenada é incorporada ao projeto.

De repente, ninguém no time entende mais como o sistema funciona. A base de código se torna uma caixa preta de abstrações geradas por IA. Se seus usuários começarem a gritar por causa de uma parada de produção e você não conseguir consertar porque “não lê mais o código”, você não é um engenheiro. Você é apenas um passivo (liability).

Desacelerando (Slowing the F*** Down)#

Na minha vida pessoal, sou um grande defensor da intencionalidade. Gosto do “trabalho” (fricção) de fazer as coisas manualmente porque isso me força a estar presente. Sinto exatamente o mesmo sobre engenharia de software: a fricção é onde o entendimento acontece.

O ato de digitar um algoritmo crítico, cometer erros e debugá-lo manualmente é como você constrói um modelo mental do sistema. Se você terceiriza essa fricção inteiramente para uma IA, você terceiriza seu entendimento.

Estabelecendo Limites para a IA#

Isso não é um chamado para desinstalar suas ferramentas de IA. É um chamado para disciplina. Precisamos definir limites para onde a IA pertence em nosso fluxo de trabalho:

1. Wipe the slop: Use agentes para o trabalho chato. Escrever casos de reprodução para bugs obscuros de usuários, gerar boilerplate de testes unitários, ou usar como rubber duck (um pato de borracha para pensar em voz alta sobre um problema de lógica)? Perfeito. Deixe a IA cuidar disso.
2. Leia cada linha do caminho crítico: Se lida com pagamentos, autenticação, lógica de negócios ou estados complexos, você escreve. Ou, no mínimo, você lê cada linha que a IA gera com extremo cuidado.
3. Pare de otimizar para velocidade: Entregar uma funcionalidade em dois dias em vez de uma semana não importa se levará três meses para entender a arquitetura resultante depois.

Conclusão#

Estamos vivendo uma era estranha onde a indústria está ativamente celebrando a capacidade de construir produtos inteiros sem entender como eles funcionam. É quase como se estivéssemos alugando nossa arquitetura de um LLM em vez de possuir o conhecimento nós mesmos.

Os engenheiros que prosperarão na próxima década não serão os “prompt engineers” mais rápidos ou aqueles que conseguem implantar um exército de clankers para fechar tickets. Os grandes engenheiros serão aqueles que sabem quando desligar a IA, arregaçar as mangas, e ler a p*rra do código.

Respire fundo. Proteja sua base de código. Slow the f*** down.

Recursos#

Cover Photo by Ángel Navarro.