Den komplette guiden til Karpathys LLM-wiki-arbeidsflyt

Fem dager etter at Andrej Karpathy la ut innlegget om sin "LLM-wiki"-arbeidsflyt, hadde internett allerede produsert mer enn femten fungerende implementasjoner, en casestudie fra en dagbok med 2 500 oppføringer, og en pågående diskusjon om hvorvidt alt dette bare er RAG med ekstra steg. Tweeten ligger på seksten millioner visninger. Oppfølgings-gisten har passert fem tusen stjerner og 1 483 forks. Folk leser ikke dette som en kommentar — de leser det som en instruks.

Denne guiden er for lesere i den andre leiren. Den går gjennom hva Karpathy faktisk bygde, de eksakte verktøyene han nevnte, katalogstrukturen som holder hele greia sammen, community-implementasjonene som drar ideen i nyttige retninger, og stedene der den stille faller fra hverandre. Den forutsetter at du vil bygge en selv.

Hva Karpathy faktisk bygde

Den 2. april 2026 publiserte Karpathy et kort innlegg på X og en lengre gist som beskrev en personlig kunnskapsarbeidsflyt. Innrammingen betydde like mye som innholdet. Han skrev at "en stor del av min nylige token-gjennomstrømning går mindre til å manipulere kode, og mer til å manipulere kunnskap" — en bemerkelsesverdig innrømmelse fra noen hvis offentlige identitet er bygget på å skrive noe av den mest leste deep learning-koden det siste tiåret.

Kjernebeskrivelsen, fra gisten, er én setning det er verdt å sitere eksakt:

"I index source documents into a raw/ directory, then I use an LLM to incrementally 'compile' a wiki, which is just a collection of .md files in a directory structure."

Det er hele mekanismen. Råe inndata havner i én mappe. En LLM leser dem og sender ut lenkede markdown-filer til en annen mappe. LLM-en er ansvarlig for kryssreferanser, indeks, overskrifter, formatering, og — kritisk — for å gå tilbake og oppdatere tidligere sider når ny informasjon kommer inn. Mennesket opererer wikien via Obsidian, ikke via et eget grensesnitt.

Karpathy rammet det inn som et "vibe-kodet" personlig system, ikke et produkt. Den innrammingen er en del av grunnen til at det spredte seg: det var åpenbart reproduserbart for alle med en terminal og en LLM-nøkkel. Innen 48 timer forket folk gisten og pushet fungerende repoer. Innen fem dager hadde økosystemet nok variasjon til å snakke om best practices.

De eksakte verktøyene Karpathy bruker

Karpathy var spesifikk om stacken sin. Det er verdt å liste delene i sin helhet, fordi mye av den sekundære kommentaren har vært slurvete her.

• Obsidian — frontend og IDE. Karpathy blar, spør og redigerer wikien gjennom Obsidians markdown-native grensesnitt. Han bygde ikke et eget UI. Dette er en bevisst separasjon: AI-en skriver filene, Obsidian leser dem.
• Obsidian Web Clipper — inntaksveien for nettartikler. Den konverterer sider til ren markdown som lander i raw/ uten manuell copy-paste.
• Et eget, vibe-kodet CLI/websøkeverktøy — Karpathy nevner et lite søkelag han skrev selv for å finne kildedokumenter. Han slapp det aldri. Det er en særegen bit som de fleste reimplementasjoner erstatter med ripgrep eller et tredjepartssøk.
• qmd av Tobi Lütke — Shopifys CEO skipet et hybrid BM25 + vector search-verktøy som Karpathy løftet fram som skaleringsveien når en wiki vokser ut av én enkelt indeksfil. qmd er svaret på "hva gjør jeg når index.md ikke lenger får plass i konteksten."
• Marp — markdown til slides. Karpathy bruker wikien sin som sannhetskilde for foredrag. En slide deck er bare en annen kompilert utdata fra samme innhold.
• Dataview — et Obsidian-plugin for å spørre mot frontmatter. Hvis hver side har et confidence: 0.7- eller stale: true-felt, gjør Dataview vaultet om til en spørrbar database uten å forlate markdown.
• matplotlib — Karpathy lar LLM-en generere Python-plotter fra strukturert data i wikien og rendre dem som bilder ved siden av prosaen. Diagrammer er kompilert, ikke håndtegnet.
• Git — versjonskontroll for både raw/ og wiki/. Hver LLM-redigering blir en commit, noe som betyr at du kan diffe hva modellen gjorde og rulle tilbake når den hallusinerer.

