Anti-Patterns — Erros Comuns ao Usar IA no Desenvolvimento

Os 12 erros mais comuns que desenvolvedores cometem ao usar IA para código. Como identificar e corrigir cada um deles.

Usar IA errado é pior que não usar. Estes são os anti-patterns mais comuns documentados em 2025-2026, com base em experiência real de equipes e no post-mortem da Anthropic.

Os 12 anti-patterns

1. Vibe Coding (codar por vibração)

O que é: pedir código sem spec, sem teste, sem revisão. "Se funciona, tá bom."

Por que é perigoso: código que funciona em ambiente de desenvolvimento mas falha em produção, tem bugs sutis, ou é inseguro.

Correção: sempre escreva specs primeiro, testes depois, implementação por último.

2. Prompt gigante

O que é: colocar tudo em um único prompt de 2.000 tokens.

Exemplo ruim:

Implemente autenticação, billing, notificações, dashboard,
relatórios, exportação PDF, integração WhatsApp, webhooks,
e atualize a documentação. Use JWT, Stripe, N8N, Puppeteer.
Escreva testes para tudo. Faça deploy quando terminar.

Correção: uma tarefa por prompt. Divida em subtarefas e execute sequencialmente.

3. Contexto infinito

O que é: manter a mesma sessão por horas acumulando contexto.

Por que é perigoso: após ~170k tokens, a qualidade degrada silenciosamente. O modelo "esquece" instruções do início.

Correção: fresh context a cada 30-60 minutos. Salve estado em arquivos.

4. Aceitar sem revisar

O que é: confiar cegamente no output da IA.

Por que é perigoso: a IA gera código que "parece certo" mas pode ter bugs sutis, vulnerabilidades, ou divergir da spec.

Correção: sempre revise. Use checklist de segurança + comportamento + qualidade.

5. Testes como afterthought

O que é: implementar primeiro, testar depois (ou nunca).

Por que é perigoso: sem testes, o agente não tem back-pressure. Gera código que "funciona nos casos óbvios".

Correção: TDD — testes primeiro, implementação depois.

6. Over-prompting

O que é: adicionar "É MUITO IMPORTANTE que você use X" ou "CRITICAL: ALWAYS do Y" quando o modelo já faz isso naturalmente.

Por que é perigoso: consome context window com instruções redundantes. Em alguns casos, pode confundir o modelo.

Correção: confie no modelo. Instrua apenas o que é específico do seu projeto.

7. Ignorar effort levels

O que é: não configurar o nível de esforço computacional.

Impacto: tarefas complexas com low effort = código incompleto. Tarefas simples com max effort = desperdício de tokens.

Correção: xhigh para coding, high para moderado, low para trivial.

8. Specs mutáveis sem re-validação

O que é: mudar a spec mas não re-rodar testes nem re-gerar código.

Por que é perigoso: código e spec divergem. Ninguém sabe qual é a verdade.

Correção: ao mudar spec, regenere fix_plan.md e re-valide com testes.

9. Não salvar estado

O que é: depender do context window para manter progresso.

Por que é perigoso: se a sessão termina ou o contexto é compactado, o progresso é perdido.

Correção: salve em progress.txt, fix_plan.md, context.md.

10. Uma spec para tudo

O que é: uma spec de 500 linhas cobrindo toda a aplicação.

Por que é perigoso: consome 30% do context window. O modelo perde foco.

Correção: specs < 200 linhas por módulo. Divida em arquivos.

11. Mudar system prompt sem ablação

O que é: alterar CLAUDE.md, rules ou hooks sem testar o impacto.

Referência: o incidente de Abr/2026 da Anthropic — a constraint "≤25 words between tool calls" reduziu qualidade de coding em 3%.

Correção: teste mudanças em sessões curtas antes de aplicar globalmente.

12. Ignorar o "digital smell"

O que é: aceitar código que parece "diferente" do estilo do projeto.

Referência: Andrew Kelley (Zig) — código gerado por IA é identificável e quebra pipelines de contribuição.

Correção: configure rules e hooks para manter estilo consistente.