Como Eu Realmente Uso o Claude Code (Depois de 400+ Sessões)

Isso Não É Um Post de Hype

Eu uso o Claude Code há meses em todos os contextos em que trabalho - projetos de agência, apps indie que publico com minha própria marca e experimentos pessoais. Centenas de sessões. Código real de produção. Prazos reais.

A maioria dos textos sobre ferramentas de IA para código cai em dois campos: o evangelismo ofegante do "dev 10x" ou o ceticismo desdenhoso de "só escreve fizzbuzz". Nenhum dos dois bate com a minha experiência. A realidade é mais interessante e mais nuançada do que ambos.

Aqui vai a versão honesta.

O Que Eu Faço vs O Que o Claude Faz

Essa é a coisa mais importante que posso dizer sobre usar ferramentas de IA para código, e é a coisa que a maioria das pessoas entende errado quando me veem usando o Claude Code.

Parece que eu digito um prompt e o computador faz meu trabalho. Não é isso que está acontecendo.

O Que Eu Faço (As Partes Difíceis)

• Investigação do problema - Ler o ticket, reproduzir o bug, entender a causa raiz, explorar o codebase
• Design da solução - Decidir o que construir, como abordar, quais padrões seguir, quais trade-offs aceitar
• Fornecer contexto - Explicar a lógica de negócio, apontar os arquivos certos, descrever edge cases, esclarecer comportamentos
• Guiar a implementação - Revisar o plano do Claude antes de ele escrever uma linha de código, perceber quando ele desvia, redirecionar no meio da tarefa
• Code review - Ler cada linha que o Claude produz, verificar correção, checar se bate com os padrões do time
• Teste manual - Rodar o app, clicar nos fluxos, testar edge cases, verificar contra os requisitos reais
• Julgamento de qualidade - Isso é bom o suficiente? Introduz dívida técnica? É a abstração certa? O time vai entender esse código?

O Que o Claude Faz (As Partes Mecânicas)

• Escrever o código em si - Componentes, funções, estilos, testes baseados na minha direção
• Boilerplate e scaffolding - Setup de arquivos, imports, definições de tipos, estruturas de teste
• Formatação e templates - Descrições de PR, mensagens de commit, documentação repetitiva
• Transformações repetitivas - Renomear em vários arquivos, atualizar padrões, scripts de migração
• Validação de build - Rodar builds, checagem de tipos, linting depois de mudanças

A Proporção

Num ticket típico, a divisão é mais ou menos 70% eu, 30% Claude. Mas aqueles 30% costumavam ocupar 50-60% do meu tempo porque escrever código é lento e tedioso comparado a pensar sobre código.

Esse é o ganho real de produtividade. Não é "a IA faz meu trabalho" - é mais "eu gasto meu tempo nas partes que realmente precisam do julgamento de um dev sênior."

Pense nisso como pair programming onde seu parceiro é um digitador extremamente rápido com boa capacidade de reconhecer padrões, mas sem senso de produto, sem julgamento sobre trade-offs, e com tendência a fazer a coisa errada com confiança se você parar de prestar atenção.

O Setup Que Faz Funcionar

Depois de meses de iteração, cheguei num sistema com cinco camadas. Os detalhes técnicos aqui são específicos do Claude Code, mas os princípios se aplicam a qualquer ferramenta de IA para código.

Camada 1: Regras Globais

Um arquivo de configuração global que se aplica a todo projeto. É aqui que minhas regras invioláveis moram - coisas que nunca devem acontecer independente do contexto.

# Regras Invioláveis

## Comandos Git Destrutivos São Proibidos
Nunca executar sem permissão explícita:
- git checkout -- em qualquer arquivo
- git restore em qualquer arquivo
- git reset em qualquer forma
- git clean

Não reverta mudanças não commitadas por nenhuma razão.
Reporte o problema e pergunte como proceder.

## Segurança de Arquivos
Nunca delete arquivos sem mover para um lugar seguro primeiro.
Pergunte antes de deletar qualquer coisa não rastreada no git.

## Honestidade Sobre Código Não Testado
Não diga que o código funciona se não foi executado.
Sempre diga: "Eu não testei isso ainda."

Cada uma dessas regras existe porque perdi trabalho ou tive que consertar uma bagunça. Mais sobre isso em breve.

Camada 2: Consciência do Workspace

Eu trabalho em vários repositórios - clientes de agência, produtos indie, projetos pessoais. Uma config no nível do workspace diz ao Claude como os diretórios estão organizados para ele não confundir um projeto com outro.

## Estrutura de Diretórios
code/
├── work/agency/        # Projetos de clientes (vários repos)
├── indie/              # Meus próprios produtos (workspace compartilhado)
└── personal/           # Experimentos e site pessoal

