Claude Code: o que é, o que ele faz no seu projeto e o que continua sendo trabalho seu

Fala aí, beleza? Todo mundo já ouviu falar do Claude Code, mas a dúvida real é outra: isso troca alguma etapa do meu dia ou é só mais uma janela aberta?

Então vamos pelo recorte que interessa: divisão de trabalho

De um lado, o que o agente resolve sozinho dentro do repositório

Do outro, o que continua na sua mão, porque nenhuma ferramenta assume por você

Se liga que a segunda lista é curta, mas ela é a que decide se você vai ganhar tempo ou só ganhar retrabalho 🙂

O que o Claude Code consegue fazer dentro do seu projeto

A definição oficial é direta: uma ferramenta de codificação agentic que lê a base de código, edita arquivos, roda comandos e se integra às ferramentas de desenvolvimento

E ele não vive só no terminal, não. Roda em CLI, IDE, app desktop e navegador

Na prática, isso vira alguns usos bem concretos:

• Ler o projeto inteiro antes de mexer: ele não depende de você colar arquivo por arquivo no chat, ele vai atrás do contexto no próprio repositório
• Editar arquivos e rodar comandos: o ciclo de mexer, executar e olhar o resultado acontece dentro da sessão
• Trabalhar direto com git: prepara (stage) as mudanças, escreve a mensagem de commit, cria branch e abre pull request. Isso já é uma etapa inteira do seu dia, e vale a pena pensar até onde delegar o Git antes de soltar a rédea
• Code Review de pull request no GitHub: agentes especializados analisam as mudanças no contexto do codebase inteiro procurando erros de lógica, vulnerabilidades de segurança, edge cases quebrados e regressões sutis. Os achados saem como comentários inline marcados por severidade, e (importante!) ele não aprova nem bloqueia o PR sozinho
• MCP para puxar dado de fora: o Model Context Protocol é um padrão aberto que permite ler docs no Google Drive, atualizar tickets no Jira, puxar dados do Slack ou plugar tooling próprio
• Subagentes: dá pra delegar pesquisa sem poluir o contexto principal, e o subagente pode até criar subagentes dele

Repara no padrão: tudo aí é execução

Ler, editar, rodar, versionar, buscar contexto

O que ele NÃO faz sozinho é decidir quando o trabalho está de fato pronto…

O que continua sendo trabalho seu

Essa é a parte que ninguém coloca no anúncio, e é a que mais muda o resultado

A própria documentação de boas práticas fala isso na lata: o Claude para quando o trabalho parece pronto

Parece. Não está

Definir a checagem executável

A recomendação é dar ao Claude uma checagem que ele mesmo possa rodar: testes, build, um screenshot pra comparar

Sem isso, "parece pronto" é o único sinal disponível na mesa, e cada erro fica esperando você notar

Ou seja: sem checagem, VOCÊ vira o loop de verificação

E aí não tem ganho nenhum, tu só trocou escrever código por caçar bug alheio

Exigir evidência, não afirmação

Aqui vai o ajuste mais barato de todos: em vez de aceitar "pronto, corrigido", peça a saída dos testes, o comando que ele rodou e o que aquilo retornou, ou um screenshot do resultado

Revisar evidência é mais rápido que refazer a verificação do zero

E isso é decisão sua, não configuração dele

Segurar a mão nos testes

O fluxo recomendado é instruir o Claude a escrever código que passe nos testes SEM modificar os testes

E seguir iterando: escreve, roda, ajusta, roda de novo, até tudo passar

Tome cuidado! Se você não disser isso, o caminho mais curto pro "verde" às vezes passa por mexer no teste, e aí o verde não significa mais nada

Julgar o plano e o nível de autonomia

Qual modo de permissão a sessão assume, se o plano proposto faz sentido pro seu projeto, qual stack entra: isso é julgamento de quem programa

O agente executa muito bem uma direção. Ele não escolhe a direção por você

Como controlar o que ele faz: plan mode e modos de permissão

Agora a parte prática, porque essa divisão de trabalho não é filosofia, é botão

