Em 13 de abril, a abmedia reportou que Forrest Chang tinha organizado as reclamações do Karpathy sobre o facto de a Claude escrever código num post anterior de janeiro, em “4 regras CLAUDE.md”, acumulando nessa altura 15.000 estrelas no GitHub; a 12 de maio, o número de estrelas desse repositório já tinha ultrapassado 126.000, crescendo 8 vezes em menos de 1 mês. Em seguida, surgiram várias tentativas “versão alargada”, e o post “adicionar mais 8 em cima das 4, ficando com uma versão completa de 12 regras” publicado a 9 de maio pelo engenheiro Mnilax (@Mnimiy) recolheu 5.968 gostos, sendo um dos conteúdos individuais mais discutidos recentemente na comunidade Claude Code.
Revisão das 4 regras: Forrest Chang transformou as queixas do Karpathy em modelos executáveis
As 4 regras originais do Forrest Chang (cada uma corresponde aos padrões de falha que Karpathy assinalou no X em janeiro):
Think Before Coding (pensa antes de escrever): não faças pressupostos implícitos; deixa claro em que pressupostos estás a partir; quando houver trade-off, discute-o; se não tiveres certeza, pergunta diretamente, não adivinhes; opõe-te a soluções complexas quando exista um caminho mais simples
Simplicity First (primeiro a simplicidade): escreve o código mínimo que resolve o problema; não escrevas funcionalidades especulativas, nem cries camadas de abstração para código de uma única utilização; engenheiros séniores diriam que designs demasiado complexos devem ser simplificados
Surgical Changes (mudanças cirúrgicas): só mexe no que precisa de ser mexido, não “melhories” código adjacente por instinto, comentários, formatação; não faças refatorações no que não está mal; alinhar com o estilo existente
Goal-Driven Execution (execução orientada por objetivos): define critérios de sucesso e itera até validares; não digas ao Claude os passos, diz-lhe como deve ser o “sucesso” para ele fazer o loop por si
A documentação oficial da Anthropic deixa isto bem claro: o CLAUDE.md é um ficheiro “advisory” e o Claude deve cumprir cerca de 80% das vezes; após mais de 200 linhas, a taxa de conformidade cai drasticamente, porque as regras importantes ficam soterradas por ruído. A proposta do Forrest Chang comprime as regras para 65 linhas, 4 regras, atingindo o “floor” (o limiar mínimo).
As 8 regras adicionadas pelo Mnilax: acrescentar novos padrões de falha da era do agent em 2026/5
O Mnilax defende que as queixas do Karpathy em janeiro estavam concentradas no cenário de “Claude a escrever código”, mas em maio a ecologia Claude Code evoluiu para cenários novos como colaboração entre múltiplos agentes, integração de hooks, conflitos ao carregar skills e fluxos de trabalho com vários passos que atravessam sessões—sendo necessário acrescentar regras. As 8 regras que ele adicionou (ordenadas pela sequência do texto original) são:
Rule 5: usa a Claude apenas para tarefas que precisam de julgamento (classificação, rascunho, resumo, extração); decisões determinísticas (retentar 503, routing, tratamento de status code, transformações determinísticas) devem ser tratadas por código normal
Rule 6: Token budget não é sugestão—limite de 4.000 tokens por tarefa e 30.000 tokens por sessão; quando estiveres perto do limite, resgatares com resumo e reinício proativamente, não ultrapasses em silêncio
Rule 7: dois padrões de código em conflito têm de “clarificar escolher um” (preferir o mais recente, o que tem mais testes), explicar por que escolhes esse, e marcar o outro para limpar; misturar os dois padrões é a pior opção
Rule 8: antes de escrever código, primeiro lê—ler ficheiros exports, chamar diretamente o caller, usar utilitários partilhados; “looks orthogonal” (parece não relacionado) é a formulação mais perigosa—se não tiveres certeza, tens de perguntar
Rule 9: os testes devem validar “intenção”, não apenas “comportamento”—só conta se conseguires escrever um teste que falharia quando a lógica de negócio mudar; caso contrário, é só aumentar a confiança do Claude, sem proteção real
Rule 10: tarefas com vários passos precisam de checkpoint—após cada passo concluído, resume “o que fizeste, o que validaste, o que falta”; se não conseguires descrever claramente o estado, não continues
Rule 11: segue as convenções do codebase existente, mesmo que não concordes—snake_case continua snake_case, component de classe continua component de classe; se não concordares, trate isso como outro debate, não te aventures a divergir sozinho
Rule 12: falha tem de ser barulhenta—“migration concluída” não está correta se saltaste 30 itens; “testes passaram” não está correto se saltaste qualquer um; por defeito, “revelar ativamente a incerteza”, não “esconder a incerteza”
O Mnilax diz que testou estas 12 regras em 30 codebases, durante 6 semanas, afirmando que a taxa de erros caiu de 41% para 3%, e que a taxa de conformidade desceu apenas ligeiramente (78% → 76%). A nossa observação como media: estes números são auto-reportados pelo autor, não validados de forma independente; ainda assim, o conteúdo das 8 regras por si é sólido e corresponde aos pontos problemáticos quando se usa Claude Code com múltiplos agentes atualmente (por exemplo, gestão de várias sessões no Agent View, Multi-Agent Layer na estrutura em seis camadas).
Cenários de aplicação e recomendações pragmáticas
O Mnilax também aponta de forma direta quais as abordagens que não se deve tentar:
Mais de 14 regras: a conformidade cai para 52% (de 76% uma queda acentuada), e 200 linhas passam a ser um limite prático real
Substituir regras por exemplos: o custo em tokens de 3 exemplos equivale a 10 regras, e o Claude tende a sobreajustar a um único exemplo
Instruções abstratas como “Be careful / think hard / really focus”: baixa verificabilidade, e a conformidade é apenas 30%
Dizer ao Claude para “agir como um engenheiro sénior”: prompts de identity não funcionam para alterar comportamento; apenas instruções do tipo regra funcionam
Depender de ferramentas específicas: “usar sempre eslint” falha de forma silenciosa quando o eslint não está instalado; trocar por redações com capacidade neutra, como “alinhar com o estilo existente do codebase”
A forma pragmática sugerida por este media: o CLAUDE.md é um “contrato de comportamento”, não uma lista de desejos—cada regra precisa de responder a que erro específico esta regra evita. Se o teu trabalho não envolve pipelines com vários passos, então a Rule 10 (checkpoint) é irrelevante; se o codebase já tem lint a forçar um único estilo, a Rule 11 (alinhar com convenções) é redundante. Depois de leres as 12 regras, guarda uma versão que corresponda aos “vales” que realmente já pisaste; o resto pode ser eliminado.
Os eventos que ainda podem ser acompanhados incluem: se a Anthropic oficial vai “normalizar” as regras do CLAUDE.md (atualmente apenas “advisory”), se o repositório do Forrest Chang vai entrar em modelos oficiais recomendados, se a comunidade vai surgir com versões personalizadas para domínios específicos (frontend/backend/data engineering) e se, após atualizações da versão do modelo Claude, a taxa de conformidade das regras muda.
Este artigo Karpathy CLAUDE.md bate 126K estrelas: organização das regras avançadas de 12 em versão comunitária, com a publicação original no ABMedia—News Link.