Detalhe pequeno, mas evita que o Claude referencie padrões do Projeto A quando está trabalhando no Projeto B.

Camada 3: Convenções do Time

No meu trabalho de agência, existe uma camada que codifica os padrões específicos do time:

## Template de Pull Request
Todos os PRs devem seguir o template padrão:
- Link do ticket
- Resumo (Problema / Solução / Como funciona)
- Passos de Teste / QA
- Critérios de Aceitação
- Checklist do Autor

## Códigos do Sistema de Tickets
| Time | Código | Exemplo |
|------|--------|---------|
| Cliente A | CLI-A | CLI-A-123 |
| Cliente B | CLI-B | CLI-B-45 |

Isso significa que quando eu crio um PR, o Claude já sabe o formato, a convenção de link do ticket e a estrutura do time. Sem precisar reexplicar a cada sessão.

Camada 4: Contexto Específico do Projeto

Cada projeto tem sua própria config com arquitetura, comandos de build e foco atual:

## Arquitetura
- Next.js 14 com App Router
- Sanity CMS v3 para gestão de conteúdo
- Módulos SCSS com mixins compartilhados
- i18n com 5 locales suportados
- ISR com revalidação de 60s

## Comandos de Build
- Build: npm run build
- Types: npx tsc --noEmit
- Lint: npm run lint

## Foco Atual
- Migração de CMS (94% completa)
- Refactor de navegação
- Integração de reservas com terceiros

Camada 5: Memória Entre Sessões

O Claude Code pode persistir aprendizados entre sessões. Quando ele descobre um padrão ou eu corrijo um erro, ele lembra na próxima vez. Isso se acumula ao longo de semanas - cada sessão começa um pouco mais inteligente sobre o projeto que a anterior.

Por Que as Camadas Importam

Quando abro o Claude Code num projeto de cliente, ele carrega automaticamente: minhas regras de segurança + consciência do workspace + convenções do time + arquitetura do projeto + aprendizados anteriores. Sem preâmbulo, sem reexplicar. Retomamos de onde paramos.

O investimento inicial em escrever essas configurações se paga a cada sessão.

Coisas Que Deram Errado (E as Regras Que Elas Criaram)

Prometi honestidade. Aqui vai.

O Claude Deletou Meu Código em Andamento

No começo, o Claude decidiu "limpar" arquivos que considerou não utilizados. Removeu código em andamento que ainda não tinha sido commitado. Foi-se.

A regra que isso criou: Nunca deletar arquivos sem mover para /tmp primeiro. Nunca rodar comandos git destrutivos sem permissão explícita. Nunca reverter mudanças não commitadas por nenhuma razão.

Agora tenho isso no topo de toda config do workspace, em negrito, em caixa alta:

# AVISO CRÍTICO
NUNCA DELETE ARQUIVOS OU REVERTA MUDANÇAS SEM SER SOLICITADO.

Sutil não é. Mas funciona.

O Claude Disse Que o Código Funcionava Quando Não Funcionava

O Claude vai dizer "isso deve funcionar" com confiança absoluta sem ter executado uma única linha. Ele escreve código que parece correto, que se lê como correto, mas que quebra de formas que você só descobre quando roda.

A regra que isso criou: O Claude deve sempre dizer "Eu NÃO testei isso - por favor rode para verificar." Deve avisar sobre suposições: "Isso assume que X existe." Nunca deve dizer que o código está "pronto" ou "completo" sem execução.

Essa é talvez a lição mais importante para qualquer pessoa usando ferramentas de IA para código: escrever código e testar código são coisas diferentes. O Claude é bom em escrever. Ele não consegue testar. Você ainda tem que verificar tudo.

O Claude Fez Push Sem Perguntar

Autoexplicativo. Agora existe uma regra: nunca fazer push para o remoto sem permissão explícita.

O Claude Adicionou Atribuição de IA nos Commits

Não quero "Co-Authored-By: Claude" ou "Gerado com IA" no meu histórico de commits. O código é meu - eu projetei a solução, revisei cada linha e assumo a responsabilidade. O Claude digitou mais rápido do que eu teria digitado. Isso não muda a autoria.

A regra: Nenhuma atribuição de IA em commits, PRs ou qualquer output.

Comandos Customizados: Codificando Workflows

Além de configuração, criei 11 comandos customizados que mapeiam pro meu workflow real. São arquivos markdown que definem um processo de múltiplos passos que o Claude segue.

O Workflow de Ticket

Meu comando mais usado pega um ID de ticket e fornece estrutura para o ciclo inteiro de implementação:

/do-ticket PROJ-123

