Como Boris Cherny, criador do Claude Code, usa o Claude Code

• Ele revelou seu ambiente e fluxo de trabalho reais, apresentando uma forma de executar 5 instâncias do Claude em paralelo no terminal e operar mais 5 a 10 na web
• Usa Opus 4.5 with thinking em todo tipo de tarefa; embora seja maior e mais lento, exige menos ajuste e tem ótima capacidade de usar ferramentas, então no fim acaba sendo mais rápido
• Toda a equipe compartilha um único arquivo CLAUDE.md, e cada vez que o Claude se comporta de forma errada, esse conteúdo é adicionado para acumular aprendizado
• A maioria das sessões começa no modo Plan; depois de refinar bem o plano, ele muda para o modo de aceitação automática para concluir tudo de uma vez
• O fator mais importante para aumentar em 2 a 3 vezes a qualidade do resultado final é dar ao Claude um loop de feedback para que ele mesmo valide o trabalho

---

1/ Configuração do ambiente de execução paralela

• Executa 5 instâncias do Claude em paralelo no terminal, numerando as abas de 1 a 5 e usando notificações do sistema para saber quando alguma entrada é necessária

2/ Operação paralela entre web e local

• No claude.ai/code da web, também executa mais 5 a 10 instâncias do Claude em paralelo, junto com o Claude local
• Faz handoff de sessões locais para a web (usando &), ou inicia sessões direto no Chrome, alternando nos dois sentidos com --teleport
• Também usa o app no iOS para iniciar sessões todas as manhãs e várias outras ao longo do dia, verificando depois

3/ Escolha do modelo: Opus 4.5 with thinking

• Usa Opus 4.5 with thinking em todas as tarefas
• É o melhor modelo de programação que ele já usou até agora
• É maior e mais lento que o Sonnet, mas precisa de menos direcionamento (steering) e tem ótima capacidade de usar ferramentas
• Como resultado, quase sempre entrega o resultado final mais rápido do que modelos menores

4/ Acúmulo de conhecimento da equipe com CLAUDE.md

• Mantém um único arquivo CLAUDE.md compartilhado por toda a equipe no repositório do Claude Code
• O arquivo é versionado no git, e toda a equipe contribui várias vezes por semana
• Sempre que o Claude toma uma ação errada, isso é adicionado ao CLAUDE.md para evitar o mesmo erro da próxima vez
• Outras equipes também mantêm seus próprios CLAUDE.md, e cada uma é responsável por mantê-los atualizados

5/ Atualização do CLAUDE.md durante code review

• Durante o code review, marcam @.claude no PR de um colega para adicionar conteúdo ao CLAUDE.md como parte do próprio PR
• Usa a Claude Code GitHub Action(/install-github-action)
• É uma abordagem parecida com o conceito de Compounding Engineering do Dan Shipper

6/ Fluxo de trabalho com modo Plan e aceitação automática

• A maioria das sessões começa no modo Plan (shift+tab duas vezes)
• Quando o objetivo é abrir um PR, ele discute com o Claude no modo Plan até que o plano fique satisfatório
• Depois que o plano é definido, muda para o modo auto-accept edits, e o Claude normalmente conclui tudo em uma única passada (1-shot)
• Um bom plano é realmente importante

7/ Automação de tarefas repetitivas com slash commands

• Usa slash commands para cada fluxo de trabalho de "inner loop" que executa várias vezes por dia
• Isso economiza prompts repetitivos, e o próprio Claude também pode usar esse fluxo
• Os comandos são versionados no git e armazenados no diretório .claude/commands/
• Exemplo: usa o slash command /commit-push-pr dezenas de vezes por dia
  • Inline bash para pré-calcular informações como git status e executar mais rápido, evitando idas e vindas desnecessárias com o modelo

8/ Uso de subagentes

• Usa regularmente vários subagentes
  • code-simplifier: simplifica o código depois que o Claude termina o trabalho
  • verify-app: inclui instruções detalhadas para testes end-to-end com Claude Code
• Assim como os slash commands, a ideia é automatizar os fluxos de trabalho mais comuns executados na maioria dos PRs

9/ Formatação de código com hook PostToolUse