Han navnga ingen spesifikk LLM. Men skjemafilen i gisten heter CLAUDE.md, som er konvensjonen brukt av Claude Code. Communityet har tatt det som et sterkt hint om at den primære driveren er Claude Code som opererer på en lokal katalog.

Arkitekturen: raw/ vs wiki/

Katalogoppsettet er den bærende ideen. Nesten hver feil i de tidlige reimplementasjonene sporer tilbake til at man utvisket skillet mellom de to mappene.

knowledge/
├── raw/           # immutable source documents (never edited by LLM)
│   ├── articles/
│   ├── papers/
│   ├── notes/
│   └── transcripts/
├── wiki/          # LLM-owned markdown (rewritten on every ingest)
│   ├── index.md
│   ├── people/
│   ├── concepts/
│   └── projects/
└── CLAUDE.md      # schema, conventions, instructions for the agent

raw/ er uforanderlig. Du slipper inn filer, LLM-en leser dem, ingenting skriver tilbake. Hvis du redigerer en rå fil, redigerer du kildene dine, og wikien blir en løgn. Behandle den som et read-only arkiv. De fleste implementasjoner håndhever dette med en git pre-commit-hook eller en enkel chmod.

wiki/ eies av LLM-en. Du redigerer ikke wiki-sider for hånd. Gjør du det, vil neste inntak stille overskrive endringene dine. Vil du rette noe, fikser du enten det underliggende rådokumentet eller legger til en instruksjon i CLAUDE.md. Dette føles strengt, og det er det, men det er den eneste måten "selvvedlikeholdende"-egenskapen holder.

CLAUDE.md (eller AGENTS.md) er skjemafilen. Den forteller agenten hvilke konvensjoner som gjelder: hvordan filer navngis, hvilke frontmatter-felt som kreves, hvilken stil prosaen skal være i, hvordan motsigelser håndteres, når man oppretter en ny side kontra oppdaterer en eksisterende. Denne filen er det nærmeste arbeidsflyten kommer et konfigurasjonslag.

Tre operasjoner kjøres mot denne strukturen:

1. Inntak — en ny fil lander i raw/. Agenten leser den, identifiserer hvilke eksisterende wiki-sider den berører, og oppdaterer omtrent ti til femten sider i ett pass: den nye emnesiden, indeksen, kryssrefererte konsepter, relevante personsider. Dette er den dyre operasjonen. Det er her "kompileringen" skjer.
2. Spørring — du stiller et spørsmål. Agenten leser wiki/index.md, bestemmer hvilke sider som er relevante, åpner disse sidene og syntetiserer et svar. Kritisk er at den spør mot den kompilerte wikien, ikke mot råarkivet. Kompileringsarbeidet lønner seg her.
3. Lint — kjøres på plan eller ved behov. Agenten går gjennom wikien på leting etter motsigelser ("side A sier X, side B sier ikke-X"), foreldreløse sider (ingen lenker til dem), og utdaterte påstander (hvis kilde i raw/ er erstattet). Dette er operasjonen som forhindrer forfall.

Hva folk faktisk bygger

Innen fem dager etter originalinnlegget hadde GitHub mer enn femten reimplementasjoner. En håndfull er substansielle nok til å lære av.

Ar9av/obsidian-wiki behandler agentlaget som pluggbart. Samme wiki kan drives av Claude Code, Codex, Cursor, Windsurf, Copilot eller Gemini, byttet via en skills-basert arkitektur som pakker hver leverandør. Det er nyttig hvis du vil unngå å satse hele oppsettet på én leverandørs priskurve.

nvk/llm-wiki kommer fra NVK, en veteran Bitcoin-utvikler, og er den mest holdningsstreke implementasjonen så langt. Den introduserer tre nivåer av spørredybde (fast, deep, exhaustive), eksplisitt confidence-skår på hvert påstand, og dual-linking — hver wiki-side lenker både til de rå kildene den ble bygd fra og til andre wiki-sider den relaterer seg til. Dual-linkingen er ideen verdt å stjele.

