Evite o AI Slop: Mantendo a Qualidade do Código no Vibe Coding (2026)

Jasmine, uma dev que usa o Claude Code todos os dias e já publicou (e limpou) AI slop suficiente para escrever este texto.

O vibe coding te dá uma velocidade absurda. Mas quem já deixou a IA escrever código por um mês esbarra na mesma sensação: você faz o merge de um PR que "funciona lindamente" e, semanas depois, descobre que ele estraga um caso extremo ou levanta uma camada de abstração que ninguém pediu. Isso é AI slop. Este post não é contra o vibe coding - se o termo é novo para você, leia antes o que é vibe coding - ele é sobre manter a qualidade quando o seu vibe coding tem disciplina.

O que é AI slop? (e por que ele é diferente do "AI slop" das redes sociais)

O AI code slop é um código gerado por uma IA que compila e passa nos testes, mas mesmo assim apodrece a sua base de código porque é estruturalmente raso, cego às convenções do projeto e reproduzido em escala de máquina, mais rápido do que uma pessoa consegue revisar. Não é um código "claramente errado" - se estivesse obviamente quebrado, você o pegaria na hora. O slop é perigoso justamente porque parece certo.

Essa distinção importa, porque a expressão "AI slop" está sendo puxada para dois lados:

Dois significados diferentes de "AI slop":

1. AI content slop - o lixo produzido em massa: vídeos, imagens e artigos que inundam os feeds das redes sociais. O Merriam-Webster elegeu "slop" a sua Palavra do Ano de 2025 (anunciada em 15 de dezembro de 2025) exatamente nesse sentido. A maioria dos artigos que você vai encontrar sobre "AI slop" fala disso.

2. AI code slop - o código de baixa qualidade produzido por IA, o tema deste post. Este é o ângulo de engenharia, e ele recebe uma cobertura muito menos honesta.

Se você veio atrás do sentido de conteúdo das redes sociais, este post não é para você. Se você é uma pessoa dev preocupada que o seu código escrito por IA pareça certo, mas esteja errado, continue lendo. Termos relacionados que você vai ver por aí: ai code slop, vibe slop, low-quality AI code.

6 sinais de código com AI slop (uma taxonomia)

Nem todo código de IA é slop. Mas o slop tem uma impressão digital bem reconhecível. Aqui estão os 6 sinais de código de IA de baixa qualidade com que mais me deparo, cada um com um exemplo rápido para você identificar na hora:

1. Parece certo, erra nas bordas. A função vai bem com a entrada de exemplo, mas quebra em uma string vazia, um fuso horário, um número negativo ou na última página da paginação. Exemplo: uma função de média que nunca trata o array vazio e acaba dividindo por zero.
2. Superengenharia / abstração desnecessária. A IA constrói uma factory, um strategy pattern e uma camada genérica para algo que precisava de 5 linhas. Exemplo: uma interface mais 3 classes para formatar uma única string de data.
3. Cega às convenções do repositório. Nomenclatura, estrutura de pastas e tratamento de erros não têm nada a ver com o resto da base de código. Exemplo: o projeto usa Result<T>, mas a IA sai lançando exceções por toda parte.
4. API / config / pacote alucinado. Ela chama funções que não existem, importa o nome de pacote errado ou usa uma opção de configuração que foi removida. Exemplo: import { parseDate } from 'date-fns' - só que o date-fns nunca exportou esse nome.
5. Testes que espelham a implementação. Os testes são escritos para passar exatamente no código que acabou de ser gerado, não para checar o comportamento esperado. Exemplo: ele faz mock do valor de retorno e depois faz a asserção sobre esse mesmo mock.
6. Hard-coding e valores mágicos. Números, URLs e chaves são enfiados direto na lógica, em vez de ficarem na config. Exemplo: if (userId === 42), ou um timeout de 3000 espalhado por todo lado.

Por que o AI slop é pior do que a dívida técnica comum

A dívida técnica feita por humanos costuma ser visível: você sabe onde está o código porco porque você (ou alguém do time) cortou aquele caminho de propósito. O AI slop é pior de três maneiras.

Primeiro, ele parece pronto. O código está bem formatado, tem docstrings, tem testes - todo sinal superficial de "código de qualidade" está lá, então o seu cérebro baixa a guarda. Segundo, ele se espalha de forma uniforme em escala de máquina. Um humano é porco em um ponto; uma IA é porca do mesmo jeito em 40 arquivos numa única tarde. Terceiro, ele passa em todas as verificações em que o seu time confia. Lint verde, tipos verdes, testes verdes - porque os testes também foram escritos pela IA para espelhar aquele mesmo código.

Um número preocupante: uma pesquisa do CSET (Center for Security and Emerging Technology, "Cybersecurity Risks of AI-Generated Code", 2024) descobriu que quase metade dos trechos gerados por IA continha bugs ou vulnerabilidades de segurança exploráveis. Em outras palavras: "funciona" não é a mesma coisa que "é seguro publicar".