1. Entre no plan mode antes de qualquer coisa: nesse modo o Claude lê arquivos, roda comandos de exploração e escreve um plano, mas não edita o código-fonte. Ativa com Shift+Tab ou prefixando o seu prompt com /plan
2. Leia o plano de verdade: é aqui que sai barato discordar. Corrigir rumo no texto custa um parágrafo, corrigir depois custa um diff inteiro
3. Decida o modo de permissão ANTES de aprovar: aprovar o plano tira a sessão do plan mode e troca ela para o modo de permissão escolhido. O erro comum deste passo é justamente esse: gente que aprova no impulso e só descobre o nível de autonomia depois que os arquivos já mudaram
4. Escolha entre os modos disponíveis: no Manual ele pergunta antes de editar arquivos e antes de rodar comandos de shell. No Accept edits ele edita arquivos e roda comandos comuns de filesystem (tipo mkdir e mv) sem perguntar. Além desses, existem ainda o auto mode e o dontAsk

Regra de bolso que eu uso: projeto que eu conheço mal começa em plan mode e termina em Manual

Projeto meu, com teste rodando e git limpo, aguenta mais folga

Como dar contexto do projeto: CLAUDE.md, skills e MCP

O agente é bom lendo código. Ele não adivinha convenção que só existe na sua cabeça

Então essa configuração aqui é trabalho seu, e é o que separa resposta genérica de resposta que parece do time:

1. Crie um CLAUDE.md na raiz do projeto: é um arquivo markdown que o Claude Code lê no início de cada sessão. Serve pra padrões de código, decisões de arquitetura, bibliotecas preferidas e checklists de revisão

# CLAUDE.md

## Padrões
- Componentes novos: reutilizar o que já existe antes de criar
- Sem dependência nova sem justificativa no PR

## Checklist de revisão
- Rodar os testes e colar a saída
- Não alterar arquivos de teste pra fazer passar

2. Escreva ali o que você cansa de repetir: se toda sessão você explica a mesma convenção, ela pertence ao arquivo. Esse é, inclusive, o caminho pra fazer o Claude Code respeitar o design system em vez de inventar componente do nada
3. Monte suas skills pessoais: elas ficam em ~/.claude/skills/<nome-da-skill>/SKILL.md e valem pra todos os projetos. O SKILL.md começa com um bloco YAML entre --- contendo name e description, e depois vêm as instruções em Markdown

---
name: revisao-pr
description: Checklist de revisão antes de abrir pull request
---

Antes de abrir o PR, rode os testes e cole a saída
Descreva o que mudou em uma frase por arquivo tocado

4. Use skills por projeto quando fizer sentido: o Claude Code também carrega de diretórios .claude/skills/ aninhados abaixo do diretório de trabalho
5. Saiba a ordem de precedência: quando existe skill de mesmo nome em níveis diferentes, enterprise sobrepõe pessoal, e pessoal sobrepõe projeto. O erro comum deste passo é criar uma skill no projeto achando que ela ganha da sua skill pessoal, e ela não ganha. Skills de plugin usam namespace plugin-name:skill-name e não entram nesse conflito
6. Conecte o que está fora do repositório via MCP: docs no Drive, ticket no Jira, dado no Slack, tooling seu

E tem um detalhe que salva contexto: as skills carregam sob demanda, só quando o Claude julga que são relevantes

Assim o tooling super específico não fica ocupando espaço em tarefa que não tem nada a ver

Como foi na prática: do plano no NotebookLM ao app no Claude Code

No vídeo eu mostro um fluxo em que essa divisão de trabalho fica escancarada: o NotebookLM vira o especialista do produto e o Claude Code fica com a construção

Um define O QUE construir, o outro escreve o projeto

Hoje, na minha avaliação, o Claude Code é a melhor alternativa pra programar, e foi exatamente por isso que troquei a ferramenta que eu usava antes nesse mesmo fluxo

A razão de existir a etapa de pesquisa é simples: pedir o projeto direto pra IA, sem pesquisar antes, tende a gerar apps muito parecidos uns com os outros, sem diferencial nenhum

E olha quanta coisa continuou na minha mão ali:

• Curadoria de fonte: depois da busca eu entro em cada fonte pra ver se faz sentido, porque fonte ruim piora a resposta
• Condução da conversa: eu fico batendo papo com o NotebookLM até sentir que ele entendeu o produto, e vou salvando o que interessa em observações, porque o histórico da conversa se perde
• Repetir quando sai raso: o primeiro prompt gerado saiu pouco detalhado, e eu pedi de novo, com a configuração de resposta mais longa ligada
• Escolher o formato de entrega: troquei a estratégia de prompt gigante por um PRD salvo em arquivo, porque prompt muito grande pode fazer o Claude Code deixar coisa de fora, e o arquivo eu referencio depois quantas vezes quiser
• Preparar o arquivo: criei um prd.md dentro do projeto com o conteúdo colado do NotebookLM, tirando a primeira linha de resposta da ferramenta antes de salvar
• Decidir a stack: React, Tailwind, shadcn e Supabase como banco, definido por mim antes de mandar pra IA, em vez de deixar a escolha na mão da ferramenta

