Den Karpathy-inspirerte CLAUDE.md: En realitetssjekk av adversarial planlegging

Et GitHub-repository med en enkelt CLAUDE.md-fil har i skrivende stund samlet over 100 000 stjerner. Det blir ofte referert til som «Karpathy-ferdigheten», en referanse til Andrej Karpathys arbeid innen KI og utdanning. Denne populariteten reiser et kritisk spørsmål for enhver utvikler som prøver å få mer ut av store språkmodeller: fungerer dette mønsteret faktisk?

Før vi analyserer resultatene fra testene våre, er to presiseringer essensielle. For det første ble det aktuelle repositoryet opprettet av Forrest Chang; det er Karpathy-inspirert, ikke skrevet av Karpathy. For det andre er filen en CLAUDE.md, ikke en SKILL.md. Det er et sett med instruksjoner som et menneske kan kopiere og lime inn i en chat-økt, ikke en formell ferdighet som kan installeres for å modifisere modellens atferd programmatisk.

Hos SkillProof tester vi ikke copy-paste-prompter. Vi tester ferdigheter. Vi installerer dem, kjører dem mot reell kode og måler ytelsen deres mot grunnmodellen. For å undersøke hypen identifiserte og testet vi en gruppe ferdigheter som implementerer det samme underliggende mønsteret som Changs CLAUDE.md: adversarial planlegging. Denne artikkelen presenterer funnene våre.

En analyse av «Grill-Meg»-mønsteret

Kjerneideen bak den populære CLAUDE.md er en form for strukturert selvkritikk. Prompten instruerer modellen til ikke bare å produsere et svar, men å innta en persona – et panel av ekspertkritikere – for å utfordre og forbedre sitt eget resultat før den presenterer en endelig versjon. Prosessen ser vanligvis slik ut:

1. Innledende plan: Modellen genererer en overordnet plan for å løse brukerens forespørsel.
2. Selvkritikk: Modellen blir bedt om å «grille» sin egen plan, identifisere potensielle feil, «edge cases» og implementeringsrisikoer. Den kan liste opp svakheter eller stille seg selv oppklarende spørsmål.
3. Forbedret resultat: Basert på kritikken produserer modellen et mer robust, endelig svar.

Denne teknikken er en form for adversarial planlegging. Du tvinger modellen til å fungere som sitt eget «red team», og simulerer en gjennomgangsprosess som normalt ville krevd en annen person eller et separat verifiseringstrinn. Hypotesen er at denne interne dialogen produserer et mer gjennomtenkt og korrekt resultat, spesielt for komplekse oppgaver som systemdesign eller algoritmeimplementering.

Dette er mønsteret vi satte oss for å teste. Når utviklere ber om en «karpathy claude skill review», er det denne mekanismen de spør om. Fører det å tvinge en modell til å kritisere seg selv til målbart bedre kode?

CLAUDE.md vs. SKILL.md: En kritisk forskjell

Forskjellen mellom en CLAUDE.md og en SKILL.md er ikke bare semantisk; den er fundamental for hvordan vi evaluerer ytelse.

En CLAUDE.md er en manuell prompt. Effektiviteten kan variere vilt avhengig av brukerens evne til å tilpasse den, detaljene i inputen og tilstanden til chat-økten. Det er en oppskrift, ikke et verktøy. Du kan ikke benchmarke en oppskrift på en standardisert måte.

En SKILL.md, slik den er definert og brukt i SkillProof-katalogen, er en kanonisk, versjonskontrollert fil som programmatisk endrer modellens system-prompt. Når du bruker en ferdighet fra katalogen vår, installeres den én gang. Hver påfølgende forespørsel til modellen drar nytte av (eller hemmes av) den ferdighetens instruksjoner, uten manuell kopiering og liming. Dette muliggjør repeterbar, objektiv testing.

Hele vår testmetodikk er bygget på dette prinsippet. Vi tar en SKILL.md, installerer den og kjører den mot en rekke reelle oppgaver. Vi sammenligner resultatet – med hensyn til korrekthet, effektivitet og overholdelse av krav – mot nøyaktig samme modell uten noen ferdighet installert. Den resulterende poengsummen er et direkte mål på verdien som ferdigheten har lagt til (eller trukket fra).

