Karpathy CLAUDE.md Skills: Instalei. Veredicto Real

Karpathy CLAUDE.md Skills: Instalei. Veredicto Real

Na terça-feira passada, pedi ao Claude Code para corrigir uma única verificação de null em uma classe de serviço Laravel. Uma linha. Null-coalesce em vez de um if aninhado.

Ele voltou com um diff de 214 linhas.

Novas constantes de classe. Um método renomeado. Quatro refatorações não relacionadas em arquivos que eu nem havia aberto. Um comentário em bloco no estilo "já que estamos aqui" explicando por que o autor anterior estava errado. A verificação de null estava enterrada na linha 138, correta, cercada por uma reorganização completa de um arquivo que vinha funcionando bem havia onze meses.

Esse é o comportamento que o plugin Karpathy CLAUDE.md skills foi projetado para interromper. E depois de instalá-lo em três projetos distintos — uma base de código de agência Laravel 13, um projeto pessoal em Next.js 15 e o pipeline de conteúdo que move este blog — estou pronto para te contar o que realmente muda, onde as barreiras seguram e onde não seguram.

Se você leu minhas anotações da primeira construção do workflow Claude Routines com Opus 4.7, já sabe que tenho vivido dentro do Claude Code em tempo integral. Este post é o complemento natural: uma vez que você está no Claude Code todos os dias, percebe exatamente quais comportamentos consomem suas manhãs — e o plugin Karpathy skills mira nos quatro piores.

Por Que Este Repo Chegou a 71,5 mil Estrelas em Menos de um Mês

O projeto se chama andrej-karpathy-skills. No momento em que escrevo isto, ele está com 71,5 mil estrelas, 6,5 mil forks, 28 commits e 8 contribuidores. Essa é uma proporção absurda de estrelas por commit. A maioria dos repositórios que bombam assim são frameworks com 50.000 linhas de código. Este aqui é essencialmente um único arquivo CLAUDE.md mais um manifesto de plugin, um diretório de skills, uma pasta de rules do Cursor e um punhado de exemplos.

Esse é o produto inteiro. Um arquivo markdown que remodela como o Claude Code se comporta.

A razão pela qual explodiu é simples: ele nomeia os quatro modos de falha com os quais todo engenheiro em atividade tem xingado seu assistente de IA no último ano, e empacota a correção como quatro princípios nomeados que o Claude realmente respeita uma vez que estão na janela de contexto. Andrej Karpathy não escreveu o repo (é do forrestchang), mas os princípios foram destilados diretamente das observações públicas de Karpathy no X sobre armadilhas de LLMs em código — sobretudo a famosa descrição que ele faz dos assistentes de IA como "um estagiário júnior savant ávido demais, com conhecimento enciclopédico de software, mas que também te enrola o tempo todo, tem uma coragem excessiva e mostra pouco ou nenhum bom gosto para código."

Essa única citação explica o repo inteiro. O estagiário é brilhante. O estagiário também é perigoso sem coleira.

O plugin Karpathy CLAUDE.md skills é a coleira.

O Que Está Realmente no Repo

Antes da instalação, você precisa saber o que está trazendo. Esta é a estrutura de diretórios na raiz:

.claude-plugin/
  plugin.json
.cursor/
  rules/
    karpathy-guidelines.mdc
skills/
  karpathy-guidelines/
    SKILL.md
CLAUDE.md
CURSOR.md
EXAMPLES.md
README.md
README.zh.md
LICENSE

Quatro mecanismos de entrega, os mesmos quatro princípios:

1. CLAUDE.md — o arquivo drop-in para raízes de projeto do Claude Code
2. .claude-plugin/plugin.json — o manifesto para o fluxo de marketplace de plugins do Claude Code
3. skills/karpathy-guidelines/SKILL.md — a versão em formato de skill compatível com o ecossistema skills.sh que eu cobri no início deste ano
4. .cursor/rules/karpathy-guidelines.mdc — o equivalente do Cursor, adicionado nos últimos commits

O manifesto do plugin é deliberadamente minúsculo. Aqui está ele na íntegra:

