Boris Cherny não faz mais prompts para o Claude.
Isso não é uma paráfrase viral. É uma declaração dele mesmo, registrada publicamente: "Eu não faço mais prompts para o Claude. Tenho loops rodando que fazem prompts para o 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, no 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 funcionalidades. A forma específica como a pessoa que construiu o Claude Code realmente o usa, no dia a dia, verificada a partir de suas próprias declarações públicas, e não por paráfrase 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.
O Claude Code Nunca Foi Feito 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 do VS Code, depois uma ferramenta CLI interna chamada clide, usada dentro da Anthropic por anos antes que qualquer pessoa fora da empresa tivesse ouvido 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 chegou de forma discreta, 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 dele sobre onde a ferramenta está agora, dita diretamente: "Estamos apenas 1% do caminho."
Essa perspectiva 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 uma equipe 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 antecede o termo "loop engineering" como uma expressão usada publicamente por qualquer pessoa. Vale a pena parar e pensar nisso por um momento, porque explica algo que confunde muitos usuários novos: por que a forma "certa" de usar essa ferramenta parece estar sempre mudando. Não é inconsistência. É uma ferramenta cujos próprios criadores ainda estão ativamente descobrindo 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 virar produto também explicam por que grande parte da filosofia abaixo soa incomumente opinativa para um software de desenvolvimento. A maioria das ferramentas acumula funcionalidades para satisfazer uma ampla base de usuários externos com necessidades concorrentes desde o primeiro dia. O Claude Code acumulou sua filosofia primeiro, dentro de uma pequena equipe resolvendo seus próprios problemas, antes de precisar satisfazer o fluxo de trabalho de qualquer outra pessoa. Essa história é exatamente o motivo de valer a pena dedicar tempo para absorver os padrões de uso específicos de Cherny, em vez de conselhos genéricos de "ferramenta de IA para codificação".
A Mudança Central: De Fazer Prompts A Projetar Loops
A coisa mais importante que Cherny já disse publicamente sobre o uso real do Claude Code é a declaração sobre loops acima, e vale a pena desdobrar o que ela realmente significa na prática, não apenas como uma frase de efeito.
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, passo a passo.
O fluxo de trabalho diário confirmado dele reflete isso diretamente. O telefone 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 rotina recorrente. Rotinas que persistem no servidor mesmo quando o laptop dele está fechado.
O aprendizado prático para qualquer pessoa que usa o Claude Code no dia a dia: o teto do que a ferramenta pode fazer não é definido por quão bom é um prompt único. É definido por quão bem você projeta o sistema em torno de ciclos repetidos e automatizados de prompts, verificação e novas tentativas.
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 sobre instruir o Claude: "Removemos ~80% do system prompt do Claude Code para nossos modelos mais novos — isto é o que aprendemos sobre escrever system prompts."
Esse corte aconteceu especificamente na 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 baseadas em julgamento. Exemplos de uso de ferramentas são substituídos por interfaces projetadas para serem autodocumentáveis. Contexto exaustivo e antecipado é substituído por divulgação progressiva (progressive disclosure), informações que aparecem apenas quando uma situação específica realmente exige, em vez de serem carregadas em toda sessão por padrão.
Uma nuance que vale a pena 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 era 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 em volume de instruções rígidas, depois cresceu novamente em referências mais ricas e específicas, exemplos resolvidos, suítes de teste, rubricas de avaliação, o tipo de contexto que um modelo genuinamente mais capaz consegue aproveitar de verdade. 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, e não um alvo fixo em nenhuma das direções.
Escrevendo Um CLAUDE.md Do Jeito Que As Próprias Equipes Da Anthropic Fazem
Isso conecta diretamente com a forma como você deve estruturar suas próprias instruções de nível de projeto, e a documentação oficial da própria 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 estrutura. Brilhante significa que você não precisa explicar demais competência geral, ela já está lá. Novo significa zero de conhecimento acumulado sobre a história ou as convenções do seu projeto específico. Amnésia significa que toda sessão começa do zero, e o CLAUDE.md é a única coisa que carrega contexto de forma confiável entre as sessões.
A orientação documentada da Anthropic busca manter esse arquivo com menos de 200 linhas, com algumas das equipes mais disciplinadas operando com apenas 60. O teste para saber se algo pertence ao arquivo: isso é genuinamente relevante para quase todas as sessões, ou apenas para uma fatia restrita e situacional do trabalho? Coisas universais, comandos de build, regras de estilo inegociáveis, expectativas de teste, proteções reais, pertencem ao arquivo raiz. Qualquer coisa mais restrita pertence a um arquivo importado, puxado para o contexto apenas quando o trabalho específico de uma sessão realmente exigir, 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, "IMPORTANT" ou "YOU MUST", reservados especificamente para o punhado de regras em que o custo de o Claude deixá-las passar é genuinamente alto. Marcar tudo dessa forma destrói o propósito por completo, já que deixa de funcionar como sinal no momento em que é aplicado indiscriminadamente.
Modo Plano (Plan Mode): Entender Antes De Agir
Um padrão comportamental específico que vale a pena incorporar à 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 um recurso que você liga e desliga; reflete uma mudança real que os próprios materiais da Anthropic descrevem: os modelos mais novos planejam corretamente sem precisar de direcionamento inicial pesado como os anteriores, a ponto de algumas equipes relatarem que não precisam mais forçar uma etapa explícita de modo plano para toda tarefa, porque o raciocínio padrão do próprio modelo já produz um plano coerente antes de agir. Dito isso, para mudanças genuinamente complexas e de múltiplos arquivos, pedir explicitamente um plano primeiro, e revisá-lo antes de aprovar a execução, continua sendo um ponto de verificação utilmente significativo, capturando um requisito mal compreendido 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 implantar subagentes para executá-las de forma independente, cada um trabalhando em 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 transbordaria uma única janela de contexto seja executado em muitas janelas menores em vez disso. 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 o próprio trabalho no mesmo fôlego em que o produziu.
Para trabalho paralelo especificamente, git worktrees permitem 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 baixo da execução de 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 genuinamente separadas de trabalho ao mesmo tempo.
A Decisão Do Grep: Um Estudo De Caso Em Simplicidade Em Vez De Sofisticação
Uma decisão técnica específica e bem documentada da própria equipe de Cherny ilustra uma filosofia mais ampla que vale a pena internalizar. O Claude Code abandonou a busca vetorial e os embeddings para busca no código em favor de grep e glob simples. As palavras dele sobre o resultado: "superou tudo. Por muita margem."
A lição se generaliza para além dessa decisão específica. Uma solução de nome mais sofisticado, a busca vetorial semântica, não é automaticamente melhor que uma mais simples, o grep, se a mais simples estiver de fato bem ajustada ao problema. Bases de código têm sintaxe exata, nomes de funções exatos, caminhos de import exatos, o tipo de correspondência precisa e literal em que o grep se destaca e que uma correspondência semântica difusa pode na verdade prejudicar ao trazer resultados plausíveis, mas errados.
O aprendizado prático para configurar seus próprios fluxos de trabalho: não escolha por padrão a ferramenta ou arquitetura de nome mais complexo partindo do pressuposto de que complexidade implica capacidade. Teste a opção simples contra 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 em seus próprios 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 fôlego em que a produziu tende a pender para o positivo, mesmo quando um revisor humano perceberia o defeito imediatamente.
Na prática, isso significa que o agente que escreve o código não deve ser a mesma passagem que decide se aquele código é bom o suficiente para ser lançado. Uma etapa de avaliação separada, 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 deixa passar. Esse é o mesmo princípio por trás do padrão de verificação por subagente acima, aplicado como uma disciplina geral, não como um recurso específico.
Gerenciamento De Esforço E Contexto
Para qualquer pessoa que rode sessões mais longas e exigentes, entender como sinalizar diretamente o nível de esforço importa. Incluir "ultrathink" em um prompt sinaliza profundidade máxima de raciocínio para aquela resposta específica, sem mudar 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 patamar mais alto combina raciocínio profundo com decomposição automática de tarefas ao longo de uma sessão, embora isso exija um modelo que realmente suporte esse patamar de esforço; nem todo modelo em uma determinada linha suporta.
O gerenciamento de contexto em si merece atenção deliberada em sessões longas. Conforme uma sessão se estende, o contexto acumulado pode começar a diluir o sinal do que realmente importa naquele momento, o mesmo problema que arquivos CLAUDE.md inchados criam, só que acontecendo dinamicamente dentro de 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, veja 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, sem nada situacional poluindo. Isso significa que a sessão começa com contexto real e relevante carregado automaticamente, sem que você precise reexplicar as convenções do seu projeto do zero.
Em vez de escrever um prompt único, 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 prévia 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 compreendido 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 naturalmente se dividir em peças genuinamente independentes, atualizar um modelo de dados e separadamente atualizar a interface que o consome, por exemplo, esse é um candidato natural para decomposição em subagentes, com cada peça trabalhando em seu próprio contexto, em vez de tudo se amontoando em uma única conversa contínua.
Antes de tratar o resultado como concluído, faça uma passagem de verificação separada, em vez de confiar no auto-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 em relação ao plano original, em vez de simplesmente aceitar um confiante "está completo" vindo do mesmo contexto que escreveu o código.
Repare no que está ausente nesse passo a passo. Nenhuma ferramenta exótica. Nenhuma configuração incomum. Apenas a aplicação ordinária de plano-primeiro para trabalho genuinamente complexo, decomposição em 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 abstratamente.
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á é em si uma forma de escalar: uma pessoa direcionando uma quantidade genuinamente grande de trabalho paralelo e automatizado. Mas os mesmos princípios se estendem a uma equipe que adota essas práticas em conjunto, com algumas considerações específicas que valem a pena nomear diretamente.
O CLAUDE.md deixa de ser um arquivo de preferência pessoal no momento em que mais de uma pessoa em uma equipe está de fato trabalhando 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 toda a equipe. Um colega adicionando uma instrução pontual de "hotfix" depois de uma única sessão frustrante, sem revisão, é exatamente o mecanismo que produz arquivos inchados e autocontraditórios que deixam de ser seguidos de forma confiável. Uma etapa de revisão leve, 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 na escala de equipe do que para um usuário solo. Quando uma pessoa está escrevendo e revisando o próprio trabalho assistido por agente, há pelo menos uma chance de ela pessoalmente capturar algo que o agente deixou passar. Quando uma equipe depende da saída do Claude Code fluindo por um processo de revisão compartilhado, o princípio de avaliação separada de antes deixa de ser opcional; é o mecanismo real que protege a base de código de uma autoavaliação confiante,