For denne undersøkelsen testet vi ikke Forrest Changs fil direkte. I stedet hentet vi flere ferdigheter fra communityet som formaliserer mønsteret for adversarial planlegging til et gjenbrukbart SKILL.md-format. Dette gjorde det mulig for oss å svare på spørsmålet: leverer selve mønsteret, når det brukes konsekvent, det det lover?

Vår testmetodikk for «adversarial»-ferdigheter

For å gjennomføre en rettferdig analyse av typen grill-me claude skill tested, valgte vi et representativt sett med oppgaver som er vanlige smertepunkter for utviklere, og hvor en mer «gjennomtenkt» modell teoretisk sett kunne utmerke seg:

• Kompleks refaktorering: Omskriving av en monolittisk funksjon med høy syklomatisk kompleksitet til mindre, testbare enheter.
• Generering av API-klient: Skriving av et klientbibliotek for en middels kompleks OpenAPI-spesifikasjon, inkludert feilhåndtering og request/response-modeller.
• Implementering av algoritme: Implementering av en ikke-triviell algoritme fra en prosabeskrivelse, som A* pathfinding eller en priority queue.
• Generering av enhetstester: Skriving av en omfattende pakke med enhetstester for en klasse med flere avhengigheter og «edge cases».

For hver oppgave kjørte vi to forsøk: ett med ren Claude (grunnmodellen, ingen ferdighet) og ett med en ferdighet for adversarial planlegging installert. Vi poengsatte resultatene basert på en rubrikk som inkluderer funksjonell korrekthet, kodekvalitet, fullstendighet og effektivitet. Den endelige poengsummen for en ferdighet representerer dens gjennomsnittlige ytelsesdelta på tvers av alle testede oppgaver.

Denne strenge prosessen er slik vi har evaluert alle de 1416 ferdighetene som for øyeblikket spores i systemet vårt. Det er et støyende landskap: bare 889 (63 %) av disse ferdighetene består vår test for å gi en netto positiv fordel. Ytterligere 467 krever ikke-triviell setup eller er bare nyttige i svært spesifikke sammenhenger. De «adversarial»-planleggingsferdighetene vi testet, falt inn i alle disse kategoriene.

Konklusjonen: Fungerer den Karpathy-inspirerte ferdigheten?

Svaret er nyansert. Effektiviteten til mønsteret for adversarial planlegging er svært avhengig av oppgavens kompleksitet. Det er ikke en universell forbedring. For noen oppgaver er det direkte skadelig.

Testene våre viste en klar trend:

Oppgavetype	Ytelse med ren Claude	Ytelse med «adversarial»-ferdighet	Konklusjon
Enkel «boilerplate» (f.eks. en React-komponent)	Rask, 95 % korrekt	Tregere, overkritiserer, 90 % korrekt	Negativ effekt
Kompleks refaktorering	Går ofte glipp av «edge cases»	Fanger opp flere «edge cases», men er ordrik	Netto positiv
Algoritmedesign fra bunnen av	Utsatt for logiske brister	Bedre logisk struktur, tregere	Netto positiv
Feilsøking av obskure feil	Foreslår ofte overfladiske løsninger	Utforsker dypere årsaker	Netto positiv

For enkle, veldefinerte oppgaver legger «adversarial»-mønsteret til unødvendig overhead. Modellen bruker tokens og tid på å kritisere en plan som allerede var tilstrekkelig. I noen tilfeller introduserte selvkritikkprosessen til og med feil, da modellen hallusinerte feil og deretter «fikset» dem, noe som ødela perfekt fungerende kode. Dette er et avgjørende funn for alle som lurer på om «karpathy claude md worth it for daily coding».

For komplekse, åpne oppgaver – den typen som ofte setter en juniorutvikler fast – gir mønsteret imidlertid en målbar fordel. Når den blir bedt om å designe et system eller refaktorere et innviklet stykke legacy code, tvinger selvkritikkfasen modellen til å vurdere interaksjoner og «edge cases» som ren Claude ofte overser. Det endelige resultatet er mer robust og krever mindre menneskelig korreksjon, selv om det tar lengre tid å generere og er betydelig mer ordrikt.