• Usa um hook PostToolUse para cuidar da formatação de código gerada pelo Claude
• O Claude já produz código bem formatado por padrão, e o hook cuida dos 10% restantes, evitando erros de formatação no CI depois

10/ Forma de gerenciar permissões

• Não usa --dangerously-skip-permissions
• Em vez disso, usa /permissions para pré-autorizar comandos bash comuns considerados seguros no ambiente
• Assim, evita prompts de permissão desnecessários
• Na maioria dos casos, isso fica versionado em .claude/settings.json e compartilhado com a equipe

11/ Uso da integração de ferramentas no Claude Code

• O Claude Code usa todas as ferramentas por ele
  • Busca e publica no Slack (usando servidor MCP)
  • Executa consultas no BigQuery (com a CLI bq) para responder perguntas analíticas
  • Busca logs de erro no Sentry
• A configuração do Slack MCP fica versionada em .mcp.json e é compartilhada com a equipe

12/ Como ele lida com tarefas longas

• Em tarefas muito longas, ele escolhe entre três métodos:
  • (a) instruir que, ao terminar, um agente em segundo plano valide o trabalho
  • (b) usar o hook Stop do agente para validação mais determinística
  • (c) usar o plugin ralph-wiggum, criado por Geoffrey Huntley
• No sandbox, usa --permission-mode=dontAsk ou --dangerously-skip-permissions para que o Claude foque no trabalho sem prompts de permissão

13/ Dica mais importante: fornecer um loop de feedback de validação

• O fator mais importante para obter ótimos resultados com o Claude Code é dar ao Claude uma forma de validar o próprio trabalho
• Com esse loop de feedback, a qualidade do resultado final melhora de 2 a 3 vezes
• Ele testa todas as mudanças que chegam ao claude.ai/code com a extensão do Claude para Chrome
  • Abrindo o navegador, testando a UI e repetindo até o código funcionar e a UX ficar boa
• A forma de validação varia conforme o domínio
  • Pode ser algo simples como executar um comando bash
  • Rodar uma suíte de testes
  • Testar o app no navegador ou em um simulador de celular
• É preciso investir para construir esse processo de validação de forma robusta

[wedding]

Como é o criador, imagino que não tenha limite, né..?

[princox]

Acho que as APIs internas da empresa não devem ser ilimitadas; vi um texto dizendo que o próprio produto Claude Code é desenvolvido usando o Claude Code.. haha;;

[cshj55]

Mesmo assim, não corre o risco de ser pego..? É caro..

[elbanic]

Não há restrições para uso na empresa. Eu não sou da Anthropic, mas trabalho em uma big tech, e o Sonnet 4.5 é praticamente ilimitado.

[wegaia]

Sou assinante do Max, mas só de ler já dá a sensação de que os tokens estão sendo consumidos.

[xguru]

Dicas práticas de uso divulgadas pelo criador do Claude Code

[sonlar]

Pontos em comum de skills..

[laeyoung]

2. Operação paralela na web e localmente

Ao ver a imagem do post original, parece que ele trabalha com 5 instâncias localmente e 5 na web. Será que existe algum motivo para dividir em 5 e 5, em vez de simplesmente usar 10 locais e 10 na web?

[agendacho]

Na web, provavelmente parece ser para verificações simples e trabalhos simples na mesma git branch do ambiente local.
(Será para conseguir trabalhar até em deslocamento??)
É só uma suposição, mas, ao criar 5 no ambiente local, imagino que ele use git branch diferente para cada finalidade para gerenciar o contexto,
e cada aba seria, por exemplo:
a aba 1 para geração de consultas de banco de dados e planejamento, a aba 2 para backend, a aba 3 para desenvolvimento de API, a aba 4 para frontend e a aba 5 para revisão de código, operando em paralelo dentro de um escopo que minimize ao máximo os conflitos.

[eajrezz]

É uma suposição minha, mas talvez seja porque, para acessar por um dispositivo móvel enquanto está em deslocamento, provavelmente precisa ser uma sessão web. Numa situação em que a carga cognitiva suportável é de cerca de 10, algo como 5 ficariam para um trabalho mais profundo localmente no PC, e o restante seria para tarefas rápidas pelo celular.

[laeyoung]

Pode ser.