ussumant/llm-wiki-compiler publiserte den eneste virkelige benchmarken så langt. Testet på et korpus med 383 markdown-filer (13,1 MB) rapporterer den omtrent 84 % færre tokens per spørresesjon sammenlignet med å laste rå-filene direkte — rundt 3 200 linjer med kontekst per sesjon som faller til rundt 330. Dette er det empiriske resultatet ingen har løftet fram tydelig, og det er det sterkeste kvantitative argumentet for hele tilnærmingen.

kenhuangus/llm-wiki kjører hele pipelinen på lokale modeller — LM Studio som serverer Gemma 4 — og legger til automatisert overvåking av arXiv- og CVE-feeder som kontinuerlige inntakskilder. Ingen sky, ingen API-regninger, og wikien oppdaterer seg selv over natten mens maskinen står stille.

iamsashank09/llm-wiki-kit reimplementerer hele greia som en MCP-server. I stedet for å kjøre agenten som et CLI eksponerer den inntak/spørring/lint som MCP-verktøy som Cursor eller Claude Code kan kalle direkte. Det er trolig dit økosystemet er på vei.

swarajbachu/cachezero var den første Show HN-lanseringen i området og solgte seg inn som "Karpathys LLM wiki-idé som én NPM-install." Det er den minst friksjonstunge måten å prøve mønsteret på hvis du vil få et fungerende vault i gang på under ti minutter.

Farzapedia-casestudien

Det mest slående eksempelet fra en utøver er fra Farza Majeed (@FarzaTV). Farza matet omtrent 2 500 oppføringer fra sin personlige dagbok, Apple Notes og iMessage-samtaler inn i en Karpathy-stil-pipeline og kalte resultatet "Farzapedia". Utdataen ble rundt 400 sammenlenkede wiki-artikler som dekket venner, tidligere startups, forskningsinteresser og — fordi dette er Farza — flere anime-dypdykk.

Det som gjør Farzapedia interessant er kildematerialet. Det er ikke et forskningskorpus. Det er den uordnede omkringliggende dataen fra et liv: tekster, slengte notater, daterte dagbokoppføringer. Kompileringssteget trakk alt inn i noe navigerbart. Karpathy selv retweetet det og kalte den resulterende minneartefakten "eksplisitt og navigerbar" — en nøye frase. Poenget er ikke at wikien vet mer enn Farzas notater gjorde. Det er at wikien kan vandres.

Det er så langt det mest overbevisende eksistensbeviset på at mønsteret generaliserer utover Karpathys egen forskningsarbeidsflyt.

Best practices som dukket opp på dager

Til tross for den korte tidslinjen har en grov konsensus formet seg om hva som fungerer.

YAML-frontmatter med confidence og staleness. Hver wiki-side får en header som:

---
title: "Pipeline v2 architecture"
confidence: 0.8
last_ingested: 2026-04-06
sources: [raw/notes/2026-03-22-sync.md, raw/articles/pipeline-blog.md]
content_hash: 8f3a...
stale: false
---

Dataview-spørringer løfter så fram sider med lav confidence, utdaterte sider eller foreldreløse direkte i Obsidian.

Streng separasjon mellom raw/ og wiki/. Allerede dekket ovenfor, men det er den praksisen som oftest brytes i tidlige forks, og den med verste feilmodus.

Steph Angos vault-separasjonsmønster. Steph Ango (@Kepano), Obsidians CEO, skrev i løpet av uken at agenter bør "make a mess in their own space" heller enn å redigere menneskets personlige vault. Anbefalingen hans er å holde dine håndskrevne Obsidian-notater i ett vault og peke LLM-wikien mot et separat, offervault. Det forhindrer det han kaller hallusinasjonskontaminering — situasjonen der en modell finner på et faktum, skriver det inn i de betrodde notatene dine, og så leser det tilbake neste uke som om det var sannhet. Når en hallusinerte lenke først er i grafen din, blir den forsterket ved hver etterfølgende inntak.

Content hash-deteksjon. Hash hver rå fil ved inntak. Hvis hashen endres, flagg hver wiki-side som siterte den som utdatert. Det er det billigste mulige lint-steget og fanger det meste av forfallet.

qmd for å skalere søk. Single-index-file-mønsteret fungerer opp til omtrent 100–150 artikler. Utover det blir index.md selv større enn et komfortabelt kontekstvindu, og agenten begynner å slite. Tobi Lütkes qmd gir deg et hybrid BM25/vector retrieval-lag som agenten kan kalle som et verktøy, slik at indeksen blir et API-kall i stedet for en fil-lesing. Det er den eneste rene skaleringsveien noen har publisert.