{
  "name": "andrej-karpathy-skills",
  "description": "Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls",
  "version": "1.0.0",
  "author": {
    "name": "forrestchang"
  },
  "license": "MIT",
  "keywords": ["guidelines", "best-practices", "coding", "karpathy"],
  "skills": ["./skills/karpathy-guidelines"]
}

Uma versão, uma referência de skill, licença MIT. Sem dependências. Sem scripts pós-instalação. Sem telemetria. Esse é o tipo de repo que confio em instalar sem ler cada byte — mas li cada byte de qualquer forma, e você também deveria.

Agora a parte interessante. Os quatro princípios em si.

Os Quatro Princípios, Na Íntegra do CLAUDE.md

Vou citá-los exatamente como aparecem no arquivo-fonte, porque parafraseá-los tira o corte. A especificidade é o ponto.

1. Think Before Coding

"Don't assume. Don't hide confusion. Surface tradeoffs."

• Declare suas suposições explicitamente. Se estiver em dúvida, pergunte.
• Se existirem múltiplas interpretações, apresente-as — não escolha em silêncio.
• Se existir uma abordagem mais simples, diga. Contra-argumente quando justificado.
• Se algo estiver obscuro, pare. Nomeie o que está confuso. Pergunte.

Modo de falha que isto previne: suposições silenciosas. O pior comportamento em programação assistida por IA. Você pede "um endpoint de exportação de usuários" e recebe de volta um download em CSV servindo cada campo do banco de dados porque o modelo decidiu que você queria isso. Sem este princípio, o Claude adivinha. Com ele, o Claude pergunta se a exportação deve ser limitada por escopo, quais campos são sensíveis e se você precisa de JSON ou CSV antes de escrever uma única linha.

2. Simplicity First

"Minimum code that solves the problem. Nothing speculative."

• Nenhuma funcionalidade além do que foi pedido.
• Nenhuma abstração para código de uso único.
• Nenhuma "flexibilidade" ou "configurabilidade" que não foi solicitada.
• Nenhum tratamento de erro para cenários impossíveis.
• Se você escrever 200 linhas e poderia ser 50, reescreva.

Modo de falha que isto previne: o problema do padrão-estratégia-para-um-único-if. Você pede um cálculo de desconto e recebe de volta um DiscountStrategyFactory abstrato com regras de arredondamento configuráveis, um enum de tipos de promoção e um dataclass DiscountContext. O problema real era price * 0.1. Este princípio é por que meus projetos de teste caíram de implementações excessivas de 180 linhas para versões de 30 linhas sem perder uma única funcionalidade real. É o mesmo padrão de sobre-engenharia que apontei em três dos modelos no meu roundup de ferramentas de IA de abril de 2026 — quase todo modelo de fronteira vai alegremente construir a catedral para você quando você pediu um barracão.

3. Surgical Changes

"Touch only what you must. Clean up only your own mess."

• Não "melhore" código, comentários ou formatação adjacentes.
• Não refatore coisas que não estão quebradas.
• Respeite o estilo existente, mesmo que você fizesse de outro jeito.
• Se notar código morto não relacionado, mencione — não delete.
• Remova imports/variáveis/funções que SUAS mudanças tornaram não usadas.
• Não remova código morto pré-existente a menos que seja pedido.

Modo de falha que isto previne: a refatoração drive-by. O comportamento exato que consumiu minha manhã de terça. Este é o princípio com o maior impacto percebido. Com ele ativo, o diff de 214 linhas vira um diff de 1 linha, e o Claude te diz no final "Notei que a classe tem três imports não utilizados vindos de uma refatoração de dois commits atrás — quer que eu trate disso separadamente?" em vez de simplesmente deletá-los.

4. Goal-Driven Execution

"Define success criteria. Loop until verified."

• Transforme tarefas em objetivos verificáveis
• Para tarefas de múltiplas etapas, enuncie um plano breve com passos e checagens de verificação
• Critérios de sucesso fortes permitem que você faça loop de forma independente

