5 antipadrões de vibecoding que destroem um projeto

O vibecoding não destrói um projeto sozinho. Quem destrói são os seus hábitos, aqueles que você trouxe da época em que escrevia código devagar e à mão. Quando um modelo gera cem linhas em três segundos, cada mau hábito passa a custar dez vezes mais, porque escala junto com a velocidade. A seguir estão cinco antipadrões que aparecem em todo projeto resgatado depois de dois meses de “entregar rápido”. Para cada um: por que dói, como saber que você caiu nele e o que fazer a respeito.

Antipadrão 1: sem spec, com prompts vagos

O erro mais comum. Você digita “crie um painel de administração para mim” e aperta enter. O modelo chuta. Chuta as tabelas, chuta os papéis, chuta se a filtragem acontece no servidor ou no cliente. Alguns chutes acertam, outros erram feio, e você não tem nenhuma referência para dizer que ele chutou errado.

Por que dói: sem uma spec, “resultado correto” não existe. Qualquer coisa que o modelo devolva é igualmente aceitável, então você se contenta com a primeira versão que compila. Uma semana depois, você tem dez telas, cada uma interpretando “usuário” de um jeito diferente.

Sintoma: muitas rodadas de “não, não é assim, corrige”. Se você precisa de um diálogo de cinco ou seis turnos com o agente para chegar ao que tinha na cabeça desde o início, a spec estava morando na sua cabeça, e não no prompt.

Solução: antes de pedir código, escreva uma descrição curta: de três a cinco frases sobre entradas, saídas e restrições. Não precisa ser um documento formal; uma lista basta: o que a função recebe, o que devolve, o que está fora do escopo, quais são os casos de borda. Para mudanças maiores (mais do que alguns arquivos), escreva um SPEC.md de verdade e peça ao agente que primeiro resuma como entendeu a tarefa, antes de escrever uma única linha.

Antipadrão 2: aceitar código gerado sem ler

O diff tem 200 linhas, parece razoável, os testes estão verdes, então você clica em “aceitar tudo”. É nesse momento que você deixa de ser engenheiro e vira uma esteira entre o modelo e o repositório.

Por que dói: os modelos geram código que parece funcionar. Detalhes sutis (uma condição invertida, um caso de lista vazia esquecido, um catch que engole o erro) passam no teste visual do “parece OK”. Pior: um modelo adiciona de bom grado uma dependência de que você não precisa ou duplica uma lógica que já existe três pastas adiante. Se você não lê, a dívida se acumula em silêncio.

Sintoma: você não consegue explicar por que uma determinada função funciona. Quando um colega pergunta “por que tem um setTimeout de 250 ms aqui?”, você responde “foi o modelo que colocou”. Isso é um sinal de alerta: código que você não entende é código que você não consegue manter.

Solução: leia cada linha que você aprova como se estivesse revisando o código de um colega. Se um diff é grande demais para ser lido com atenção, ele é grande demais para um único commit: peça passos menores. Pergunte ao agente “por que isso e não aquilo” sobre qualquer trecho que surpreenda você. Trate o código gerado como um PR de um júnior muito rápido, mas confiante demais.

Antipadrão 3: pular os testes porque “funciona”

Você clica pelo app, tudo roda, então para que perder tempo com testes. O vibecoding tenta você ativamente aqui: como o código aparece tão rápido, os testes parecem um freio. É uma armadilha que se fecha exatamente quando o projeto começa a ter valor.

Por que dói: “funciona” significa “funcionou uma vez, na minha máquina, no caminho que eu por acaso cliquei”. Sem testes, cada nova mudança gerada pelo modelo é uma aposta: você não sabe se ela quebrou algo três módulos adiante. E, com vibecoding, as mudanças são muitas e rápidas, então a regressão alcança você num piscar de olhos.

Sintoma: você tem medo de fazer mudanças. Todo refactor é uma roleta, porque a única verificação é clicar manualmente. Bugs que estavam “já corrigidos” continuam voltando. É o clássico caso de falta de rede de segurança.

Solução: escreva testes para o que realmente dói quando quebra: regras de negócio, validação, cálculos, caminhos de erro. Não persiga 100% de cobertura; persiga a cobertura de risco. Os modelos são ótimos para gerar testes, então aproveite: peça os testes antes da implementação ou junto com ela, e confira você mesmo se eles testam comportamento, e não implementação. Um bom teste num caminho crítico vale mais do que dez num getter.