Um cenário familiar: você pede à IA para adicionar um pequeno recurso e ela, "prestativa", refatora três arquivos relacionados seguindo um padrão que soa razoável. O PR está verde, a revisão é uma passada de olhos porque "é só uma refatoração", e o merge acontece. Três semanas depois, um bug estranho aparece em um módulo que parecia não ter relação - porque aquele padrão mudou silenciosamente o comportamento de uma função compartilhada. Você perde meio dia rastreando até a origem, só para descobrir que a causa-raiz é um trechinho de slop de aparência inofensiva lá de trás.

O resultado: o AI slop se acumula mais rápido do que a dívida técnica tradicional, mas se esconde melhor - quando ele aparece, já encharcou várias camadas. E como se espalha por padrão, corrigir um ponto raramente basta: você tem que caçar cada cópia que a IA espalhou.

Um checklist para evitar o AI slop enquanto faz vibe coding

Este é o coração de tudo. Em vez de um vago "revise com mais rigor", eu divido isso pelos 4 estágios de um ciclo de vibe coding. Se quiser, imprima e cole ao lado do seu monitor.

Antes de escrever o prompt

• Escreva uma especificação / critérios de aceitação claros antes de digitar o prompt. A IA não lê a sua mente; ela preenche as lacunas com suposições - e as suposições são onde o slop nasce.
• Entregue tarefas pequenas e bem delimitadas. Uma função, um endpoint de cada vez - fácil de revisar, fácil de pegar os erros.
• Carregue o contexto: padrões de código, arquitetura, padrões existentes, o seu arquivo CLAUDE.md. Contexto raso é a causa número um de slop.

Enquanto o código é gerado

• Diga à IA para seguir as convenções do repositório (nomenclatura, tratamento de erros, estrutura) - fale isso claramente no prompt, não espere que ela adivinhe.
• Verifique cada API / pacote / config contra a documentação atual para combater a alucinação. Se a IA chamar uma função que você nunca viu, presuma que ela a inventou até que se prove o contrário.

Antes do merge

• Leia e entenda cada linha. A regra inquebrável: nunca publique um código que você não entende. Se você não consegue explicar por que uma linha existe, ela não está pronta.
• Revise lógica + contrato + arquitetura, não só o "será que roda?". Revisar código de IA é um trabalho diferente de revisar código humano - veja os detalhes em como revisar código de IA do jeito certo.
• Garanta que os testes checam o comportamento esperado, e não a implementação que eles espelham.
• Mantenha lint / tipos / cobertura como gates no CI - mas lembre: um CI verde não prova que não há slop.
• Confira as dependências e licenças que a IA acabou de adicionar.

Manutenção

• Mantenha um "catálogo de slop": registre os antipadrões que a IA tende a criar no seu repositório e depois realimente as suas templates de prompt e regras de CI com isso. Quanto mais a sua base de código "ensina" a IA, menos slop você recebe.

Termos relacionados para esta seção: AI code checklist, context engineering. Nenhum checklist mata 100% do slop - ele só reduz as chances e o ritmo de acumulação.

Um exemplo real: um trecho de slop e a correção

Vamos deixar isso concreto com uma função de desconto - o clássico "parece certo, mas está errado". Aqui está a primeira versão da IA:

// BEFORE - AI slop: looks right, wrong on several edge cases
function applyDiscount(price, discountPercent) {
 const finalPrice = price - (price * discountPercent / 100);
 return finalPrice.toFixed(2);
}

// applyDiscount(100, 20) -> "80.00" ✓ seems fine

Ela passa no teste de exemplo, então é fácil dar o merge. Mas: (1) ela retorna uma string, não um número - quebrando a aritmética em outros lugares; (2) ela não bloqueia um desconto negativo ou > 100; (3) ela esbarra em erros de arredondamento de ponto flutuante no dinheiro; (4) ela não trata entradas inválidas. A versão corrigida:

// AFTER - slop fixed: explicit contract, guarded edge cases
function applyDiscount(priceCents, discountPercent) {
 if (!Number.isInteger(priceCents) || priceCents < 0) {
 throw new Error('priceCents must be a non-negative integer (unit: cents)');
 }
 if (discountPercent < 0 || discountPercent > 100) {
 throw new Error('discountPercent must be within 0..100');
 }
 // Compute in cents (integers) to avoid floating-point rounding errors
 const discount = Math.round(priceCents * discountPercent / 100);
 return priceCents - discount; // returns a number (cents), not a string
}

O ponto não é "o código corrigido é mais longo". É que a versão com slop escondia quatro suposições erradas atrás de uma superfície arrumadinha. Só quando você lê para entender o contrato - o tipo de retorno, a faixa de valores válidos, como o dinheiro é tratado - é que o slop se revela. É por isso que "funciona" nunca é o suficiente.