Modo de falha que isto previne: o término "acho que terminei" baseado em vibes. O próprio enquadramento de Karpathy sobre isso é a frase mais afiada do repo inteiro: "LLMs are exceptionally good at looping until they meet specific goals… Don't tell it what to do, give it success criteria and watch it go." Uma vez que este princípio é carregado, o Claude para de dizer "Adicionei rate limiting, me avise se precisar de mais alguma coisa" e começa a dizer "Rate limiting adicionado. Plano de verificação: (a) curl 10 requisições abaixo do limite e esperar 200s, (b) curl 11 e esperar um 429 na última, (c) rodar a suíte de testes existente. Rodando agora."

Esses quatro tópicos são todo o framework. Todo o resto neste post é sobre como carregá-los, como mantê-los carregados e como saber se estão funcionando.

Os Três Caminhos de Instalação — e Qual Você Realmente Quer

O repo envia três caminhos de instalação porque existem três contextos diferentes em que você pode querer esses princípios ativos. Testei os três. Cada um tem um caso de uso específico, e misturá-los desperdiça tokens e causa colisões de regras.

Caminho A — A Instalação do Plugin do Claude Code

Este é o caminho mais limpo se você quer as diretrizes disponíveis em toda sessão do Claude Code na sua máquina, independentemente de qualquer projeto. Dois comandos:

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

Esses são slash commands que você cola dentro do próprio Claude Code, não bash. O primeiro adiciona o repo como fonte de marketplace de plugins. O segundo instala o plugin, que registra o arquivo skills/karpathy-guidelines/SKILL.md como um skill disponível. O Claude vai carregá-lo automaticamente quando a sessão casar com a descrição de ativação do skill.

Onde os arquivos realmente aterrissam: o Claude Code armazena plugins instalados em ~/.claude/plugins/andrej-karpathy-skills/. O manifesto do skill fica em ~/.claude/plugins/andrej-karpathy-skills/skills/karpathy-guidelines/SKILL.md. Você pode verificar com:

ls -la ~/.claude/plugins/andrej-karpathy-skills/
cat ~/.claude/plugins/andrej-karpathy-skills/.claude-plugin/plugin.json

Quando usar: você quer os princípios ativos globalmente, em todos os repos, sem tocar em nenhum arquivo de projeto. Melhor para desenvolvedores solo em máquinas onde você é o único usuário.

Quando pular: você está numa base de código de time. O carregamento em nível de skill é por usuário, então seus colegas de time não terão o mesmo comportamento. Para consistência de time, você quer o Caminho B.

Caminho B — O Drop-in (ou Merge) do CLAUDE.md na Raiz do Projeto

Este é o caminho que uso em todo projeto real de cliente. As diretrizes ficam no repo, são versionadas junto com o código, e todo colega de time que rodar o Claude Code naquele checkout pega o mesmo comportamento automaticamente.

Se o projeto ainda não tem um CLAUDE.md, é um único comando:

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

Commite. Feito. A próxima sessão de claude naquele diretório carrega os quatro princípios no contexto do sistema antes da sua primeira mensagem.

Se o projeto já tem um CLAUDE.md — o que provavelmente tem — não sobrescreva. Fiz isso uma vez no repo ai-agents-team (o que move este blog) e perdi toda a minha configuração de geração de conteúdo por cerca de noventa segundos antes de perceber o que tinha acontecido e recuperar do git. Não seja eu.

Em vez disso, faça merge. Aqui está o workflow exato que uso agora:

# 1. Fetch the Karpathy principles to a temp file
curl -o .karpathy-skills-temp.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

# 2. Append as a new section to your existing CLAUDE.md
{
  echo ""
  echo "---"
  echo ""
  echo "# Coding Behavior (Karpathy Guidelines)"
  echo ""
  echo "_Source: https://github.com/forrestchang/andrej-karpathy-skills — MIT_"
  echo ""
  cat .karpathy-skills-temp.md
} >> CLAUDE.md

# 3. Clean up the temp file
rm .karpathy-skills-temp.md

# 4. Verify the result opens cleanly and your original rules are still on top
head -40 CLAUDE.md
tail -60 CLAUDE.md

A regra de ordenação das seções importa. O Claude trata regras anteriores no CLAUDE.md como de prioridade maior quando regras entram em conflito. Você quer comportamento específico do projeto (seus templates de conteúdo, suas convenções Laravel, suas regras de deploy) no topo, e os princípios Karpathy como uma seção geral de comportamento de código mais abaixo. Eles são meta-regras sobre como o Claude deve abordar o código — não regras de domínio sobre o que o Claude deve construir — então eles pertencem ao final do arquivo, não ao início.