Aí sim eu abri o Claude Code numa pasta em branco, iniciando com a opção que dispensa os pedidos de permissão, e deixei ele construir a partir do documento

Detalhe pequeno que eu faço de propósito: escolho o nome do notebook parecido com o nome do projeto, porque acredito que isso melhora as respostas

E a V1 eu trato como MVP mesmo: precisa ir pro mercado e voltar pro ciclo, com pergunta nova, prompt novo e nova iteração no Claude Code

No vídeo tu acompanha o caminho inteiro: a pesquisa virando PRD, o arquivo entrando no projeto e o app sendo construído em cima dele

Como instalar e começar a usar o Claude Code

Instalação é a parte fácil, é quase next, next e finish

1. macOS ou Linux: roda o instalador nativo

curl -fsSL https://claude.ai/install.sh | bash

2. Windows: mesma ideia, no PowerShell

irm https://claude.ai/install.ps1 | iex

3. Prefere gerenciador de pacote? Tem Homebrew e WinGet

brew install --cask claude-code

winget install Anthropic.ClaudeCode

4. Cuidado com o caminho do npm: o npm install -g @anthropic-ai/claude-code está depreciado. O erro comum deste passo é seguir tutorial antigo e cair nele sem perceber. Se por algum motivo você usar essa via, ela pede Node.js 18+ e não deve rodar com sudo
5. No Windows nativo, instale o Git for Windows: ele é recomendado pro Claude Code usar a ferramenta Bash. Sem ele, o shell usado é o PowerShell
6. Entre no diretório do projeto e rode o comando

cd meu-projeto
claude

7. No VS Code, escolha como quer usar: existe extensão do VS Code com painel gráfico e existe o CLI. Pra rodar o CLI dentro do editor, é só abrir o terminal integrado e chamar claude
8. Esquece a rotina de update: instalações nativas se atualizam sozinhas em segundo plano pra manter a última versão

A referência oficial de instalação e do projeto fica no repositório claude-code, vale deixar salvo

Planos que dão acesso ao Claude Code

Antes de instalar, checa se o seu plano cobre, porque nem todo plano cobre:

Duas notas que evitam confusão:

Com Pro e Max, o acesso ao Claude na web, desktop e mobile e ao Claude Code no terminal vem na MESMA assinatura, não são duas cobranças

E isso não quer dizer que o Claude Code fique preso ao terminal nesses planos: o acesso ao Claude Code pelo app desktop do Claude está disponível pra usuários Max, Pro, Team e Enterprise

Vale trocar alguma etapa do seu dia pelo Claude Code?

Veredito honesto, sem hype

Vale muito se você já tem repositório de verdade e consegue responder rápido a pergunta: "qual comando prova que isso funcionou?"

Teste, build, screenshot de comparação, qualquer coisa executável

Quem tem isso pronto ganha as etapas mais chatas: varrer o codebase, aplicar a mudança repetitiva, preparar commit e branch, revisar PR com um segundo par de olhos que enxerga o projeto inteiro

Agora, se o seu projeto não tem NENHUMA forma de verificação automática, a conta muda

Porque o agente para quando o trabalho parece pronto, e sem checagem executável o "parece pronto" é o único sinal que sobra

Aí você não delegou trabalho, você virou o loop de verificação de código que não escreveu… e isso é pior que fazer na mão

O ganho não depende do agente achar que terminou

Depende de você conseguir provar que terminou

Conclusão

A divisão fica assim: o Claude Code lê o codebase, edita arquivos, roda comandos, cuida do git, revisa PR e puxa contexto externo via MCP

Você fica com o que ninguém delega: definir a checagem executável, exigir evidência em vez de afirmação, proibir mexer nos testes e escolher o nível de autonomia da sessão

Se for começar hoje, faz nessa ordem: instala, entra na pasta do projeto, roda claude, começa em plan mode e escreve o primeiro CLAUDE.md ANTES de liberar edição

É meia hora de configuração que muda o resto da sua relação com a ferramenta 😀

Até o próximo post!