Claude Code: 12 dicas para errar menos e gastar menos

A maior diferença no Claude Code não vem de prompts mágicos. Vem de dizer o que ele não consegue ver, dar um jeito de ele verificar o próprio trabalho e bloquear de verdade o que nunca pode acontecer. Estas dicas partem das boas práticas oficiais, conferidas em 31 de outubro de 2026. A ferramenta muda rápido, então alguns comandos podem variar na sua versão.

Antes de começar

1. Seja específico sobre o que só você sabe. O Claude lê o código, mas não adivinha o sintoma nem o que conta como resolvido.

# em vez de: "corrija o bug do login"
o login falha depois que a sessão expira. veja a renovação do token
em src/auth/, escreva um teste que reproduza o erro e depois corrija

2. Peça ambição quando quiser mais. Por padrão, ele tende a fazer o mínimo que atende ao pedido. A própria documentação sugere dizer be ambitious e listar o que entra: estados vazios, erros, navegação por teclado. Já “pense passo a passo” é só texto comum; quem controla o raciocínio é o nível de esforço.

3. Deixe ele entrevistar você. Quando a ideia ainda está crua, peça isso e comece a construção em uma sessão nova, com o contexto limpo:

quero limitar o uso da API pública, mas não pensei nos detalhes.
me entreviste até poder escrever a especificação em SPEC.md

4. Mantenha o CLAUDE.md curto. Ele é carregado em toda sessão. Coloque só o que o código não mostra: comandos de teste, decisões do time, armadilhas e o que você já corrigiu duas vezes. Comece com /init e vá cortando; a recomendação é ficar abaixo de 200 linhas. Procedimentos longos, como fazer uma release, vão melhor em uma skill, lida só quando necessária.

Durante o trabalho

5. Dê uma verificação que passe ou falhe. Sem isso, você vira o teste. Pode ser um teste, o build, o linter ou uma captura de tela. Peça sempre a evidência: o comando que rodou e a saída, porque “todos os testes passaram” sozinho diz pouco.

6. Acompanhe o primeiro minuto e use o Esc. Esc interrompe mantendo o trabalho feito. /rewind volta o código e a conversa a um ponto anterior, o que torna seguro tentar o caminho mais ousado. Os checkpoints não cobrem arquivos alterados só por comandos de terminal, então continue usando o git.

7. Depois de duas correções, recomece. Uma terceira tentativa só soma erros à conversa. Rode /clear e escreva um prompt novo com o que você aprendeu.

8. Ajuste o esforço conforme a tarefa. /effort low para rascunhos e renomeações, /effort high para bugs em código desconhecido e mudanças de banco. Guarde max para problemas difíceis: em tarefas comuns, ele costuma custar mais sem melhorar a resposta.

O que precisa ser garantido

9. O que não tem exceção não vai no CLAUDE.md. O CLAUDE.md é uma orientação, e o modelo pode decidir que ela não se aplica. Regra sem exceção vira hook ou regra de permissão, porque quem aplica é a ferramenta. Este exemplo, em .claude/settings.json, bloqueia a leitura de segredos, pede confirmação antes de um push e não deixa o Claude terminar com erro de tipo:

{
  "permissions": {
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.local)", "Read(./secrets/**)"]
  },
  "hooks": {
    "Stop": [{
      "hooks": [{ "type": "command", "command": "pnpm tsc --noEmit 1>&2 || exit 2" }]
    }]
  }
}

Regra de bloqueio não é um cofre: um script que abra o arquivo escapa dela. Para um limite no sistema operacional, ative o /sandbox. Mantenha a lista pequena, porque cada regra também dá manutenção.

10. Crie um revisor que não pode editar. Um subagente que não viu a conversa revisa sem o viés de quem escreveu. Use só ferramentas de leitura e peça para ignorar estilo, ou ele sempre vai achar alguma coisa. Em .claude/agents/reviewer.md:

---
name: reviewer
description: Revisa os arquivos alterados contra a especificação.
tools: Read, Grep, Glob
---
Compare as mudanças com a especificação recebida, confira se os casos
previstos têm testes e relate só o que afeta o funcionamento. Ignore estilo.

Custo e trabalho sem supervisão

11. Olhe o /usage e limpe entre tarefas. Cada pedido reenvia a conversa inteira. /clear entre assuntos diferentes não custa nada, e o /usage mostra o que está consumindo mais. Subagentes ajudam, mas gastam da mesma cota; para trabalho simples, defina model: haiku. Desligue também os servidores MCP que não usa, pois eles ocupam contexto mesmo parados.

12. Antes de deixar rodando sozinho, responda cinco perguntas. Ele sabe como é o “pronto”? Consegue verificar o próprio trabalho? O que pode tocar? O que o faz parar? Quem aprova o resultado? Em scripts, coloque um teto:

claude -p "corrija os testes de tests/auth" --max-turns 30 --max-budget-usd 5

O ideal é que o resultado termine em um pull request que uma pessoa aprova. Quanto a usar sem nenhum limite: o modo bypassPermissions só faz sentido em um contêiner descartável.

Comparando com outros agentes? Veja nosso guia de Hermes, OpenClaw e Grok.