Quando usar: qualquer base de código de time, qualquer projeto com o qual você se importa a longo prazo, qualquer repo onde você quer comportamento de agente versionado.

Caminho C — A Instalação no Cursor

Se você está no Cursor em vez do Claude Code, o repo envia um arquivo .cursor/rules/karpathy-guidelines.mdc que funciona com o sistema de rules do Cursor. Instale copiando o arquivo para o seu projeto:

mkdir -p .cursor/rules
curl -o .cursor/rules/karpathy-guidelines.mdc \
  https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/.cursor/rules/karpathy-guidelines.mdc

O engine de rules do Cursor carrega automaticamente qualquer arquivo .mdc em .cursor/rules/ ao abrir o projeto, então isso ativa na próxima sessão. O conteúdo são os mesmos quatro princípios no formato de rule do Cursor — um arquivo .mdc é só markdown com um bloco curto de frontmatter declarando quando a rule deve se aplicar.

Quando usar: você está principalmente no Cursor. Eu ainda rodo Claude Code para trabalho agêntico, então instalo ambos — os arquivos não entram em conflito porque estão em diretórios específicos de ferramenta diferentes.

Como Verificar Que Está Realmente Ativo

Instalar é uma coisa. Saber se está fazendo alguma coisa é outra. Todo sistema de skill/plugin que já usei tem um problema do tipo "isso carregou mesmo?", e a resposta nunca é apenas confiar na mensagem de instalação.

Aqui está minha verificação de três etapas que rodo depois de toda instalação:

Etapa 1 — Teste de read-back. Abra uma sessão nova do Claude Code no projeto e pergunte:

"Quais princípios de comportamento de código estão atualmente carregados no seu contexto? Liste-os com a fonte."

Se a instalação funcionou, o Claude vai listar os quatro princípios Karpathy pelo nome — Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution — e citar o arquivo CLAUDE.md ou o skill do plugin como a fonte. Se ele listar "boas práticas de programação" genéricas sem os nomes Karpathy, algo está errado: ou o arquivo não foi salvo, ou o plugin não instalou, ou você está num diretório que o Claude não considera a raiz do projeto.

Etapa 2 — Teste comportamental. Dê a ele uma tarefa especificamente projetada para disparar o velho comportamento ruim:

"Corrija a verificação de null na linha 42 do UserService.php."

Sem as diretrizes: diff espalhado, refatoração não solicitada, mudanças de estilo, a experiência completa de manhã de terça-feira. Com as diretrizes: o Claude deve fazer exatamente o que você pediu, fazer a edição mínima e sinalizar qualquer outra coisa que notou em uma mensagem separada em vez de enviar junto.

Etapa 3 — Armadilha de scope creep. Esta é a que realmente te diz.

"Adicione um rate limit ao endpoint de login. Já que está aí, adicione também logging de requisições."

Sem as diretrizes: o Claude faz as duas coisas, enquadra como uma mudança única e provavelmente joga uma refatoração do middleware de auth de brinde. Com Goal-Driven Execution ativo, o Claude deve separar as tarefas, declarar critérios de sucesso para cada uma e — este é o sinal — propor checagens de verificação para o rate limit especificamente antes de tocar na tarefa de logging. Se ele colapsar tudo em uma única mudança não verificada, os princípios não estão carregados corretamente.

Rodei esse teste de três etapas em toda instalação. Leva cerca de quatro minutos. Pule-o e você está confiando no auto-relato do modelo sobre se as barreiras estão de pé, e auto-relato é exatamente a coisa que esses princípios foram projetados para desconfiar.

Mesclando com um Setup Existente (o Caso do Mundo Real)

Tudo acima pressupõe uma instalação limpa. O caso mais difícil — e o que a maioria dos engenheiros que conheço realmente enfrenta — é mesclar esses princípios num projeto que já tem um CLAUDE.md opinado com suas próprias regras.