Én ferdighet for adversarial planlegging som vi testet, slo grunnlinjen klart på åpne systemdesignoppgaver, men scoret under den på generering av enkel «boilerplate». Dette understreker behovet for å bruke riktig ferdighet til riktig jobb, i stedet for å lete etter én enkelt «god prompt» som løser alt.

Den skjulte kostnaden: Ordrikhet og negative poengsummer

Den mest umiddelbare ulempen med dette mønsteret er ordrikhet. Et svar fra en ferdighet som bruker adversarial planlegging kan være 3–5 ganger lengre enn et svar fra ren Claude. Det inkluderer planen, den fullstendige kritikken og deretter det endelige svaret. Selv om mellomtrinnene kan gi innsikt i modellens «tankeprosess», øker de også token-forbruket og den kognitive belastningen for utvikleren som må lese alt.

Mer bekymringsfullt er risikoen for negativ ytelse. En dårlig implementert ferdighet er verre enn ingen ferdighet i det hele tatt. Hos SkillProof er vårt viktigste funn ikke listen over ferdigheter som fungerer, men listen over de som ikke gjør det. Per i dag har 60 ferdigheter vi har testet scoret UNDER ren Claude. De gjør aktivt modellen mindre nøyaktig, mindre effektiv eller mindre pålitelig.

Flere av ferdighetene for adversarial planlegging vi testet, falt i denne kategorien. Feilmønsteret var konsekvent: kritikkfasen havnet i en løkke, eller «ekspertpersonaene» motsa hverandre, noe som førte til et forvirret og feilaktig sluttresultat. I én test gikk en ferdighet rettet mot SQL-spørringsoptimalisering inn i en kritikkløkke der den debatterte fordelene med JOIN vs. INNER JOIN (som er funksjonelt identiske i de fleste dialekter) og klarte ikke å produsere noen spørring i det hele tatt.

Dette er anti-hype-realiteten i økosystemet for KI-ferdigheter. Popularitet og GitHub-stjerner korrelerer ikke med ytelse. Et smart prompt-mønster kan like gjerne skade som å hjelpe. Den eneste måten å vite det på, er å teste det.

Så, er mønsteret verdt det?

La oss gå tilbake til det opprinnelige spørsmålet. Er mønsteret fra den Karpathy-inspirerte CLAUDE.md verdt det?

Som et læringsverktøy, absolutt. Å lese gjennom Changs CLAUDE.md og lignende prompter er en utmerket måte å forstå konseptet «chain-of-thought» og selvkorreksjon på. Å eksperimentere med det manuelt kan hjelpe deg med å utvikle bedre intuisjon for prompting.

Som et produksjonsverktøy i form av en installert SKILL.md, er svaret et bestemt «det kommer an på». Våre data viser at for spesifikke, høyst komplekse oppgaver kan en velimplementert «adversarial»-ferdighet være et kraftig verktøy for senioringeniører. Den kan fungere som en utrettelig, logisk sparringpartner for komplekse problemer. For daglig koding er den sannsynligvis treg, kostbar og potensielt motproduktiv.

Dette er nøyaktig det problemet SkillProof ble bygget for å løse. I stedet for å stole på hype eller antall stjerner, kan du stole på våre data. Vi skiller ferdighetene som gir et reelt, målbart løft fra de som bare er smarte, men ineffektive prompter.

Relatert lesing: andelen ferdigheter som faktisk slår ren Claude · hvordan vi kjører hver ferdighet før vi lister den.

Vi har testet dusinvis av ferdigheter som bruker adversarial planlegging og andre avanserte teknikker. For å se hvilke som besto våre reelle tester og fikk en SkillProof-score, kan du bla gjennom Produktivitet og arbeidsflyt-kategorien i katalogen vår. Vi pakker også de best presterende ferdighetene på tvers av alle kategorier i en startpakke for $10, som gir deg et sett med verifiserte verktøy som faktisk fungerer.