Antipadrão 4: context rot (despejar o repositório inteiro no prompt)

“Para o modelo ter o contexto completo”, você cola nele cinquenta arquivos ou o repositório inteiro. A intuição diz: quanto mais contexto, melhor. Aqui, a intuição está errada.

Por que dói: a atenção de um modelo é um recurso finito. Quanto mais arquivos irrelevantes você despeja, mais o sinal se dilui. O modelo começa a misturar convenções de módulos diferentes e a buscar padrões em qualquer código que por acaso esteja na janela, em vez do código que importa. Isso se chama context rot: a qualidade das respostas cai à medida que o ruído aumenta, mesmo quando tudo cabe formalmente na janela.

Sintoma: quanto mais longa a sessão, piores as respostas. O modelo começa a “esquecer” decisões de dez mensagens atrás, troca nomes, propõe soluções incoerentes com o resto do projeto. Você cola cada vez mais coisas, e os resultados ficam cada vez mais fracos.

Solução: dê ao modelo só o que é relevante para a tarefa: dois ou três arquivos mais uma nota curta sobre a arquitetura, e não o grafo inteiro de dependências. Use arquivos como o CLAUDE.md, onde você registra as convenções uma única vez em vez de colá-las em cada prompt. Comece uma sessão nova para cada tarefa nova: um contexto novo e limpo vale mais do que uma conversa longa e bagunçada. Menos, porém mais preciso.

Antipadrão 5: megaprompts que pedem tudo de uma vez

“Crie para mim autenticação com OAuth, um painel do usuário, um sistema de pagamentos, notificações por e-mail e um dashboard de analytics”, tudo em um único prompt. O modelo vai produzir alguma coisa, porque ele sempre produz alguma coisa. A única questão é quanto disso dá para usar.

Por que dói: quanto maior o escopo de uma única resposta, mais decisões o modelo toma sem você e menos atenção dá a cada uma. Você recebe cinco funcionalidades funcionando pela metade em vez de uma boa. Depurar vira um pesadelo, porque, quando algo não está certo, você não sabe se o problema está nos pagamentos, na autenticação ou na forma como o modelo ligou uma coisa à outra. Tudo fica pela metade ao mesmo tempo.

Sintoma: você recebe uma muralha de código que não consegue verificar nem fazer merge com segurança. Sua primeira reação é “OK, mas por onde eu começo a conferir isso?”. Se a resposta a um prompt não cabe em um único review razoável, o prompt era grande demais.

Solução: divida a tarefa nos menores passos que façam sentido e entregue um de cada vez. Primeiro a autenticação: leia, teste, faça o merge. Depois o painel. Depois os pagamentos. Cada passo termina com uma peça funcionando e verificada, sobre a qual o próximo se apoia. Parece mais lento, mas na verdade é mais rápido, porque você não fica voltando o tempo todo para desatar nós. Prompts pequenos, diffs pequenos, risco pequeno.

Por que esses cinco andam juntos

Esses antipadrões se reforçam. Sem spec (1), você não sabe o que procurar ao ler um diff (2). Já que você nem está lendo, para que se dar ao trabalho de escrever testes (3)? Para deixar o modelo “descobrir sozinho”, você despeja tudo nele (4) e pede tudo de uma vez (5). Cada um, isoladamente, dá para aguentar; juntos, criam um projeto que funciona na demo e desmorona com o primeiro usuário real.

Eles têm um denominador comum: você está entregando ao modelo decisões que deveriam ficar com você. Vibecoding não é “o modelo faz por mim”, é “o modelo escreve, eu decido”. Quando essa linha se apaga, a velocidade vira dívida.

TL;DR

Cinco antipadrões que destroem um projeto: (1) sem spec, com prompts vagos: escreva uma descrição curta de entradas, saídas e restrições antes de pedir código; (2) aceitar código sem ler: leia cada linha como se estivesse fazendo review; (3) pular os testes porque “funciona”: teste o risco, não porcentagens; (4) context rot: passe só os arquivos relevantes e comece sessões novas; (5) megaprompts: divida em passos pequenos e verificáveis. A cura em comum: mantenha as decisões com você e entregue ao modelo só a digitação.