O repo deste blog é um bom exemplo. O projeto ai-agents-team tem um CLAUDE.md de geração de conteúdo definindo as regras de voz da Aria, configurações de marca, convenções de nome de arquivo, e uma pilha de restrições duras ("sem frases de enchimento de IA", "mínimo 3.000+ palavras", "sem frontmatter YAML em posts"). Os princípios de Karpathy são sobre comportamento de código, não comportamento de conteúdo, mas eu queria mesmo assim carregados para quando o trabalho da Aria transborda para código de verdade — quando estou pedindo ao repo para refatorar uma definição de agente, atualizar um hook ou adicionar um novo arquivo de skill.

A estrutura com a qual acabei após algumas iterações:

# CLAUDE.md

<Project-specific identity and purpose goes first>

## Project Overview
...

## Architecture
...

## Hard Constraints
<Domain rules — these are non-negotiable and win any conflict>
...

---

# Coding Behavior (Karpathy Guidelines)

<Source: https://github.com/forrestchang/andrej-karpathy-skills — MIT>

<The four principles verbatim, dropped in as an appendix>

A linha horizontal antes da seção de comportamento de código é deliberada. Ela dá ao Claude uma pista estrutural visual de que a seção seguinte é uma preocupação diferente — meta-regras sobre como escrever código, ao contrário de regras de domínio sobre o que o projeto faz. Nos meus testes, o Claude respeita essa separação: quando estou editando conteúdo, ele segue as regras de conteúdo do topo; quando estou editando código, ele puxa a seção Karpathy e a aplica.

Três regras para mesclar sem quebrar seu setup existente:

1. Regras específicas de projeto ficam no topo. Sua voz de marca, suas escolhas de framework, suas convenções de nome de arquivo, sua lista de frases proibidas — essas são regras de domínio e precisam vencer qualquer conflito. Coloque-as acima da seção Karpathy.

2. Mantenha a atribuição de fonte. Uma linha: Source: https://github.com/forrestchang/andrej-karpathy-skills — MIT. É licenciado sob MIT, então você está livre para colocar, mas a atribuição importa por dois motivos: ela deixa o você-do-futuro saber de onde vieram os princípios se algum dia parecerem errados, e sinaliza ao Claude (que lê essas coisas) que esta seção tem proveniência externa.

3. Nunca misture a redação dos princípios com as regras do seu projeto. Se você quiser referenciar Simplicity First dentro de uma regra específica do projeto ("aplique Simplicity First aqui — sem abstrações especulativas"), tudo bem. O que não está tudo bem é parafrasear os princípios na sua própria seção do projeto e abandonar a redação literal. A especificidade da redação original é o que faz os princípios funcionarem, e reescrevê-los na sua própria linguagem amortece o corte que o Claude precisa para reconhecê-los.

Isso não substitui superpowers, skills, ou qualquer um dos outros sistemas comportamentais que você já tem carregados. Ele complementa. Os princípios Karpathy são estreitos — eles governam como mudanças de código são feitas, não o que o projeto é, não quais ferramentas são usadas, não quais são suas convenções de domínio. Empilhados em cima de um CLAUDE.md de projeto forte, eles são um upgrade líquido. Empilhados em vez de um, deixam o Claude sem qualquer contexto de domínio e você vai odiar o resultado.

Um exemplo concreto do meu próprio stack: o pipeline deste blog usa o Claude programmatic SEO skill que construí anteriormente para otimização on-page automatizada. Aquele skill fica acima da seção Karpathy no meu CLAUDE.md porque é uma regra de domínio — define o que é escrito. Os princípios Karpathy ficam abaixo porque são meta-regras — eles definem como o código por trás daquele skill é editado quando eu o refatoro. Preocupações separadas, seções separadas, sem colisões.

Minha Opinião Direta — Onde Isto Ganha, Onde Não Ganha

Vou te poupar da versão diplomática. Aqui vai a avaliação direta depois de uma semana de uso:

