Boris Cherny não dá mais prompts ao Claude.
Isso não é uma paráfrase viral. É uma declaração própria, registrada publicamente: "Eu não dou mais prompts ao Claude. Tenho loops rodando que dão prompts ao Claude e descobrem o que fazer. Meu trabalho é escrever loops." Ele disse isso em várias aparições públicas, uma palestra na Sequoia, uma entrevista no Acquired, na Startup School do Y Combinator, e o padrão por trás disso é o verdadeiro assunto deste artigo. Não dicas. Não uma lista de recursos. A forma específica como a pessoa que construiu o Claude Code realmente o usa, no dia a dia, verificada com base nas próprias declarações públicas dele, em vez de paráfrases de segunda mão.
Esta é a análise completa, fundamentada no que Cherny realmente disse, além das melhores práticas documentadas pela própria Anthropic para a ferramenta que ele construiu.
Claude Code Nunca Foi Para Ser Um Produto
Entender como Cherny usa a ferramenta começa por entender de onde ela veio, porque a origem explica a filosofia, e é uma história mais interessante do que a maioria das pessoas que usam a ferramenta hoje imagina.
O Claude Code começou em 2021 como um projeto de pesquisa de alinhamento de segurança de IA, não como um produto. Uma extensão rudimentar de VS Code, depois uma ferramenta CLI interna chamada clide, usada dentro da Anthropic por anos antes que qualquer pessoa fora da empresa ouvisse falar dela. Cherny entrou no projeto em setembro de 2024 e reconstruiu o núcleo em um sprint de duas semanas naquele dezembro. O lançamento público em fevereiro de 2025 foi discreto, sem muito alarde, recebido mais com um dar de ombros do que com empolgação. Então o Claude 4 foi lançado, e a adoção explodiu quase da noite para o dia.
A avaliação do próprio Cherny sobre onde a ferramenta está agora, dita diretamente: "Estamos apenas em 1%."
Essa visão importa para a forma como você deve abordar o uso da ferramenta. Cherny não está descrevendo um produto acabado com um padrão fixo de uso correto. Ele está descrevendo algo que ainda está sendo ativamente reconstruído, por um time que usa a ferramenta para construir a própria ferramenta. O Claude Code foi reescrito repetidamente usando o próprio Claude Code, um loop de autoaperfeiçoamento que existe desde antes de "loop engineering" se tornar uma expressão usada publicamente. Vale a pena parar para digerir isso por um momento, porque explica algo que confunde muitos usuários novos: por que o jeito "certo" de usar essa ferramenta parece mudar o tempo todo. Não é inconsistência. É uma ferramenta cujos próprios criadores ainda estão descobrindo ativamente do que ela é realmente capaz, em tempo real, usando a própria ferramenta para descobrir.
Os anos passados como ferramenta interna de pesquisa antes de se tornar um produto também explicam por que grande parte da filosofia abaixo parece incomumente opinativa para uma ferramenta de desenvolvimento. A maioria das ferramentas acumula recursos para satisfazer uma base ampla de usuários externos com necessidades concorrentes desde o primeiro dia. O Claude Code acumulou sua filosofia primeiro, dentro de um time pequeno resolvendo os próprios problemas, antes de precisar satisfazer o fluxo de trabalho de qualquer outra pessoa. Essa história é exatamente o motivo pelo qual entender os padrões de uso específicos de Cherny, em vez de conselhos genéricos sobre "ferramentas de codificação com IA", vale o tempo que leva para realmente absorver.
A Mudança Central: De Escrever Prompts Para Projetar Loops
A coisa mais importante que Cherny disse publicamente sobre o uso real do Claude Code é a declaração sobre loops acima, e vale a pena explorar o que isso realmente significa na prática, não apenas como uma frase digna de citação.
Um prompt é uma instrução única, enviada uma vez, respondida uma vez. Um loop é um sistema: ele dá um prompt ao Claude, avalia o que voltou, decide o que acontece em seguida e repete, sem um humano no meio de cada ciclo. A descrição de cargo declarada por Cherny, "meu trabalho é escrever loops", significa que ele passa o tempo projetando os sistemas que geram e avaliam prompts, não digitando prompts ele mesmo, turno após turno.
O fluxo de trabalho diário confirmado dele reflete isso diretamente. O celular como interface principal, não o teclado de um laptop. De cinco a dez sessões ativas rodando ao mesmo tempo, cada uma capaz de gerar subagentes, às vezes algumas centenas de uma vez, às vezes alguns milhares durante a noite em trabalhos mais profundos. Dezenas de loops rodando continuamente em segundo plano, cuidando de pull requests, mantendo a integração contínua saudável, agrupando feedback em uma programação recorrente. Rotinas que persistem no servidor mesmo quando o laptop dele está fechado.
O aprendizado prático para quem usa o Claude Code no dia a dia: o teto do que a ferramenta pode fazer não é definido por quão bom é um único prompt. É definido por quão bem você projeta o sistema em torno de ciclos repetidos e automatizados de dar prompts, verificar e tentar de novo.
O Que Realmente Mudou No System Prompt E Por Que Isso Importa
Cherny também falou diretamente sobre uma decisão técnica específica que revela como ele pensa em instruir o Claude: "Removemos cerca de 80% do system prompt do Claude Code para nossos modelos mais novos. Isso é o que aprendemos sobre escrever system prompts."
Esse corte aconteceu especificamente com a geração Opus 4.8, reduzindo o system prompt de aproximadamente 15.000 caracteres para cerca de 4.500, sem perda mensurável nas avaliações de codificação. A lição por trás disso, de acordo com o próprio guia de engenharia de contexto da Anthropic, é que listas rígidas e exaustivas de regras deixam de ser necessárias quando um modelo é capaz o suficiente para exercer julgamento real. Regras viram decisões de julgamento. Exemplos de uso de ferramentas são substituídos por interfaces projetadas para se autodocumentar. Contexto exaustivo antecipado é substituído por divulgação progressiva, informações que só aparecem quando uma situação específica realmente pede por elas, em vez de serem carregadas em todas as sessões por padrão.
Uma nuance que vale incluir com honestidade, já que complica a versão simples dessa história: quando o Opus 5 foi lançado, testes independentes de desenvolvedores descobriram que o system prompt real dele veio aproximadamente 72% mais longo que o do Opus 4.8. Isso não é uma contradição da lição acima; é uma versão mais profunda dela. O prompt encolheu no volume de instruções rígidas e depois cresceu de novo em referências mais ricas e específicas, exemplos trabalhados, suítes de teste, rubricas de avaliação, o tipo de contexto que um modelo genuinamente mais capaz consegue aproveitar bem. O aprendizado não é "mais curto é sempre melhor". É que o volume de instruções deve acompanhar o que o modelo específico realmente precisa para exercer bom julgamento, não um alvo fixo em qualquer direção.
Escrevendo Um CLAUDE.md Do Jeito Que Os Times Da Anthropic Fazem
Isso conecta diretamente com a forma como você deve estruturar suas próprias instruções no nível do projeto, e a documentação oficial da Anthropic é explícita sobre o modelo mental a usar: pense no Claude como um funcionário brilhante, mas muito novo, com amnésia, que precisa de instruções explícitas.
As implicações práticas dessa visão. Brilhante significa que você não precisa explicar demais a competência geral; ela já está lá. Novo significa zero conhecimento acumulado sobre a história ou as convenções do seu projeto específico. Amnésia significa que cada sessão começa do zero, e o CLAUDE.md é a única coisa que carrega contexto de forma confiável entre as sessões.
O guia documentado da Anthropic recomenda manter esse arquivo com menos de 200 linhas, com alguns dos times mais disciplinados rodando com apenas 60. O teste para saber se algo pertence ao arquivo: isso é realmente relevante para quase todas as sessões, ou apenas para uma fatia estreita e situacional do trabalho? Coisas universais, comandos de build, regras de estilo inegociáveis, expectativas de teste, salvaguardas reais, pertencem ao arquivo raiz. Qualquer coisa mais específica pertence a um arquivo importado, puxado para o contexto apenas quando o trabalho específico de uma sessão realmente pede, usando a sintaxe de importação @path/to/file que a ferramenta suporta diretamente.
Para instruções que genuinamente não podem ser ignoradas, a prática interna da própria Anthropic usa marcadores explícitos de ênfase, "IMPORTANTE" ou "VOCÊ DEVE", reservados especificamente para o punhado de regras em que o custo de o Claude não segui-las é realmente alto. Marcar tudo dessa forma anula completamente o propósito, já que deixa de funcionar como um sinal no momento em que é aplicado de forma indiscriminada.
Plan Mode: Entender Antes De Agir
Um padrão comportamental específico que vale a pena incorporar na forma como você realmente trabalha com a ferramenta: fazer o Claude planejar antes de executar, em vez de pular direto para as mudanças.
Isso não é apenas uma opção de recurso; reflete uma mudança real que os próprios materiais da Anthropic descrevem: os modelos mais novos planejam corretamente sem precisar de tanta direção antecipada quanto os anteriores, a ponto de alguns times relatarem que não precisam mais forçar uma etapa explícita de plan mode para toda tarefa, porque o raciocínio padrão do modelo já produz um plano coerente antes de agir. Dito isso, para mudanças genuinamente complexas e que envolvem vários arquivos, pedir explicitamente um plano primeiro e revisá-lo antes de aprovar a execução continua sendo um ponto de verificação muito útil, capturando um requisito mal interpretado antes que ele se propague por uma dúzia de edições de arquivos, em vez de depois.
Subagentes E Trabalho Em Paralelo
O fluxo de trabalho confirmado de Cherny, rodando centenas, às vezes milhares, de subagentes em uma única sessão, aponta para uma capacidade estrutural que vale a pena entender e usar deliberadamente, em vez de acidentalmente.
Um agente principal pode decompor uma tarefa complexa em partes menores e acionar subagentes para executá-las de forma independente, cada um trabalhando no seu próprio contexto, em vez de tudo competindo por espaço em uma única conversa contínua. Isso serve a dois propósitos ao mesmo tempo. Permite que um trabalho que estouraria uma única janela de contexto rode em várias janelas menores. E adiciona uma camada real de verificação, já que um subagente revisando a saída de outro agente está verificando um trabalho que ele mesmo não produziu, o que é estruturalmente mais confiável do que um agente avaliando a própria lição de casa no mesmo contexto em que a produziu.
Para trabalho paralelo especificamente, git worktrees permite que múltiplas sessões operem em branches ou diretórios separados simultaneamente, sem que as mudanças em andamento de uma sessão atrapalhem as de outra. Essa é a infraestrutura mecânica por trás de rodar muitos loops concorrentes do jeito que Cherny descreve fazer pessoalmente: não um único agente trabalhando mais rápido, mas muitos agentes trabalhando em peças de trabalho genuinamente separadas ao mesmo tempo.
A Decisão Do Grep: Um Estudo De Caso De Simplicidade Em Vez De Sofisticação
Uma decisão técnica específica e bem documentada do próprio time de Cherny ilustra uma filosofia mais ampla que vale a pena internalizar. O Claude Code abandonou a busca vetorial e os embeddings para busca na base de código em favor de grep e glob simples. As palavras dele sobre o resultado: "superou tudo. Por muito."
A lição vai além dessa decisão específica. Uma solução que parece mais sofisticada, a busca vetorial semântica, não é automaticamente melhor que uma mais simples, o grep, se a mais simples estiver bem alinhada com o problema. Bases de código têm sintaxe exata, nomes de função exatos, caminhos de importação exatos, o tipo de correspondência precisa e literal em que o grep é excelente e que uma correspondência semântica difusa pode na verdade prejudicar ao trazer resultados plausíveis, mas errados.
O aprendizado prático para como você configura seus próprios fluxos de trabalho: não escolha por padrão a ferramenta ou arquitetura que parece mais complexa por presumir que complexidade implica capacidade. Teste a opção simples no seu caso de uso real primeiro. Muitas vezes ela vence, e mesmo quando não vence, você confirmou que a abordagem mais complexa merece seu lugar em vez de apenas presumir isso.
Nunca Deixe Um Agente Avaliar O Próprio Trabalho
Um princípio separado e confirmado da prática de engenharia de harness da própria Anthropic, diretamente relevante para como você deve estruturar qualquer etapa de verificação nos seus fluxos de trabalho com Claude Code: geração e avaliação devem acontecer em papéis genuinamente separados, porque um modelo revisando a própria saída no mesmo contexto em que a produziu tende a ser tendencioso para o positivo, mesmo quando um revisor humano identificaria o defeito imediatamente.
Na prática, isso significa que o agente que escreve o código não deveria ser a mesma etapa que decide se aquele código é bom o suficiente para entrar em produção. Uma etapa separada de avaliação, idealmente com acesso a algo que o agente gerador não tinha, a saída real da suíte de testes, o documento original de requisitos, captura o que a autoavaliação perde. Esse é o mesmo princípio por trás do padrão de verificação com subagentes acima, aplicado como uma disciplina geral em vez de um recurso específico.
Gestão De Esforço E Contexto
Para quem roda sessões mais longas e exigentes, entender como sinalizar diretamente o nível de esforço é importante. Incluir "ultrathink" em um prompt sinaliza profundidade máxima de raciocínio para aquela resposta específica, sem alterar as configurações gerais da sessão. Para orquestração automática de fluxo de trabalho no nível da sessão, definir o nível de esforço para o nível máximo combina raciocínio profundo com decomposição automática de tarefas ao longo da sessão, embora isso exija um modelo que realmente suporte esse nível de esforço, e nem todo modelo da linha suporta.
A gestão de contexto em si merece atenção deliberada em sessões longas. Conforme uma sessão fica mais longa, o contexto acumulado pode começar a diluir o sinal do que realmente importa no momento, o mesmo problema que arquivos CLAUDE.md inchados criam, só que acontecendo dinamicamente em uma única conversa em vez de estaticamente em um arquivo. Começar periodicamente uma sessão nova para uma fase genuinamente nova de trabalho, em vez de estender uma conversa indefinidamente, é uma disciplina real e prática que vale a pena aplicar, em vez de presumir que mais contexto é sempre estritamente melhor.
Um Exemplo Prático: Aplicando Isso A Uma Tarefa Real
Para tornar tudo acima concreto em vez de abstrato, aqui está como esses princípios realmente se combinam em uma tarefa real e comum: adicionar um novo recurso a uma base de código existente com complexidade razoável, alguns arquivos interconectados, alguns testes existentes, uma mudança não trivial, mas não exótica.
Comece com o CLAUDE.md já no lugar, curto, universal, com os comandos de build e teste, as regras de estilo inegociáveis, nada situacional poluindo ele. Isso significa que a sessão começa com contexto real e relevante carregado automaticamente, sem você reexplicar as convenções do seu projeto do zero.
Em vez de escrever um único prompt longo e esperançoso descrevendo o recurso inteiro em detalhes exaustivos, descreva o objetivo e deixe o planejamento do próprio modelo cuidar da decomposição, confiando na filosofia de menos estrutura de apoio da discussão sobre system prompt acima. Para uma tarefa desse tamanho, pedir explicitamente um plano primeiro vale o passo extra, já que um requisito mal interpretado capturado aqui custa uma correção de dois minutos em vez de uma hora desfazendo mudanças em vários arquivos depois.
Quando o plano parecer certo, deixe a execução prosseguir. Se a tarefa se dividir naturalmente em peças genuinamente independentes, atualizar um modelo de dados e, separadamente, atualizar a UI que o consome, por exemplo, isso é um candidato natural para decomposição com subagentes, cada peça trabalhando no seu próprio contexto em vez de tudo se amontoando em uma única conversa contínua.
Antes de tratar o resultado como pronto, rode uma etapa separada de verificação em vez de confiar no próprio relato do agente implementador de que tudo funciona. Isso pode ser tão simples quanto uma sessão nova, ou um subagente com acesso somente leitura, verificando a saída real dos testes e o diff contra o plano original, em vez de apenas aceitar um confiante "está completo" vindo do mesmo contexto que escreveu o código.
Note o que está ausente neste passo a passo. Nenhuma ferramenta exótica. Nenhuma configuração incomum. Apenas a aplicação comum de planejar primeiro para trabalhos genuinamente complexos, decomposição com subagentes para peças genuinamente independentes e verificação separada em vez de autoavaliação, os mesmos três princípios que percorrem tudo acima, aplicados a uma tarefa concreta em vez de descritos de forma abstrata.
Escalando Isso Além De Uma Única Pessoa
Tudo acima descreve práticas para uma pessoa usando o Claude Code deliberadamente. O fluxo de trabalho confirmado do próprio Cherny, centenas de subagentes por dia, milhares durante a noite, já é por si só uma forma de escalar, uma pessoa dirigindo uma quantidade genuinamente grande de trabalho paralelo e automatizado. Mas os mesmos princípios se estendem a um time que adota essas práticas em conjunto, com algumas considerações específicas que valem ser nomeadas diretamente.
O CLAUDE.md deixa de ser um arquivo de preferência pessoal no momento em que mais de uma pessoa no time trabalha contra a mesma base de código com o Claude Code. Trate mudanças nele com a mesma disciplina de revisão que você aplicaria a qualquer configuração compartilhada que afeta o fluxo de trabalho de todo o time. Um colega de time adicionando uma instrução pontual de "hotfix" depois de uma única sessão frustrante, sem revisão, é exatamente o mecanismo que produz os arquivos inchados e autocontraditórios que param de ser seguidos de forma confiável. Uma etapa leve de revisão, mesmo que apenas uma segunda pessoa dando uma olhada no diff antes do merge, captura uma parcela significativa disso antes que se acumule em um problema genuíno.
A disciplina de verificação importa ainda mais em escala de time do que para um usuário solo. Quando uma pessoa escreve e revisa o próprio trabalho assistido por agente, existe pelo menos a chance de ela pessoalmente capturar algo que o agente deixou passar. Quando um time depende da saída do Claude Code fluindo por um processo de revisão compartilhado, o princípio de avaliação separada de antes não é mais opcional; é o mecanismo real que protege a base de código de uma autoavaliação confiante, mas errada, do agente chegar à produção, já que a alternativa é confiar que algum humano, em algum momento do fluxo de trabalho de um time ocupado, acabe capturando o que o agente não sinalizou sozinho.
Também vale estabelecer responsabilidade explícita por auditorias periódicas do CLAUDE.md, a mesma disciplina de manutenção recomendada para qualquer documento compartilhado que acumula conteúdo. Sem um responsável claramente designado, esse trabalho tende a passar despercebido precisamente porque não bloqueia nenhuma tarefa imediata específica do jeito que um build quebrado bloqueia, e seis meses de adições sem dono produzem exatamente o tipo de arquivo inchado e contraditório que o princípio de aplicabilidade universal existe para prevenir.
Onde As Pessoas Aplicam Mal Esses Princípios
Um punhado de leituras erradas específicas das ideias acima aparecem repetidamente, e vale nomeá-las diretamente, já que cada uma tem uma correção simples e específica.
Tratar "loops em vez de prompts" como licença para pular completamente o entendimento da tarefa. A declaração do próprio Cherny é que o trabalho dele é escrever loops, não que ele parou de pensar sobre o que esses loops deveriam realmente fazer. Projetar um bom loop, uma boa definição de sucesso, uma boa condição de parada, ainda exige entender o problema tão claramente quanto escrever um bom prompt único exigiria. O loop substitui a digitação manual repetida, não o pensamento inicial.
Ler a redução do system prompt como "dê menos contexto ao modelo, sempre." O contraexemplo do Opus 5 no início deste artigo existe especificamente para corrigir essa leitura errada. A lição real é que o volume de instruções deve corresponder ao que um modelo específico realmente precisa para exercer bom julgamento, o que às vezes significa menos listagem rígida de regras e às vezes significa mais material de referência rico e específico. Cortar contexto de forma indiscriminada porque "os modelos mais novos precisam de menos" aplica de forma errada uma descoberta sutil e específica de modelo como se fosse uma regra geral.
Decompor demais tarefas simples em subagentes por hábito. A decomposição com subagentes justifica sua complexidade em peças de trabalho genuinamente grandes e genuinamente independentes. Dividir uma mudança pequena e fortemente acoplada em pedaços artificiais de subagentes só para usar o padrão adiciona custo de coordenação sem o benefício que a justifica em tarefas maiores. O exemplo prático no início deste artigo usou subagentes deliberadamente apenas onde as peças eram naturalmente independentes, não como padrão para toda tarefa, independentemente do tamanho.
Pular a verificação na suposição de que "os modelos mais novos não precisam mais disso." O princípio de avaliação separada não é um contorno para modelos mais fracos que se tornará desnecessário conforme a capacidade melhora. É um fato estrutural sobre autoavaliação: um modelo verificando o próprio trabalho no mesmo contexto em que o produziu sempre terá mais dificuldade de capturar os próprios pontos cegos do que uma verificação independente teria, independentemente de quão capaz o modelo subjacente se torne. Isso também é verdade para revisores humanos, e não deixa de ser verdade só porque o revisor fica mais inteligente.
Os Hábitos Diários Reais Que Valem A Pena Adotar
Trazendo tudo acima para uma prática diária concreta e aplicável, aqui está como é realmente seguir a abordagem demonstrada por Cherny.
Pare de tratar toda tarefa como um único prompt para acertar de primeira. Projete um loop em vez disso: um agente que tenta a tarefa, uma forma de verificar se a tentativa teve sucesso e um caminho definido para o que acontece em seguida dependendo dessa verificação: passar, tentar de novo ou escalar diretamente para você.
Mantenha seu CLAUDE.md curto e trate-o como material de integração para um novo contratado capaz, mas sem contexto, não como um manual abrangente. Mova qualquer coisa situacional para arquivos importados em vez de inchar o documento raiz.
Use o plan mode deliberadamente em trabalhos genuinamente complexos e com vários arquivos, e confie no planejamento padrão do próprio modelo em tarefas mais simples e bem definidas, em vez de forçar um passo extra em todo lugar por hábito.
Decomponha tarefas grandes em subagentes trabalhando em contextos separados, em vez de tentar segurar uma tarefa complexa inteira em uma única conversa contínua. Use uma etapa separada para verificar trabalhos significativos, em vez de confiar na autoavaliação de um único agente.
Opte por padrão pela ferramenta mais simples que possa resolver seu problema específico, do jeito que o grep venceu a busca vetorial nesse caso de uso exato, e só recorra a mais complexidade quando a opção simples tiver sido realmente testada e se mostrado insuficiente.
Construa paralelismo real no seu fluxo de trabalho usando git worktrees para peças de trabalho genuinamente independentes, em vez de rodar tudo em uma sessão sequencial porque esse é o jeito padrão de trabalhar.
Para Onde Isso Está Realmente Indo
A visão do próprio Cherny de "estamos apenas em 1%" vale a pena ser levada a sério como uma declaração prática, não apenas como uma frase de humildade. Os padrões específicos descritos acima, design de loops em vez de prompts únicos, poda agressiva do system prompt conforme os modelos ficam mais capazes, decomposição com subagentes, verificação separada, não são uma metodologia fixa e final. São o estado atual de uma ferramenta e de uma prática que o próprio criador descreve como ainda no início.
A habilidade real que vale a pena desenvolver não é memorizar a configuração específica de melhores práticas de hoje. É entender os princípios subjacentes bem o suficiente para continuar se adaptando conforme a própria ferramenta continua mudando, do mesmo jeito que o time do próprio Cherny reconstruiu o Claude Code repetidamente usando o Claude Code, refinando o loop em vez de tratar qualquer versão dele como acabada.
Essa é a linha condutora real conectando tudo neste artigo. Não uma lista estática de dicas, mas uma filosofia de trabalho: projete sistemas em vez de digitar instruções únicas, mantenha instruções enxutas e deixe a capacidade do modelo fazer mais do trabalho conforme ela melhora, verifique de forma independente em vez de confiar na autoavaliação, e opte pela simplicidade até a complexidade realmente se provar necessária. Direto de como a pessoa que construiu a ferramenta realmente a usa.
Siga @cyrilXBT para mais análises do Claude Code baseadas em material verificado e registrado publicamente.
