4 月 13 日, abmedia relatou que Forrest Chang organizou as reclamações de Karpathy sobre a criação de código feita pelo Claude em “4 regras do CLAUDE.md”; na época, o repositório no GitHub havia acumulado 15.000 estrelas. Em 12 de maio, o número de estrelas desse repo já havia ultrapassado 126.000; em menos de 1 mês, o crescimento foi de 8 vezes. A comunidade então passou a surgir com várias tentativas de “versões estendidas”; entre elas, o post de 9 de maio do engenheiro Mnilax (@Mnimiy), “adicionando 8 regras sobre as 4 originais, virando uma versão completa com 12 regras”, recebeu 5.968 curtidas e se tornou um dos conteúdos mais comentados recentemente na comunidade do Claude Code.
Revisão das 4 regras: Forrest Chang transforma as reclamações de Karpathy em um template executável
As 4 regras originais de Forrest Chang (cada uma corresponde aos padrões de falha que Karpathy apontou em janeiro no X):
Pense Antes de Codar (antes de escrever): não faça suposições implícitas; deixe claro em quais suposições você está se baseando; ao lidar com trade-offs, exponha e discuta; se não tiver certeza, pergunte diretamente, não adivinhe; quando houver uma forma mais simples, seja contra soluções complexas
Simplicidade em Primeiro Lugar: escreva o menor código possível que resolva o problema; não implemente funcionalidades especulativas, nem abstrações para código que é apenas pontual; engenheiros experientes costumam dizer que projetos complexos demais devem ser simplificados
Mudanças Cirúrgicas: mexa só no que precisa ser mexido, sem “melhorar por tabela” trechos adjacentes de código, comentários ou formatação; não refatore o que não está quebrado; alinhe-se ao estilo existente
Execução Orientada a Metas: defina critérios de sucesso e itere até validar; não diga ao Claude os passos — diga como é “o sucesso”, para ele próprio fazer o loop
A documentação oficial da Anthropic na verdade deixa isso bem claro: CLAUDE.md é um arquivo “advisory” (conselho), e o Claude tende a seguir em cerca de 80% das vezes. Depois de mais de 200 linhas, a taxa de conformidade cai drasticamente, porque as regras importantes ficam soterradas por ruído. A proposta de Forrest Chang comprime as regras para 65 linhas, em 4 pontos, atingindo o “floor” (limite mínimo).
As 8 regras adicionadas por Mnilax: novos padrões de falha da era de agents em 2026/5
Mnilax argumenta: as reclamações de Karpathy em janeiro se concentraram no cenário de “o Claude escrevendo código”, mas em maio de 2026 a ecologia do Claude Code já evoluiu para cooperação de múltiplos agents, encadeamento via hooks, conflitos no carregamento de skills e fluxos de trabalho com múltiplas etapas atravessando sessões — portanto, é preciso adicionar regras. A seguir estão as 8 regras que ele acrescentou (organizadas na ordem original):
Regra 5: use o Claude apenas para tarefas que exigem julgamento (classificação, redação, resumo, extração); decisões determinísticas (retries de 503, roteamento, tratamento de status code, conversões determinísticas) devem ser tratadas com código comum
Regra 6: o token budget não é sugestão — limite de 4.000 tokens por tarefa e 30.000 tokens por sessão; ao se aproximar do budget, resuma e reinicie proativamente; não ultrapasse em silêncio
Regra 7: dois padrões de código conflitantes devem “indicar explicitamente que um será escolhido” (pegar o mais novo, o que tem mais testes), explicar por que foi escolhido e marcar o outro como algo a ser limpo; misturar dois padrões é a pior escolha
Regra 8: antes de escrever código, primeiro entenda — leia exports, chame direto o caller, use utilities compartilhadas; “parece não relacionado (looks orthogonal)” é a frase mais perigosa; se não tiver certeza, pergunte
Regra 9: testes devem validar “intenção”, não apenas “comportamento” — um teste só é válido se der para escrever um que falhe quando a lógica do negócio muda; caso contrário, é só fazer o Claude ficar confiante, sem proteção real
Regra 10: tarefas com múltiplas etapas precisam de checkpoint — ao completar cada etapa, resuma “o que foi feito, o que foi validado e o que resta”; se você não conseguir descrever o estado com clareza, não continue
Regra 11: siga as convenções do codebase existente, mesmo que você não concorde — snake_case continua snake_case, component de classe continua component de classe; se não concordar, trate como outro debate, não faça uma bifurcação unilateral
Regra 12: falhas precisam ser barulhentas — “migração concluída” não vale se você pular 30 itens; “testes passaram” não vale se você pular qualquer um; por padrão, “revelar ativamente a incerteza” e não “esconder a incerteza”
Mnilax afirma que testou essas 12 regras em 30 codebases, dentro de 6 semanas; ele diz que a taxa de erro caiu de 41% para 3%, e que a taxa de conformidade caiu apenas um pouco (78% → 76%). Observação deste veículo: esses números são testes declarados pelo autor, sem verificação independente; ainda assim, o conteúdo das 8 regras em si é sólido e corresponde às dores do uso atual do Claude Code em contextos de múltiplos agentes (como a gestão de múltiplas sessões no Agent View, e o Multi-Agent Layer na arquitetura em seis camadas).
Cenários de aplicação e recomendações práticas
Mnilax também aponta, de forma direta, quais abordagens não vale a pena tentar:
Mais de 14 regras: conformidade cai para 52% (queda brusca de 76%), e 200 linhas na prática é o limite real
Substituir regras por exemplos: o custo de tokens de 3 exemplos é igual ao de 10 regras; o Claude tende a overfitar um único exemplo
Instruções abstratas como “Be careful / think hard / really focus”: baixa verificabilidade, e a conformidade fica apenas em 30%
Mandar o Claude “como se fosse um engenheiro sênior”: identity prompt não funciona para mudança de comportamento; apenas instruções baseadas em regras têm efeito
Confiar em ferramentas específicas: “use sempre eslint” quando o eslint não estiver instalado falha silenciosamente; trocar por uma redação neutra como “acompanhe o estilo já existente do codebase” reduz esse risco
A recomendação prática deste veículo para adoção: CLAUDE.md é um “contrato de comportamento”, não uma lista de desejos — cada regra deve responder “que erro específico esta regra evita”. Se seu trabalho não envolve um pipeline com múltiplas etapas, a Rule 10 (checkpoint) é irrelevante; se o codebase já tem lint impondo um estilo único, a Rule 11 (acompanhar convenções) é redundante. Depois de ler as 12 regras, preserve apenas a versão que mapeia os “percalços que você realmente já enfrentou”; o restante pode ser removido.
Entre os eventos que podem ser acompanhados a seguir estão: se a Anthropic oficial vai “padronizar” as regras do CLAUDE.md (por enquanto, apenas “advisory”); se o repo de Forrest Chang vai entrar como um template recomendado oficialmente; se a comunidade vai aparecer com versões customizadas para domínios específicos (front-end/back-end/data engineering); e se, após atualização da versão dos modelos Claude, a taxa de conformidade com as regras muda.
Este artigo “Karpathy CLAUDE.md bate 126K estrelas: organização das regras avançadas em 12 versões da comunidade” foi publicado pela primeira vez em Cadeia de Notícias ABMedia.