Onde isto ganha — e ganha feio: nos quatro modos de falha exatos que transformaram a programação assistida por IA de "incrível" em "frustrante" no último ano. Suposições silenciosas. Sobre-engenharia. Refatorações drive-by. Vibes de "acho que terminei". Todos os quatro são agora mensuravelmente menos frequentes nas minhas sessões. O incidente de 214 linhas de verificação de null na manhã de terça não se repetiu desde que instalei. Meu tamanho médio de diff para pequenas tarefas de correção de bug caiu de forma significativa — o padrão consistente nos três projetos é algo como um terço da contagem de linhas para a mesma tarefa, sem perda de correção.

O princípio Goal-Driven Execution é o trunfo escondido. Ele soa como o mais chato dos quatro, mas é o que mais muda seu workflow. Uma vez que o Claude começa a declarar critérios de verificação antecipadamente, você para de escrever prompts como "adicione validação" e começa a escrever prompts como "adicione validação para e-mails vazios — sucesso = o caso de teste X passa." Essa mudança sozinha me fez um prompter mensuravelmente melhor, o que é um efeito colateral estranho de se obter ao instalar o arquivo markdown de outra pessoa.

Onde isto é limitado: quatro princípios não substituem conhecimento de domínio. O Claude com as diretrizes Karpathy carregadas ainda não sabe que sua base de código Laravel usa form requests em vez de validação inline, ou que seu projeto React usa server components em todo lugar, ou que sua API retorna snake_case neste um endpoint por razões legadas. Os princípios impedem o Claude de piorar as coisas — eles não deixam o Claude mais inteligente sobre seu stack específico. Você ainda precisa de um CLAUDE.md específico do projeto. Você ainda precisa de skills. Você ainda precisa de bons prompts.

Onde isto me irrita ativamente: para tarefas triviais, os princípios adicionam atrito. Pedir ao Claude para renomear uma variável agora ocasionalmente me rende uma confirmação de três linhas sobre escopo antes do rename acontecer. As próprias diretrizes reconhecem isso ("as diretrizes inclinam para cautela em vez de velocidade — útil para trabalho não trivial enquanto mantém julgamento para tarefas simples"), mas na prática, o modelo nem sempre distingue. Desenvolvi um hábito pessoal de adicionar "mudança trivial única, não precisa de verificação" a prompts onde sei que o escopo são dois caracteres. Funciona. Mas é uma gambiarra, não uma correção.

Instale se: você escreve código real para projetos reais, trabalha com assistentes de IA de código diariamente, e já foi mordido por scope creep, suposições silenciosas ou refatorações drive-by no último mês. A barra para valor aqui é baixa o suficiente para que qualquer pessoa que envie código de produção já deveria tê-lo instalado.

Pule se: você está usando o Claude Code puramente para prototipagem descartável, trabalho de spike ou vibe coding onde velocidade importa mais que disciplina de escopo. As diretrizes vão atrapalhar. Elas não foram projetadas para o modo que o próprio Karpathy descreveu como "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Foram projetadas para o modo que ele descreveu depois — aquele em que você é "slow, defensive, careful, paranoid" com código com o qual você realmente se importa.

Para o pipeline deste blog e todo projeto de cliente que atualmente estou entregando, está dentro. Para experimentação de fim de semana, está fora. Essa é a divisão honesta.

Antes e Depois — A Verificação de Null Revisitada

Deixe eu fechar o loop que abri no topo deste post.

Rodei novamente a tarefa da manhã de terça depois de instalar as diretrizes. Mesma base de código, mesmo arquivo, mesma linha, mesmo prompt: "Corrija a verificação de null na linha 138 do UserService.php — $user->profile->avatar deve cair num default se o profile for null."

Antes das diretrizes (representativo do que aconteceu da primeira vez):

• diff de 214 linhas
• Nova constante de classe DEFAULT_AVATAR
• Método renomeado de getAvatar() para resolveAvatar() por "clareza"
• Quatro correções não relacionadas de null-coalesce em métodos que eu não tinha mencionado
• Um comentário em bloco explicando por que a abordagem do autor original tinha sido subótima
• A correção real da verificação de null, correta, na linha 138, cercada por tudo acima

Depois das diretrizes (re-rodada em uma branch nova do mesmo estado inicial):