Skjemafiler som konvensjoner. CLAUDE.md og AGENTS.md konvergerer som de to filnavnene agenter ser etter. Legg stilveilederen din, dine obligatoriske frontmatter-felt, dine krysslenke-regler og dine disambigueringsregler i en av disse filene. Alt annet følger.

Hvor det svikter

Dette er den delen av arbeidsflyten det meste av entusiastdekningen hopper over. Mønsteret er bra. Det er ikke ferdig.

Indeksen vokser ut av kontekstvinduet. Forbi noen hundre artikler blir wiki/index.md uhåndterlig. Du kan komprimere, sharde eller bytte til qmd, men ingenting av dette er gratis. Hver skaleringsløsning introduserer retrieval, og retrieval er tingen mønsteret skulle erstatte. Ved en viss korpusstørrelse blir arbeidsflyten stille til RAG-over-kompilert-markdown, som er forsvarbart, men verdt å innrømme.

Sitatpresisjon er svak. Wikien kan si "denne beslutningen ble tatt 22. mars" og sitere raw/notes/2026-03-22-sync.md, men den kan ikke enkelt sitere "side 47, avsnitt 3". For forskningsarbeid der proveniens betyr noe, er dette et hull. Eneste workaround så langt er å forhåndsbehandle rå-filer til små nok biter til at filnavnet er presist nok — som, igjen, begynner å ligne på chunking.

Hallusinasjonskontaminering er reell. Hvis LLM-en finner på en lenke ved inntak, vedvarer den lenken. Ved neste inntak vil modellen lese sin egen oppdiktning som kildemateriale og forsterke den. Steph Angos separat-vault-mønster demper dette; lint-steg fanger noe av det; men ingen har en prinsipiell løsning. Wikien kan drive bort fra råarkivet og det finnes ingen automatisk alarm.

Token-kostnader i skala er upubliserte. Ingen som kjører en wiki i produksjon har lagt ut ekte tall. Inntaksoperasjonen berører ti til femten sider per nytt dokument, hver full-lesing-og-omskriving. Til Claude Sonnet-priser kunne en travel kunnskapsarbeider brenne meningsfulle penger per måned, men vi vet ikke ennå om det er ti dollar eller to hundre. Ussumant-benchmarken handler om besparelser ved spørretid, ikke kostnader ved inntak.

"Dette er bare RAG"-debatten. En betydelig del av den tekniske kommentaren er en eller annen variant av "kompiler markdown og spør mot det er bokstavelig talt retrieval-augmented generation". Skillet verdt å bevare er at kompilering er lossy og holdningsbasert — LLM-en tar redaksjonelle beslutninger ved inntak som klassisk RAG utsetter til spørretid. Om det teller som et nytt paradigme eller en omplassering av samme arbeid er en definisjonskrangel, og den blir ikke avgjort av en tweet.

Møtetranskripsjons-muligheten

Karpathy listet flere kildetyper i gisten. Én linje er verdt å sitere i sin helhet fordi den peker på hullet ingen har fylt:

"Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. The wiki stays current because the LLM does the maintenance that no one on the team wants to do."

Den setningen inneholder den uuttalte tesen for hvert møte-AI-verktøy på markedet. Møtetranskripsjoner er det høyeste-utbytte-inputtet for en Karpathy-stil-wiki: de genereres automatisk, de er relasjonelle, de sammenligner seg, og ingen vil vedlikeholde dem for hånd. De er akkurat den typen dokument som nyter godt av kompilering heller enn lagring.

Og likevel, per denne uken, finnes ingen produkt som automatisk mater møtesamtaler inn i en akkumulerende Karpathy-stil-wiki. De nærmeste nærstående verktøyene stopper ved sammendrag per møte. Gapet mellom "her er et sammendrag av dagens samtale" og "her er en vedlikeholdt wiki-side for Q3-prisbeslutningen, oppdatert over de syv møtene der den kom opp" er stort, og det er fortsatt stort sett tomt.

