Claude Code é uma ferramenta voltada para apoiar atividades de programação com assistência de um modelo de linguagem, integrando conversa, execução de comandos e automações em um fluxo de desenvolvimento. Nesse contexto, Boris Cherny, criador do Claude Code, descreveu em um tweet como organiza o próprio trabalho com a ferramenta, detalhando um conjunto de práticas repetíveis.
O relato dele enfatiza que o uso pode ser simples “de fábrica”, sem grandes personalizações, e ainda assim altamente produtivo. Também aparece a ideia de que não existe um único jeito correto, porque o sistema foi pensado para permitir adaptação, extensão e automação. A seguir, ficam organizadas e explicadas as 13 dicas, na ordem apresentada por ele, com foco no que cada prática resolve e por que costuma funcionar bem.
1) Rodar vários Claudes em paralelo no terminal
Boris mantém cinco sessões paralelas do Claude Code no terminal, cada uma em uma aba numerada de 1 a 5. Esse arranjo separa contextos de trabalho, reduzindo a mistura de assuntos e evitando que uma tarefa interrompa outra. O uso de notificações do sistema sinaliza quando uma sessão precisa de entrada, diminuindo a necessidade de monitoramento constante. A prática cria um “estoque” de tarefas em andamento e favorece alternância rápida entre frentes diferentes.
Em termos de operação, cada aba costuma representar um objetivo específico, como investigar um bug, preparar um commit ou revisar uma mudança. Quando uma sessão está “pensando” ou executando ferramentas, outra sessão pode estar coletando informações ou refinando um plano. Isso reduz tempo ocioso e melhora o aproveitamento do tempo de espera natural de tarefas que levam mais tempo. A numeração simples evita confusão e facilita lembrar o propósito de cada sessão.
2) Combinar sessões locais e sessões na web (e também no celular)
Além do terminal, Boris roda 5 a 10 sessões em paralelo no ambiente web do Claude, e ainda inicia algumas no aplicativo do iOS ao longo do dia. Essa combinação permite escolher a interface mais conveniente para cada tarefa, mantendo o terminal para tarefas de código e a web para coordenação, escrita e análises mais amplas. Ele descreve a prática de “entregar” uma sessão local para a web usando &, e também de alternar com --teleport para ir e voltar entre ambientes. O celular entra como um ponto de captura rápida de ideias e tarefas que podem ser revisadas mais tarde.
O valor principal dessa estratégia está na continuidade do contexto em diferentes dispositivos e superfícies de trabalho. Quando uma atividade fica melhor em uma janela de navegador, ela pode ser movida sem recomeçar do zero, preservando histórico e decisões. Sessões iniciadas no telefone funcionam como “sementes” para tarefas futuras: uma hipótese, uma pergunta, um rascunho de plano. O resultado é um fluxo mais flexível, com menos fricção para iniciar e retomar atividades.
3) Usar Opus 4.5 com “thinking” para tudo
Boris escolhe o modelo Opus 4.5 com “thinking” (modo em que o modelo investe mais esforço em raciocínio) como padrão para praticamente todas as tarefas. Ele argumenta que, embora seja maior e mais lento do que alternativas menores, a necessidade de “condução” é menor e o uso de ferramentas costuma ser melhor. Isso significa menos idas e voltas para corrigir direções, requisitos e detalhes de implementação. No saldo final, a produtividade tende a ser maior porque o tempo economizado em correções supera o tempo extra por resposta.
Essa dica também revela um critério de escolha: não é apenas velocidade por resposta, mas tempo para concluir um objetivo com qualidade aceitável. Modelos menores podem exigir mais prompts, mais revisões e mais retrabalho. Um modelo mais competente, mesmo mais lento, pode chegar mais perto do resultado certo na primeira tentativa. Em projetos com integração, testes e padrões rígidos, reduzir retrabalho costuma ser decisivo.
4) Manter um único CLAUDE.md compartilhado e versionado
O time dele mantém um arquivo CLAUDE.md único para o repositório do Claude Code, versionado no git. Esse arquivo funciona como um manual de instruções e restrições para o assistente, descrevendo preferências, padrões do projeto e armadilhas conhecidas. A regra prática é simples: sempre que Claude faz algo incorreto, o time registra a correção no CLAUDE.md para reduzir a chance de repetição. Como o documento é compartilhado, as melhorias se acumulam e beneficiam todos.
O efeito é transformar erros em memória organizacional, em vez de tratá-los como incidentes isolados. Em times, isso reduz divergência entre estilos e evita que cada pessoa “reinvente” as mesmas orientações. Também facilita alinhar decisões de arquitetura e convenções, especialmente quando o assistente participa de várias tarefas. Segundo ele, outros times mantêm seus próprios CLAUDE.md e assumem a responsabilidade de atualizá-los.
5) Usar code review para alimentar o CLAUDE.md via automação no GitHub
Durante revisão de código, Boris marca @.claude em Pull Requests (PRs) de colegas para solicitar que algo seja adicionado ao CLAUDE.md como parte da própria PR. Essa prática é apoiada por uma GitHub Action do Claude Code, instalada com o comando /install-github-action. O objetivo é incorporar aprendizado diretamente no fluxo de revisão, no momento em que problemas e padrões aparecem. Ele relaciona isso a uma abordagem de melhoria contínua, em que pequenas melhorias se acumulam ao longo do tempo.
Na prática, a revisão deixa de ser apenas correção do código atual e passa a ser também correção do “processo” que gera código. Ao fazer o ajuste no CLAUDE.md junto com a PR, o time registra uma regra enquanto o contexto ainda está fresco. Isso reduz a repetição do mesmo tipo de feedback em PRs futuras. O resultado tende a ser um assistente mais consistente com o padrão do repositório.
6) Começar sessões em Plan mode e só depois entrar em auto-accept edits
Segundo Boris, muitas sessões começam no Plan mode, ativado com shift+tab duas vezes. Nesse modo, o foco é produzir um plano de ação antes de editar arquivos, definindo passos, riscos e critérios de verificação. Quando o objetivo é abrir uma PR, ele negocia o plano com o Claude até ficar satisfeito. Em seguida, muda para um modo de auto-accept edits, no qual o assistente aplica alterações automaticamente e tende a concluir tudo em uma única passada (“1-shot”).
A lógica central é que um bom plano reduz retrabalho e diminui o risco de mudanças fora do escopo. Planejamento explícito também torna mais fácil identificar dependências, como migrações, testes e ajustes de configuração. Com o plano validado, a execução pode ser acelerada porque há menos decisões em aberto. Ele destaca que a qualidade do plano é um fator determinante para o resultado final.
7) Criar slash commands para fluxos repetidos e versioná-los no repositório
Boris usa slash commands (comandos iniciados por “/”) para tarefas do “loop interno”, ou seja, rotinas repetidas muitas vezes ao dia. O objetivo é evitar prompts repetitivos e padronizar procedimentos para que o próprio Claude consiga acionar esses fluxos com consistência. Esses comandos ficam versionados no git, no diretório .claude/commands/, o que permite revisão, histórico e compartilhamento. Ele cita como exemplo um comando /commit-push-pr, usado dezenas de vezes por dia.
Ele também menciona o uso de bash inline nesses comandos, isto é, trechos de shell usados para pré-calcular informações como estado do git. Essa pré-computação torna o comando mais rápido e reduz a necessidade de perguntas adicionais, diminuindo a “conversa” para obter dados básicos. A ideia é transformar um fluxo complexo em uma operação repetível, com entradas e saídas previsíveis. A padronização tende a reduzir erros e aumentar a velocidade de entrega.
8) Usar subagentes para automatizar etapas comuns de PR
Além de comandos, Boris usa subagentes, que são agentes auxiliares com instruções específicas para executar tarefas recorrentes. Ele cita alguns exemplos: code-simplifier, para simplificar o código depois do trabalho principal, e verify-app, com instruções detalhadas para testar o Claude Code de ponta a ponta. A analogia é que subagentes “encapsulam” processos que aparecem em grande parte das PRs. Assim como slash commands, a intenção é automatizar o que é frequente e previsível.
O ganho típico está em separar responsabilidades: um agente foca em implementar, outro foca em simplificar, outro foca em validar. Essa divisão ajuda a manter consistência e reduz a chance de esquecer etapas. Também facilita evoluir o processo, melhorando instruções do subagente conforme surgem novos padrões de falha. No conjunto, subagentes funcionam como peças reutilizáveis de um pipeline de desenvolvimento.
9) Aplicar formatação automaticamente com PostToolUse hook
O time usa um PostToolUse hook, isto é, um gancho (hook) executado após o uso de ferramentas, para formatar o código gerado pelo Claude. Mesmo quando o código já vem bem formatado, esse mecanismo cuida do “último 10%” e evita divergências que causariam falhas posteriores no CI (Integração Contínua, o sistema que roda verificações automáticas). A ideia é tratar formatação como uma etapa mecânica e confiável, não como algo dependente de atenção humana. Isso reduz ruído em revisões e diminui mudanças apenas estéticas.
Automatizar a formatação também melhora previsibilidade: o mesmo estilo é aplicado sempre, independentemente de quem escreveu ou de como o assistente gerou o trecho. Em pipelines de engenharia, pequenas inconsistências de estilo podem interromper builds e atrasar entregas. Um hook evita esse tipo de interrupção de maneira preventiva. Assim, a atenção fica concentrada em lógica e comportamento, não em formatação.
10) Evitar dangerously-skip-permissions e pré-aprovar comandos com /permissions
Boris afirma que não usa --dangerously-skip-permissions no dia a dia, preferindo um caminho mais controlado. Ele usa /permissions para pré-aprovar comandos bash comuns que já são conhecidos como seguros no ambiente dele, reduzindo prompts de permissão. Parte dessas permissões fica registrada em .claude/settings.json e é compartilhada com o time. O objetivo é equilibrar produtividade com segurança operacional.
O ponto central é diminuir interrupções sem abrir mão de barreiras importantes. Em ferramentas que executam comandos, permissões funcionam como um controle de risco para ações potencialmente perigosas. Ao pré-aprovar um conjunto restrito e conhecido, o fluxo fica mais suave e ainda mantém limites. Versionar configurações também ajuda a alinhar o time e reduzir discrepâncias entre máquinas.
11) Deixar o Claude usar ferramentas do ecossistema (Slack, BigQuery, Sentry) via integrações
Boris descreve o Claude Code como um orquestrador que usa ferramentas no lugar dele quando necessário. Ele cita exemplos como pesquisar e postar no Slack via um servidor MCP (um servidor de integração que expõe ferramentas ao assistente), rodar consultas no BigQuery via bq CLI, e buscar logs de erro no Sentry. A configuração do Slack via MCP fica em .mcp.json e é compartilhada com o time. A intenção é centralizar tarefas operacionais no mesmo fluxo em que o código é escrito e investigado.
Essa abordagem reduz troca de contexto: em vez de alternar entre várias interfaces, parte da coleta de evidências e comunicação é automatizada. Para análises, consultas e triagem de incidentes, ter acesso a dados e logs acelera diagnóstico. Ao mesmo tempo, configurações compartilhadas padronizam como essas ferramentas são acessadas. O resultado é uma rotina em que o assistente atua como um “operador” que busca informações, executa consultas e retorna resultados no mesmo canal.
12) Lidar com tarefas longas usando verificação em segundo plano, hooks ou plugin
Para tarefas de longa duração, Boris usa três estratégias: pedir que Claude verifique o próprio trabalho com um agente em background quando terminar, usar um Stop hook de agente para tornar essa verificação mais determinística, ou empregar o plugin ralph-wiggum. A ideia comum é garantir que, ao final de um processamento longo, exista uma etapa automática de checagem que aponte problemas. Ele também menciona usar --permission-mode=dontAsk ou até --dangerously-skip-permissions em um sandbox (ambiente isolado) para evitar bloqueios por prompts durante a sessão.
O cenário aqui envolve automações que não podem ficar esperando intervenções frequentes. Se uma sessão exigir confirmações constantes, a tarefa longa perde eficiência e pode travar. Em um ambiente isolado, permissões mais liberais reduzem interrupções, mantendo o risco contido no sandbox. Ao finalizar, a verificação automática funciona como uma rede de segurança para detectar falhas e regressões.
13) A dica mais importante: criar um loop de verificação do trabalho
Boris encerra com o princípio que ele considera mais importante: dar ao Claude uma forma de verificar o próprio trabalho. Com um loop de feedback, ele afirma que a qualidade final pode melhorar de 2 a 3 vezes, porque o assistente deixa de “imaginar” se algo funciona e passa a confirmar. No caso do claude.ai/code, ele descreve que Claude testa cada mudança usando uma extensão do Chrome, abrindo o navegador, testando a interface e iterando até o comportamento funcionar e a experiência de uso ficar boa. A verificação, segundo ele, varia por domínio, podendo ser um comando bash, uma suíte de testes, um teste no navegador ou em simulador de celular.
O valor desse padrão está em transformar o desenvolvimento em um ciclo fechado: alterar, executar, observar, corrigir. Sem verificação, erros sutis podem passar e o retrabalho aparece mais tarde, quando a correção é mais cara. Com verificação consistente, o assistente aprende rapidamente por tentativa e erro dentro do próprio fluxo. Investir em um mecanismo de verificação “à prova de falhas” passa a ser parte do sistema, não uma etapa opcional.
Conclusão
O uso que Boris descreve combina paralelismo, padronização e verificação contínua para tornar o Claude Code um componente estruturado do fluxo de engenharia. O paralelismo aparece em múltiplas sessões locais, web e móveis, reduzindo espera e separando contextos. A padronização surge em arquivos versionados como o CLAUDE.md, em comandos e subagentes reutilizáveis, e em hooks que automatizam detalhes como formatação e checagens. Por fim, a ênfase mais forte recai sobre o loop de verificação, que transforma assistência em execução com feedback, elevando qualidade e reduzindo retrabalho.