• diff de 1 linha
• $user->profile?->avatar ?? asset('images/default-avatar.png') na linha 138
• Uma mensagem separada no final: "Notei quatro outros lugares neste arquivo onde ->profile-> é acessado sem uma verificação de null. Mesmo padrão, métodos diferentes. Quer que eu trate disso em um commit separado, ou deixo?"

Correção de uma linha. Sinalização explícita do problema adjacente. Nenhuma refatoração enviada em silêncio. O modelo ainda viu os problemas adjacentes — é a mesma inteligência — mas as diretrizes converteram a resposta de "deixa eu lidar com tudo" para "deixa eu sinalizar e você decide."

Essa é toda a proposta de valor num único antes-e-depois. O modelo não fica mais burro. Ele fica disciplinado.

Tem um motivo para o repo ter passado de 71 mil estrelas em menos de um mês. Todo engenheiro em atividade tem uma versão daquela história de manhã de terça, e cada um de nós queria um jeito de pará-la sem escrever system prompts de 50 linhas tentando explicar, nas nossas próprias palavras, o que significa "não faça refatoração drive-by". Os princípios Karpathy fazem isso em quatro seções nomeadas, com redação afiada o suficiente para que o Claude realmente os siga, pelo preço de um único comando curl. Essa é uma troca que vou aceitar toda vez.

Agora a única pergunta que vale a pena fazer é a que você deveria estar se fazendo enquanto fecha esta aba: quando foi a última vez que seu assistente de IA fez uma mudança que era três vezes maior do que o que você pediu? Se a resposta é "esta semana", você já sabe o que fazer em seguida.

Perguntas Frequentes

O que é o plugin Karpathy CLAUDE.md skills?

O plugin Karpathy CLAUDE.md skills é um único arquivo CLAUDE.md (mais um manifesto de plugin, um diretório de skill e uma pasta de rules do Cursor) que carrega quatro princípios de comportamento de código no Claude Code, derivados das observações públicas de Andrej Karpathy sobre armadilhas de LLMs em programação. É licenciado sob MIT, é enviado em github.com/forrestchang/andrej-karpathy-skills e chegou a 71,5 mil estrelas apenas no boca a boca.

Quais são os quatro princípios Karpathy para o Claude Code?

Os quatro princípios são Think Before Coding (traga suposições à tona, pergunte quando incerto), Simplicity First (código mínimo que resolve o problema, sem funcionalidades especulativas), Surgical Changes (toque só no que precisa, sem refatorações drive-by) e Goal-Driven Execution (defina critérios de sucesso verificáveis, faça loop até verificar). Veja o detalhamento literal acima para a lista completa de tópicos.

Como instalo o Karpathy CLAUDE.md em um projeto existente?

Rode curl -o .karpathy-skills-temp.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md, depois faça append ao seu CLAUDE.md existente como uma nova seção "Coding Behavior" no final. Nunca sobrescreva um CLAUDE.md existente — regras específicas do projeto precisam ficar acima da seção Karpathy para vencerem qualquer conflito. O workflow completo de merge está documentado acima.

Isto substitui Claude Code skills ou superpowers?

Não. Os princípios Karpathy são meta-regras sobre como mudanças de código são feitas — eles não conhecem seu stack, suas convenções ou seu domínio. Empilhe-os em cima do seu CLAUDE.md de projeto existente, skills e outros sistemas comportamentais. Eles complementam, não substituem. Se você instalar isto como sua única configuração, o Claude vai ser disciplinado mas cego de domínio.

Como verifico que os princípios Karpathy estão realmente carregados?

Rode uma checagem de três etapas: (1) peça ao Claude para listar os princípios de comportamento de código no seu contexto e confirme que os quatro nomes Karpathy aparecem, (2) dê a ele uma pequena tarefa de correção de bug e confira se o diff permanece cirúrgico, (3) dê a ele uma armadilha de scope creep ("conserte X, já que está aí faça também Y") e confirme que ele separa as tarefas com critérios de verificação em vez de colapsá-las. Se alguma etapa falhar, a instalação não pegou.

Vamos trabalhar juntos

Quer construir sistemas de IA, automatizar workflows ou escalar sua infraestrutura tech? Eu adoraria ajudar.

• Fiverr (builds e integrações customizadas): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções enterprise): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io