Proudfrog tenker på dette problemet, og den tidligere teksten om Karpathys wiki og møtekunnskap går dypere inn i de arkitektoniske implikasjonene. For det bredere argumentet om hvordan en kompilert møtekunnskaps-graf ser ut i daglig bruk, se knowledge worker-arbeidsflyten, funksjonssiden eller pricing.

Kortversjonen: Karpathy viste hvordan destinasjonen ser ut. Det interessante arbeidet nå er å legge rørleggingen inn i stedene der råmaterialet allerede produseres.

---

Ofte stilte spørsmål

Hvilken LLM bruker Karpathy til wikien sin?

Karpathy navnga ingen modell eksplisitt i originalinnlegget eller gisten. Skjemafilen i den publiserte katalogstrukturen hans heter imidlertid CLAUDE.md, som er konvensjonen brukt av Anthropics Claude Code. Community-konsensusen er at den primære driveren er Claude Code som kjører mot en lokal katalog, selv om implementasjoner har blitt publisert med GPT-basert Codex, Gemini, Cursor og lokale modeller via LM Studio. Arbeidsflyten er modellagnostisk — det som betyr noe er at agenten kan lese og skrive filer i en katalog.

Må jeg være utvikler for å bygge min egen LLM-wiki?

Du må være komfortabel med en terminal, git og en LLM-kodeagent som Claude Code eller Cursor. Du trenger ikke å skrive kode fra bunnen av — flere reimplementasjoner (cachezero, llm-wiki-kit, obsidian-wiki) installeres på noen minutter og gir deg et fungerende vault. Det løpende arbeidet er å kuratere skjemafilen, bestemme hva som skal inn i raw/, og gå gjennom det agenten skriver. Tenk på det som å drifte et system heller enn å bygge et.

Hvordan skiller dette seg fra RAG?

Klassisk RAG chunker dokumenter, embedder dem, og henter lignende chunks ved spørretid. Hentingen er likhetsbasert og skjer når du stiller et spørsmål. Karpathys wiki kompilerer rådokumenter til strukturert, lenket markdown ved inntak, og LLM-en tar redaksjonelle beslutninger — hva som betyr noe, hva som lenker til hva, hva som skal oppdateres — før noe spørsmål er stilt. Ved spørretid leser modellen den kompilerte wikien, ikke råarkivet. Forbi noen hundre artikler blir skillet mer utvisket fordi indeksen selv må søkes, men i personlig skala bærer kompileringssteget meningsfull informasjon som ren likhetssøk forkaster.

Hva skjer når wikien blir for stor for kontekstvinduet?

Single-index-file-mønsteret brytes rundt 100–150 artikler, når wiki/index.md slutter å passe komfortabelt i konteksten. Den reneste skaleringsveien publisert så langt er qmd av Tobi Lütke, et hybrid BM25- og vector search-verktøy som agenten kaller som et retrieval-steg. Utover det begynner du å sharde wikien etter tema eller tidsperiode. Det er den ærlige plassen der mønsteret gjeninnfører retrieval, og det er verdt å planlegge for hvis korpuset ditt vokser.

Kan jeg bruke dette med mine møtetranskripsjoner?

I prinsippet ja — slipp transkripsjoner i raw/transcripts/ og la agenten kompilere dem. I praksis er møtetranskripsjoner støyende, taler-attribuerte og tidsstemplede, og en generisk wiki-agent vet ikke hvordan den skal vekte beslutninger, trekke ut action items eller avduplisere gjentakende diskusjoner. Det er hullet Proudfrog jobber på. For en dypere behandling av hvordan en møte-native kompilert wiki ville sett ut, se Karpathys LLM-wiki og hva det betyr for møtekunnskap.

Hva er forskjellen mellom raw/ og wiki/?

raw/ holder kildedokumentene dine — artikler, papers, notater, transkripsjoner — og er uforanderlig. LLM-en leser fra den, men skriver aldri tilbake. wiki/ holder kompilert markdown som LLM-en eier helt: den oppretter, oppdaterer og omstrukturerer sider etter hvert som nye kilder kommer inn. Du håndredigerer ikke wiki/-filer, fordi neste inntak vil overskrive dem. Trenger du å rette noe, fikser du den underliggende kilden i raw/ eller oppdaterer reglene i CLAUDE.md. Å holde de to mappene strengt adskilt er den enkeltvis viktigste konvensjonen i arbeidsflyten, og det er den som oftest brytes i tidlige forks.