O fluxo:

1. Coleta de Contexto - O Claude explora o codebase. Eu forneço o contexto de negócio, explico o problema, aponto os arquivos relevantes e esclareço os critérios de aceitação.

2. Planejamento - O Claude propõe uma abordagem. Eu reviso, questiono coisas que não vão funcionar, sugiro alternativas e aprovo ou redireciono antes de qualquer código ser escrito.

3. Implementação - O Claude escreve código em commits atômicos. Eu estou acompanhando - lendo diffs, pegando problemas, corrigindo o curso: "Não, use URL params e não state local - precisa ser compartilhável." "Use o hook existente de shared/ em vez de criar um novo." "A query está sem um filtro, vai puxar dados errados."

4. Validação - O Claude roda builds e checagem de tipos. Eu testo manualmente - rodando o app, verificando a UI, testando edge cases, conferindo contra os requisitos reais.

5. Preparação de PR - O Claude gera o PR a partir do template do time. Eu reviso e edito antes de criar.

O comando fornece estrutura. Eu forneço o julgamento.

Standups Automáticos

/standup

Escaneia todos os meus diretórios de projetos procurando atividade git recente, categoriza em completado/em andamento/bloqueado e gera um standup. Eu edito - o Claude pega os fatos dos commits mas não sabe o que foi realmente difícil ou no que estou bloqueado.

Code Reviews Estruturados

/code-review #234

O Claude passa por um checklist de 40+ pontos: correção, segurança, performance, qualidade de código e padrões específicos do projeto. Mas eu ainda leio o PR. O Claude pega problemas mecânicos que eu poderia perder (imports não usados, tratamento de erro faltando). Eu pego coisas que o Claude não consegue julgar - essa abordagem faz sentido pro produto? É a abstração certa? O time vai entender?

As duas revisões juntas são melhores que qualquer uma sozinha.

Outros Comandos Que Uso Regularmente

Construindo os Seus

Comandos são apenas arquivos markdown. Aqui vai a estrutura mínima:

# Nome do Comando

O que esse comando faz.

## Input
$ARGUMENTS

O que o usuário fornece (ID de ticket, número de PR, etc.)

## Fase 1: Primeiro Passo
O que o Claude deve fazer aqui...

## Fase 2: Próximo Passo
E aqui...

## Lembretes
- Não faça push sem perguntar
- Não modifique arquivos não relacionados
- Diga quando o código não foi testado

Salve no diretório de comandos e ele fica disponível como /nome-do-comando. A barreira de entrada é escrever um arquivo markdown.

Ferramentas Estendidas: Servidores MCP

Servidores MCP (Model Context Protocol) estendem o que o Claude pode acessar além de apenas ler arquivos.

O Que Eu Uso

Automação de navegador - O Claude pode interagir com um app rodando via Playwright. Útil para verificar mudanças de UI, preencher formulários e navegar fluxos programaticamente.

Consulta de documentação - Em vez de depender de dados de treinamento que podem estar desatualizados, o Claude busca documentação atual e específica da versão sob demanda. Quando adiciono "use context7" a um prompt sobre uma API de biblioteca, ele puxa a documentação real em vez de chutar.

Navegação semântica de código - Navegação no nível de símbolos em codebases grandes. "Encontre todos os usos desse tipo" em todo o projeto.

Essas ferramentas não são estritamente necessárias - o Claude funciona bem sem elas. Mas reduzem o número de vezes que preciso dizer "não, essa API mudou na v3, confira a documentação."

Gerenciamento de Permissões

Uso uma allowlist explícita. O Claude só pode rodar comandos que eu pré-aprovei:

Permitido:
  Git: add, commit, log, status, diff, branch
  Build: npm run build, npm test, npm run lint
  Ferramentas: tsc, vitest, playwright test
  GitHub: gh pr, gh issue

NÃO permitido (requer aprovação a cada vez):
  Git: push, operações force, rebase
  Destrutivo: rm, git clean, git reset
  Rede: curl/wget arbitrários

Comecei com "permitir tudo, negar coisas perigosas." Estava ao contrário. Agora permito apenas o necessário. Se o Claude precisa de algo novo, ele pede, eu aprovo uma vez e entra na allowlist.

Overrides por projeto permitem adicionar permissões específicas. Um monorepo usando pnpm ganha comandos pnpm. Um projeto com Docker ganha comandos docker. Cada projeto recebe exatamente o que precisa e nada mais.

O Efeito Sonoro (Sério)

Isso é um detalhe pequeno mas mudou como eu trabalho:

{
  "hooks": {
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "afplay /System/Library/Sounds/Blow.aiff"
      }]
    }]
  }
}