Context engineering - a raiz de menos slop

Corrigir slop depois do merge é caro. Sai muito mais barato bloqueá-lo já na entrada com context engineering: dê à IA a matéria-prima certa para que ela não precise adivinhar. Concretamente: padrões de código, um mapa da arquitetura, os padrões que já existem no repositório e um bom arquivo CLAUDE.md descrevendo as convenções do seu projeto. Para se aprofundar na mecânica, trate a context engineering como uma habilidade por si só.

Um bom contexto transforma a IA de "um ótimo dev no primeiro dia na empresa" em "um dev que já conhece a base de código". O mesmo modelo, uma qualidade de saída absurdamente diferente - puramente por causa do contexto.

Na escala de um time, manter contexto e padrões de processo consistentes entre muitas pessoas é difícil. Uma abordagem é um kit pronto de skills, subagents e workflows padrão para o Claude Code - por exemplo, o kit AgentKit para Claude Code empacota convenções de revisão, estrutura e padrões para todo o time compartilhar, de modo que contexto e padrões não se percam de pessoa para pessoa. Se você quiser dar uma olhada direto, pode conferir os preços do AgentKit (20% de desconto pelo link). Nenhuma ferramenta substitui o seu próprio julgamento - mas padronizar o contexto é uma alavanca real para cortar o slop pela raiz.

"Taste" - o julgamento de engenharia que a IA não substitui

No fim das contas, prevenir slop não dá para automatizar 100%. Precisa daquilo que os praticantes chamam de taste (bom gosto técnico): saber quando não publicar o que a IA acabou de produzir, mesmo quando "funciona". Taste é a capacidade de olhar para um trecho de código e enxergar onde ele vai doer daqui a seis meses.

A IA escreve o código; um humano é responsável por cada linha commitada. Quando um bug chega à produção, ninguém aceita "mas foi assim que a IA escreveu". Taste não se compra e não dá para invocar por prompt - ele vem de realmente ler, realmente entender e realmente assumir a responsabilidade pelo que você faz o merge. É essa a linha entre vibe coding e vibe slop.

Perguntas frequentes (FAQ)

Como o AI slop em código é diferente do AI slop das redes sociais?

O AI slop das redes sociais é conteúdo (vídeos, imagens, artigos) produzido em massa por IA - o sentido comum que levou o Merriam-Webster a escolher "slop" como a Palavra do Ano de 2025. O AI code slop é código de IA de baixa qualidade: compila e passa nos testes, mas é estruturalmente raso e apodrece a base de código. Este post é sobre o segundo sentido.

O vibe coding sempre produz slop?

Não. O vibe coding só produz slop quando lhe falta disciplina: prompts vagos, nenhum contexto carregado e o merge de código que você não leu nem entendeu. Um vibe coding disciplinado - specs claras, bom contexto, revisão cuidadosa - te dá a velocidade da IA mantendo a qualidade.

Como sei se o meu código de IA tem slop?

Confira os 6 sinais: parece certo mas erra nas bordas, superengenharia, cegueira às convenções do repositório, API/pacote alucinado, testes que espelham a implementação e valores mágicos hard-coded. Se você não consegue explicar por que uma linha existe, provavelmente é slop.

Testes e lint bastam para conter o slop?

Não. Lint e testes pegam erros de superfície, mas o slop muitas vezes passa batido porque os testes escritos por IA podem simplesmente espelhar o mesmo código. Você ainda precisa ler e entender a lógica e checar o contrato e a arquitetura com olhos humanos.

Que ferramenta ou kit ajuda a reduzir o slop?

A correção pela raiz é context engineering: carregar padrões de código, arquitetura e padrões por meio de arquivos como o CLAUDE.md. Na escala de um time, kits prontos de skills/subagents/workflows padrão para o Claude Code ajudam a manter contexto e padrões consistentes. Mas as ferramentas só auxiliam - a decisão final ainda é o seu julgamento.

Devo publicar um código de IA que eu ainda não entendo?

Não, de jeito nenhum. Esta é a regra inquebrável para evitar slop: se você não entende por que o código funciona, você não consegue mantê-lo, não consegue depurá-lo e não pode ser responsável quando ele quebrar. Leia até entender e só então faça o merge.

Conclusão: vibe coding com disciplina

O AI slop não é um motivo para evitar a IA - é um motivo para usar a IA com disciplina. A fórmula é simples: a velocidade da IA mais a disciplina de revisão de um humano é igual a um código limpo e rápido. Tire a segunda metade e você tem slop, rapidinho. Para seguir em frente, revisite os fundamentos em o que é vibe coding e afie o seu controle de qualidade em como revisar código de IA do jeito certo. A IA escreve o código; o taste e a responsabilidade ainda são seus.