Mestre do Claude
Voltar pro blog
4 min de leitura

7 erros comuns no Claude Code (e como evitar cada um)

Os erros que mais fazem iniciantes perder tempo e dinheiro no Claude Code — e o ajuste certo pra cada um. Em pt-BR, com comandos e exemplos práticos.

7 erros comuns no Claude Code (e como evitar cada um)

Tem uma frase que eu ouço toda semana: "experimentei o Claude Code e não gostei, ele fez besteira". Quase sempre, quando a pessoa mostra o que aconteceu, o problema não era o Claude — era o jeito de usar. Os mesmos cinco ou seis erros se repetem.

A boa notícia é que todos têm conserto simples. Listei os 7 que mais fazem iniciante perder tempo (e dinheiro), com o ajuste certo pra cada um. Se você está começando, ler isso aqui economiza semanas de frustração.

1. Soltar o Claude num projeto sem Git

Esse é o erro mais perigoso, e o que mais assusta quando dá errado. Você pede uma mudança, o Claude edita cinco arquivos, e de repente algo que funcionava parou. Sem Git, você não tem como saber o que mudou nem como voltar atrás.

Com Git, é só um susto. Antes de começar, garanta que o projeto está versionado:

git init
git add -A
git commit -m "estado inicial"

Aí, sempre que o Claude fizer algo, você revê com git diff e desfaz com um comando se não gostou. Git é a sua rede de segurança. Nunca trabalhe sem ela.

2. Pular o /init (e deixar o Claude no escuro)

Sem contexto, o Claude chuta. Ele não sabe se você usa npm ou pnpm, se o padrão é TypeScript, qual a estrutura de pastas. Aí "inventa" — e você acha que ele alucina, quando na verdade ninguém contou pra ele as regras da casa.

O conserto leva 30 segundos. Em todo projeto novo, rode:

/init

Ele lê o projeto e cria um CLAUDE.md — o manual que ele relê em toda conversa. A partir daí, ele já sabe a stack e as convenções sem você repetir. Se quiser entender melhor como esse arquivo funciona, eu detalho no guia do Claude Code no terminal.

3. Pedir vago e esperar mágica

"Arruma isso." "Melhora esse código." "Tá com bug, resolve." Pedido vago obriga o Claude a adivinhar — e adivinhação vira retrabalho.

A diferença entre uma resposta ruim e uma ótima quase sempre está no pedido, não no modelo. Compare:

  • ❌ "o login não funciona, conserta"
  • ✅ "no login.js, o botão de entrar não chama a API quando o email tem maiúscula. Espera-se que normalize pra minúscula antes de enviar. Mostra o teste passando."

Diga o arquivo, o comportamento esperado e como saber que deu certo. Quanto mais específico, menos idas e vindas.

4. Não usar o plan mode em tarefa grande

Pra mudança grande — "cria um sistema de login", "refatora o módulo inteiro" — deixar o Claude sair editando direto é pedir pra ele ir longe demais na direção errada. Você só descobre depois de 15 arquivos mexidos.

Antes de tarefas grandes, ative o plan mode com Shift + Tab. O Claude planeja primeiro e te mostra os passos antes de tocar em qualquer arquivo. Você aprova, ajusta ou descarta — gastando quase nada. É o ponto onde você corrige o rumo barato, em vez de caro.

5. Dar "Allow always" em tudo

Os pop-ups de permissão cansam, e a tentação é liberar tudo pra sempre. O problema: você também libera comandos que apagam e sobrescrevem sem perguntar.

A regra de bolso:

  • Pode liberar sem medo — ler arquivos, listar pastas, rodar testes.
  • Pense duas vezesrm, del, git reset --hard, git push --force, mover/renomear em massa.

Libere o que é seguro pra parar de ver pop-up à toa, mas mantenha a confirmação no que é destrutivo. Essa última pergunta é, várias vezes, o que te salva.

6. Deixar a conversa virar bola de neve

O Claude relê todo o histórico a cada mensagem. Uma conversa que começou sobre o login e foi parar no deploy carrega tudo isso o tempo todo: fica lenta, cara e o Claude começa a misturar assuntos.

Dois comandos resolvem:

/clear     # zera o contexto ao trocar de assunto
/compact   # resume a sessão longa sem perder o fio

Use /clear sempre que mudar de tarefa. Conversa enxuta responde mais rápido, gasta menos e erra menos. Esse é só um dos ajustes — tem vários outros no post sobre como gastar menos tokens no Claude.

7. Confiar cego no resultado (e não revisar o diff)

O Claude erra, como qualquer ferramenta. O erro não é ele errar — é você aceitar sem olhar. Quem dá "aceita tudo" e segue em frente acumula bugs silenciosos que aparecem semanas depois, difíceis de rastrear.

Crie o hábito de revisar antes de seguir:

git diff

Leia o que mudou. Não precisa entender cada linha, mas bata o olho: era isso que você pediu? Mexeu em arquivo que não devia? Dois minutos de revisão evitam horas de caça ao bug. Você continua no comando — o Claude é o copiloto, não o piloto.

O padrão por trás de todos eles

Repare que os 7 erros têm a mesma raiz: largar o controle. Sem Git, sem contexto, sem plano, sem revisão. O Claude Code brilha quando você dá direção e mantém as rédeas — e decepciona quando você espera que ele adivinhe tudo sozinho.

Se for guardar um checklist, fica este:

  1. Git versionado antes de começar.
  2. /init em todo projeto novo.
  3. Pedido específico: arquivo, comportamento, como testar.
  4. Plan mode nas tarefas grandes.
  5. Permissão liberada só no que é seguro.
  6. /clear ao trocar de assunto.
  7. git diff antes de aceitar.

Faça isso virar hábito e o Claude Code deixa de "fazer besteira" e vira o que ele é de verdade: o ajudante mais rápido que você já teve. Se ainda nem instalou, comece por aqui.

Bom Claude pra você.

Perguntas frequentes

O Claude Code apagou ou quebrou meu código. Como recupero?

Se o projeto está no Git, é tranquilo: rode git diff pra ver o que mudou e git checkout -- <arquivo> (ou git restore <arquivo>) pra desfazer um arquivo, ou git reset --hard pra voltar tudo ao último commit. Por isso a regra número um é versionar com Git ANTES de soltar o Claude no projeto. Sem Git, não há rede de segurança e a recuperação fica difícil.

Por que o Claude erra ou inventa coisas no meu projeto?

Quase sempre é falta de contexto ou pedido vago. Sem um CLAUDE.md ele não conhece sua stack e suas convenções, então chuta. E um pedido como 'arruma isso' obriga ele a adivinhar o que é 'isso'. Rode /init pra criar o CLAUDE.md e seja específico: diga o arquivo, o comportamento esperado e como testar.

Por que minhas respostas ficam lentas e caras com o tempo?

Porque a conversa vira uma bola de neve: o Claude relê todo o histórico a cada mensagem. Use /clear ao trocar de assunto e /compact pra resumir uma sessão longa. Conversa enxuta responde mais rápido e gasta menos.

Devo dar 'Allow always' pra tudo pra parar de ver pop-up?

Não. Liberar leitura de arquivos é tranquilo, mas dar Allow always em comandos que apagam ou sobrescrevem (rm, del, git reset, git push --force) tira sua última chance de revisar. Libere o que é seguro e mantenha confirmação no que é destrutivo.


Curtiu? Receba os próximos por email.

Sem spam, sem newsletter chata. Só o que vale.

Cadastrar email