Quando o Claude termina uma tarefa, meu Mac toca um som. Só isso. Mas significa que posso trocar para testes manuais, leitura de tickets ou revisão de PRs enquanto o Claude escreve código, e sei quando voltar para revisar o output. Transforma um processo interativo em assíncrono para as partes pesadas de digitação.

Em Que Eu Uso Isso

Trabalho em três contextos, e o setup se adapta a cada um:

Trabalho de Agência

Aplicações web de grande escala para marcas grandes - restaurantes, plataformas de bem-estar, varejo. Next.js, Sanity CMS, i18n complexo, performance crítica. A camada de convenções do time e automação de templates de PR são essenciais aqui. Tudo precisa ter qualidade de produção e seguir os padrões do time.

Produtos Indie

Apps macOS, ferramentas SaaS, apps mobile sob minha própria marca. Swift/SwiftUI, Electron, React Native, Next.js. O ritmo é mais rápido aqui - estou lançando MVPs, então o foco é chegar a um produto funcional rapidamente. Comandos customizados para workflows de release e submissão na App Store ajudam aqui.

Projetos Pessoais

Experimentos, aprendizado, portfólio. Menos estrutura necessária, mais exploração. O Claude é mais útil aqui para prototipagem rápida - ter uma versão funcional rápido para avaliar se uma ideia vale a pena perseguir.

O sistema de config em camadas significa que a mesma ferramenta se adapta aos três sem eu reconfigurar nada.

Conselho Para Quem Está Começando

Semana 1: O Setup Mínimo Viável

1. Escreva uma config global com suas convenções de git e regras de segurança. No mínimo: não delete arquivos, não faça push sem perguntar, não diga que código não testado funciona.
2. Adicione uma config de projeto ao seu projeto principal com arquitetura e comandos de build.
3. Configure permissões - comece com uma allowlist apenas do necessário.
4. Adicione o hook de som. Confie em mim.

Mês 1: Construa Seu Workflow

1. Escreva um comando customizado para sua tarefa mais repetida (criação de PR é um bom começo).
2. Organize suas configs em camadas - convenções do time numa camada, detalhes do projeto em outra.
3. Preste atenção no que você fica reexplicando ao Claude. Cada explicação repetida é uma melhoria de config esperando acontecer.

A Disciplina Contínua

• Revise cada linha. O Claude é rápido, não correto. Sua revisão é o que torna o código qualidade de produção.
• Teste tudo manualmente. O Claude pode rodar builds mas não consegue julgar se a UI está boa, se o fluxo faz sentido ou se o edge case importa.
• Corrija o curso cedo. Se o plano do Claude parece errado, pare antes de ele escrever 200 linhas na direção errada. Guiar no início é mais barato que consertar depois.
• Atualize suas configs. Quando você corrigir o Claude sobre algo duas vezes, adicione na config para não ter terceira vez.

Avaliação Honesta

Onde o Claude Code genuinamente ajuda:

• Escrever boilerplate e scaffolding (componentes, tipos, estruturas de teste)
• Transformações repetitivas em muitos arquivos
• Formatar PRs, commits e documentação para seguir templates
• Pegar problemas mecânicos em code review (tratamento de erro faltando, imports não usados)
• Buscar e navegar codebases grandes rapidamente
• Escrever as partes diretas de features para que eu possa focar nas partes complicadas

Onde ainda deixa a desejar:

• Julgamento de produto (não sabe o que o usuário realmente precisa)
• Decisões de arquitetura (propõe padrões que parecem limpos mas não se encaixam nas restrições reais)
• Saber quando parar (vai felizmente over-engenheirar uma feature simples se você deixar)
• Testes (pode escrever código de teste mas não consegue verificar comportamento de verdade)
• Respostas confiantemente erradas (vai te dizer que o código funciona quando não funciona, toda vez, a menos que você force o contrário)

O efeito final: Sou mais rápido para entregar. Não porque faço menos - mas porque gasto mais tempo nas partes que precisam de um dev sênior e menos tempo nas partes que são apenas digitação. O padrão de qualidade é o mesmo porque ainda sou eu quem o define.

A Analogia da Serra Circular

Uma serra circular não substitui um carpinteiro. Ela faz cortes mais rápido para que o carpinteiro possa focar no design, nas juntas, nas partes que exigem habilidade e julgamento. Você não daria uma serra circular para alguém que não sabe carpintaria e esperaria bons móveis. E você não diria que a serra construiu a casa.

É assim que eu penso sobre o Claude Code. É uma ferramenta de força. O ofício ainda é meu.

---

Se você quer ver o que estou construindo, confira meus projetos no GitHub ou acompanhe a jornada no LinkedIn.