Slop e vibe-coding: o que é, por que mata projeto, e como sair em 7 dias

Definição operacional

Slop é qualquer entrega de IA sem critério: código frágil sem teste, conteúdo genérico que serve pra qualquer empresa, integração que passa na demo e quebra na primeira borda. O nome pegou porque descreve bem o que sobra: lama. Massa indiferenciada.

Vibe-coding é o processo que gera slop: o desenvolvedor (ou agente) aceita a primeira sugestão do modelo sem especificação, sem teste, sem revisão. Funciona o suficiente pra parecer pronto. Quebra o suficiente pra travar o time depois.

Sinais de que seu projeto está em slop

1. Você não sabe explicar por que uma função está como está. "O Copilot sugeriu assim." Red flag.
2. Cobertura de teste < 30% em código novo, mas o time diz "depois a gente cobre."
3. Bug em produção exige rollback porque ninguém entende a causa raiz.
4. Pull request com 800 linhas e descrição "implementa X". Nenhum reviewer aguenta ler.
5. Conteúdo de IA usado direto: blog post, landing, descrição de produto. Sem editoria, sem voz.
6. Lock-in invisível: o código depende do modelo específico, do prompt específico, do humor do servidor da OpenAI naquele dia.

Por que slop é pior que código humano ruim

Código humano ruim é lento, mas previsível. Você aponta o bug, o autor explica o pensamento, conserta. Tem rastro mental.

Slop não tem rastro. O modelo gerou, o dev colou. Ninguém pensou. Quando quebra, não há a quem perguntar. Você não está debugando código — está fazendo arqueologia.

O custo composto é o que mata: cada sprint adiciona slop, cada slop adiciona dívida invisível, e em 6 meses o produto está fora de qualquer refator econômico.

O protocolo de 7 dias pra sair

Este é o escopo do plano SPRINT da AUMI (R$ 4.997). Cinco passos, ordem importa:

1. Dia 1 — Auditoria do gerado. Mapear cada arquivo/feature que veio de IA. Marcar risco: alto (segurança/dados), médio (lógica de negócio), baixo (boilerplate).
2. Dia 2-3 — Correção dos riscos críticos. Bugs de segurança, validação de fronteira, vazamento de dados, dependências obsoletas. Sem refator opcional.
3. Dia 4-5 — Disciplina de engenharia. Specs versionadas pras 3-5 features principais. Testes pros caminhos críticos. ADRs pra decisões de arquitetura. Code review obrigatório dali em diante.
4. Dia 6 — De-slop do conteúdo. Reescrever copy/blog/descrições gerados com IA bruta. Voz da marca, fato real, zero generalidade.
5. Dia 7 — Um agente ou automação rodando. Algo concreto na infra do cliente, com teste e doc. Prova viva que dá pra usar IA com método.

Como evitar voltar pro slop

• Spec antes de código vira regra de máquina, não de boa vontade. Sem spec aprovada, o ciclo não anda.
• Teste antes de revisão. Agente de teste roda antes do humano olhar. Cobertura é gate, não meta.
• Revisão sênior em 100% das entregas. Humano com nome assina. Responsabilidade tem dono.
• Vault de contexto: convenções, decisões, regras de negócio carregadas antes da primeira linha de cada ciclo.

Isso é o método AUMI. Detalhe em O que é AI Native.

Quer um diagnóstico do seu projeto?

O assessment gratuito mapeia onde está o slop no seu codebase e propõe rota de saída em 24h úteis. Se valer, vira SPRINT; o valor entra como crédito integral no primeiro plano mensal.

Perguntas frequentes