Part II: LLM Wiki — 외장 지식 엔진

Chapter 4: Karpathy의 LLM Wiki 패턴 — 16M view 회고

집필일: 2026-05-22 최종수정일: 2026-05-22

4.1 2026년 4월 4일, gist 한 장

2026년 4월 4일, Andrej Karpathy는 GitHub Gist 한 장을 공개했다 [3]. 제목은 "LLM Wiki." 본문은 제품 발표가 아니라 패턴 설명이었다. raw source를 한 디렉토리에 보존하고, LLM agent가 그 자료를 읽어 마크다운 위키를 작성·유지하며, 그 위키를 다시 질문·정리·보강의 기준으로 삼는다. gist 하단은 "copy-paste this idea file into your favorite LLM agent, e.g. Codex, Claude Code, OpenCode, Pi"로 시작한다. 패턴 자체는 누구나 베껴 쓸 수 있도록 idea file 형태로 박혀 있다 [10].

발표 트윗은 16M+ 뷰를 기록했다 [3]. gist는 2026년 5월 초 기준 19k+ stars / 4k+ forks를 넘었고, 발표 후 30일 안에 6개 이상의 OSS 구현이 등장했다 [3]. 같은 한 달 사이 MindStudio, Cognition, Denser, Analytics Vidhya, Agentpedia, Lobster Pack, WebEdge가 해설 글을 냈고 [5], Starmorph의 "Full Beginner Setup Guide" 영상은 setup-guide 계열의 캐논으로 자리잡았으며 [12], 한국어권에서는 GeekNews가 "BYOAI / files-over-apps" 어휘를 빠르게 정착시켰다 [13]. (Chapter 5)에서 다루는 OSS·콘텐츠 매트릭스는 모두 이 한 달 반의 산물이다.

왜 1page짜리 gist가 그 정도 반응을 끌어냈는가? 그 질문이 이 챕터의 출발점이다. 정답은 "이 패턴이 30년 묵은 외장 두뇌 전통 위에 LLM agent를 얹은 마지막 한 줄"이었기 때문이다.

4.2 비유: Obsidian as IDE, LLM as programmer, wiki as codebase

Figure 4.1: Karpathy의 LLM Wiki 패턴 — raw/, wiki/, agents/ 세 레이어 markdown 트리와 LLM 에이전트의 read/write 관계 — illustration by author (gpt-image assisted)
Figure 4.1: Karpathy의 LLM Wiki 패턴 — raw/, wiki/, agents/ 세 레이어 markdown 트리와 LLM 에이전트의 read/write 관계 — illustration by author (gpt-image assisted)

Karpathy의 트윗 한 줄이 이 패턴을 가장 압축적으로 설명한다 [3]. "Obsidian이 IDE, LLM이 프로그래머, wiki는 codebase다." 비유를 풀어 쓰면 이렇다.

  • codebase = wiki/. 사람의 머릿속이 아니라 디스크 위에 사는 산출물. 읽을 수 있고, diff를 볼 수 있고, git으로 되돌릴 수 있다. 다른 사람과 공유 가능하고, 다른 모델에 옮겨도 동일하게 작동한다.
  • programmer = LLM. 이 codebase를 작성하고 리팩토링하고 lint하는 주체는 사람이 아니라 LLM agent다. 사람은 PR 리뷰어처럼 diff를 보고 승인·반려·수정 지시를 내린다.
  • IDE = Obsidian (또는 Cursor, VS Code + Claude Code, Codex). wiki를 사람이 읽고 자기 사고로 끌어올 때 쓰는 표면. Karpathy 본인은 Obsidian을 명시했지만, 본질은 IDE 자체가 아니라 "markdown 파일이 사람·LLM 모두에게 동시에 1급 시민"이라는 점이다.

이 비유의 함의는 작지 않다. "지식관리 시스템"이라는 단어가 일반적으로 떠올리게 만드는 데이터베이스·태그 트리·정교한 그래프 뷰는 모두 옆으로 밀린다. 핵심은 IDE에서 코드를 다루듯 LLM agent에게 markdown vault를 다루게 시키는 것이다. 코드 리뷰의 디시플린(diff, lint, 컨벤션, 테스트)이 그대로 wiki 관리의 디시플린이 된다. 이것이 (Chapter 6)에서 제안하는 연구용 schema가 임의의 prescription이 아니라 코드베이스 hygiene의 직접 차용임을 미리 정당화한다.

4.3 3-레이어 구조

Karpathy의 gist는 vault를 세 레이어로 자른다 [3]. (Chapter 10) claude-to-codex Part IV에서 이미 한 번 다뤘지만, Part II는 이를 연구용 외장 두뇌의 기준 단위로 다시 세운다.

L1 — raw/ : 불변 source-of-truth


vault/
└── raw/
    ├── papers/          # PDF, arXiv 원문
    ├── articles/        # 블로그, 뉴스, Substack
    ├── notes/           # 회의 메모, 일지, 손글씨 스캔
    ├── bookmarks/       # 북마크, 트윗 스크랩
    └── transcripts/     # 영상·팟캐스트 트랜스크립트

agent는 이 레이어를 읽기만 한다. 쓰지 않는다. 원본 불변성은 모든 후속 추론의 닻이 된다. Agentpedia가 "이 raw-immutability 규칙이야말로 wiki rot을 막는 가장 결정적 한 줄"이라고 단언하는 이유다 [9].

L2 — wiki/ : LLM이 작성하는 markdown 합성


vault/
└── wiki/
    ├── entities/        # 사람, 프로젝트, 회사, 모델
    ├── concepts/        # 기술 개념, 정의
    ├── summaries/       # 논문·글 요약
    ├── comparisons/     # 비교·대조 페이지
    ├── claims/          # 명시적 주장 + 근거
    ├── contradictions/  # 모순 페이지
    └── open-questions/  # 미해결 질문

agent는 L1을 읽고 이 레이어를 작성·갱신한다. 사람이 직접 손대도 되지만, 대부분의 편집은 agent가 한다. 사람은 git diff로 검토한다.

L3 — schema/ : CLAUDE.md, AGENTS.md

agent에게 vault 구조와 운영 규칙을 알려주는 instruction file. "wiki/entities/에는 인물 페이지가 있다. raw/는 절대 수정하지 않는다. 모든 claim에는 source ID가 붙어야 한다" 같은 규칙이 산다. Claude Code는 CLAUDE.md를, Codex는 AGENTS.md를 본다 [14]. 같은 파일 두 이름이 사실상 cross-vendor 컨벤션이 되어 가는 흐름은 (Chapter 6)에서 다시 다룬다.

세 가지 기본 연산이 이 vault 위에서 돈다:

  • ingest: raw 추가 → wiki 페이지 생성/갱신
  • query: 질문 → wiki 탐색 → 답변 + 인용
  • lint: 깨진 링크, 중복, 모순, 출처 없는 claim 정리

ingest와 lint가 query보다 먼저 온다는 점이 RAG와의 결정적 차이다. RAG는 query-time에 모든 일을 하지만, LLM Wiki는 ingest-time과 maintenance-time에 미리 합성을 끝낸다.

4.4 CLAUDE.md / AGENTS.md — instruction file이 왜 중요한가

WebEdge의 분석은 이 점에서 특히 유용하다 [11]. CLAUDE.md는 단순한 README가 아니다. agent의 "운영 계약"이다. 6개의 절이 거의 모든 검토된 구현에서 공통적으로 등장한다.

  1. Ingest rules: 새 raw가 들어왔을 때 어떤 wiki 페이지를 만들고 어떻게 기존 페이지와 머지하는가.
  2. Citation rules: claim에는 반드시 raw/ 내 source ID를 붙인다. 출처 없는 claim은 저장 거부.
  3. Contradiction-flagging rules: 새 raw가 기존 claim과 충돌하면 contradictions/ 페이지에 양쪽을 기록한다.
  4. Link conventions: wikilink 형식, 중복 wikilink 방지, 깨진 링크의 lint 규칙.
  5. Lint commands: 주기적으로 돌릴 lint 명령. 어떤 위반을 어떻게 다룰지.
  6. Tool boundaries: 외부 호출(웹 검색, 데이터베이스, 실험 도구) 사용 시점과 권한.

Agent skills, hooks, subagents, MCP는 모두 이 운영 계약의 부속물이다. 본 책 (Chapter 10)에서 7가지 hook 규칙을 도구화하는 흐름의 출발점이 바로 여기다. 한 가지 강조할 점은 instruction file이 단지 명령어 모음이 아니라 읽힘이 되는 산문이라는 것이다. Karpathy의 표현을 빌리면 "사람이 읽고 납득할 수 있어야 LLM도 따른다."

Lobster Pack의 "idea file" 프레이밍은 이 지점에서 결정적이다 [10]. Karpathy가 공유한 것은 코드가 아니라 idea file 자체였다. 이 파일은 Codex, Claude Code, OpenCode, Cursor, Pi 어디에 붙여도 작동한다. 즉 코드의 시대는 "instruction이 호스트에 종속"이었지만, agent의 시대는 "instruction이 host-agnostic markdown"이다. 이 작은 형식 전환이 30일 안에 6+개의 OSS 구현이 등장할 수 있었던 인프라적 조건이다.

4.5 index.md, log.md, schema.md — 장기 운영의 중심

vault가 한 달 이상 살아남으려면 세 개의 메타 파일이 필요하다. MindStudio, Starmorph, Fulkerson은 거의 같은 결론으로 수렴한다 [5].

  • index.md: vault의 sitemap. 모든 wiki 페이지로의 진입점. agent가 query를 시작할 때 가장 먼저 읽는다. lint가 깨진 링크와 고아 페이지를 잡아내는 기준선.
  • log.md: ingest·query·lint의 기계 가독 이력. "언제, 무엇을, 어떤 raw로부터, 어떤 페이지에 반영했는가." Fulkerson은 이걸 production observability의 최소 단위로 다룬다 [16].
  • schema.md: wiki 페이지 자체의 schema. claim 페이지의 필수 필드, entity 페이지의 필수 필드, contradiction 페이지의 필수 필드 등. (Chapter 6)에서 연구용으로 확장한다.

이 세 파일은 단순한 organizational hygiene 이상의 역할을 한다. agent가 wiki를 "기억해야 할 한 덩어리"가 아니라 "구조 있는 파일 시스템"으로 다루도록 강제한다. Aimaker의 4개월 longitudinal report는 log.md를 빼먹은 vault가 "스스로를 반복하기 시작한다"고 보고했다 [17]. n=1이지만 이 신호는 (Chapter 6)의 wiki-rot 논의와 직접 연결된다.

4.6 RAG vs LLM Wiki — 합성을 언제 할 것인가

가장 잦은 오해는 "이게 RAG와 뭐가 다르냐"는 것이다. Hacker News 첫날 thread의 세 대립 진영 중 가장 큰 진영이 정확히 이 질문을 던졌고 [18], Denser는 RAG 벤더 입장에서 같은 질문에 honest answer를 시도했다 [7]. 정리하면 다음과 같다.

항목 기존 RAG (Lewis 2020 + Karpukhin 2020 + Johnson 2019 substrate) Atlas (Izacard 2022) LLM Wiki (Karpathy 2026)
기억 단위 vector DB의 chunk jointly-trained retriever + generator 사람이 읽는 markdown 페이지
합성 시점 query-time query-time (학습된 보강) ingest-time + maintenance-time
지식 축적 약함. 매 질문 재해석 약함. 가중치에 흡수 강함. concept/claim/contradiction이 누적
투명성 낮음. chunk 숨김 낮음. 가중치 안 높음. file·git·diff
도구 의존성 검색 인프라 학습 파이프라인 markdown + git
적합 시나리오 일회성 Q&A knowledge-intensive QA 장기 연구, 가설 관리, 문헌 추적
주요 실패 모드 검색 누락, chunk 오염 가중치 stale, 갱신 비용 wiki rot, synthesis 오류, 출처 손실

핵심은 합성을 언제 할 것인가이다. RAG는 "질문 올 때 합성"하고, Atlas는 "학습 때 합성"하며, LLM Wiki는 "ingest와 maintenance 때 미리 합성"한다 [19].

Denser의 결정적 통찰은 cost/quality trade-off다 [7]. ingest-time 합성은 앞단에서 더 비싸지만, 같은 코퍼스를 반복 질의할 때 query-time이 더 싸고 정확하다. 연구자는 같은 논문군을 수십 번 다시 본다. RAG가 매번 같은 chunk를 같은 LLM에게 같은 방식으로 재해석하는 것은 낭비다. LLM Wiki는 그 합성을 디스크에 "한 번 저장된 결과"로 남긴다.

반대로 일회성 Q&A에는 LLM Wiki가 과잉이다. Denser 본인이 RAG 벤더 입장에서 "두 패턴은 경쟁이 아니라 보완"이라고 정리하는 이유다. 이 책은 그 정리를 수용한다. LLM Wiki는 RAG의 대체가 아니라, 연구용 코퍼스에 RAG가 풀지 못하는 차원의 합성을 더하는 컴파일러다.

MindStudio가 자사 사례로 보고한 "383개 파일 + 100개 회의 트랜스크립트 → 토큰 95% 절감" 수치는 흥미롭지만 독립 검증이 없는 벤더 보고임을 짚어둔다 [5]. 핵심 주장(반복 질의에서 wiki가 더 싸다)은 정성적으로 옳지만, 정량적 95%는 코퍼스·질의 분포·비교 베이스라인에 강하게 의존한다. (Chapter 5)의 G2에서 다시 다룬다.

4.7 PKM의 30년 — Bush → Luhmann → Ahrens → Karpathy

Figure 4.2: PKM의 직계 계보 — Bush 1945 Memex → Luhmann 1950s Zettelkasten → Clark and Chalmers 1998 Extended Mind → Ahrens 2017 Smart Notes → Karpathy 2026 LLM Wiki — illustration by author (gpt-image assisted)
Figure 4.2: PKM의 직계 계보 — Bush 1945 Memex → Luhmann 1950s Zettelkasten → Clark and Chalmers 1998 Extended Mind → Ahrens 2017 Smart Notes → Karpathy 2026 LLM Wiki — illustration by author (gpt-image assisted)

Karpathy의 gist가 16M 뷰를 얻은 이유 중 일부는 그것이 신선해 보였기 때문이고, 또 일부는 그것이 30년 묵은 전통의 마지막 한 줄이었기 때문이다. 두 번째 부분이 본 챕터의 결론 절이다.

1945 — Vannevar Bush, Memex [23]. Atlantic 7월호 "As We May Think." Bush는 OSRD 디렉터로서 위계적 인덱싱이 인간 사고와 맞지 않는다고 진단하고, 마이크로필름과 책상으로 "associative trails"를 따라 문서를 엮는 가상 장치 Memex를 제안한다. 모든 후속 PKM 개념의 뿌리다. Engelbart NLS, Nelson Xanadu, World Wide Web, Wikipedia, Roam, Obsidian이 다 여기서 갈라진다. 2026년 LLM Wiki는 이 80년 묵은 제안에 "associative trail을 LLM agent가 자동으로 유지한다"는 한 줄을 더한 것이다.

1992 — Niklas Luhmann, Zettelkasten [24]. 약 9만 장의 손번호 카드를 ID로 링크한 슬립박스를 "communication partner"로 다룬 에세이. atomic note + dense link라는 두 디시플린이 여기서 코드화된다. Luhmann은 슬립박스가 자기도 모르는 연결을 만들어 그를 놀라게 한다고 썼다. LLM Wiki에서 agent가 contradictions/ 페이지를 만들어 사용자에게 보여주는 순간은 이 "놀라게 하는 second mind"의 디지털 재현이다.

1998 — Andy Clark & David Chalmers, The Extended Mind [25]. parity principle: 외부 자원이 인지 과정의 기능적 역할을 신뢰성 있게 수행하면 그것은 마음의 일부다. Otto의 노트가 Inga의 생물학적 기억과 동등한 epistemic 지위를 갖는다는 사고실험. LLM Wiki를 "도구"가 아니라 "연구자 인지의 외장 피질"로 보는 본 책의 입장은 이 1998년 논증에 직접 기댄다. 28년 묵은 철학 논증이 2026년 markdown vault의 윤리적·인식론적 정당성을 떠받친다.

2017 — Sönke Ahrens, How to Take Smart Notes [26]. Luhmann을 현대 연구 워크플로우(fleeting → literature → permanent notes)로 코드화. permanent note는 미래의 자기 또는 임의의 독자가 맥락 없이 읽어도 작동해야 한다는 디시플린. 이것이 LLM Wiki의 atomic-note 디자인 제약과 직접 이어진다. Astro-Han, ekadetov는 atomic-note 디시플린을 명시적으로 설계 제약으로 인용한다 [36].

2017 — Andrej Karpathy, Software 2.0 [4]. neural net을 새 프로그래밍 substrate로 다룬 에세이. 가중치라는 산출물도 코드처럼 버전 관리되는 executable knowledge라는 프레임. 2026년 LLM Wiki는 이 프레임을 "weights 대신 markdown 페이지"로 평행 이동한 것이다. 같은 저자가 9년 간격으로 두 substrate를 명명한 셈이다.

2020 — Lewis et al., RAG; Karpukhin et al., DPR; 2019 — Johnson et al., FAISS [19]. 벡터 스토어 기반 검색이 industrial 표준이 되는 시기. LLM Wiki가 "정확히 거부하는" baseline.

2022 — Izacard et al., Atlas [22]. retriever-generator 공동 학습으로 11B로 540B를 이기는 결과. RAG의 가장 강한 baseline. Karpathy의 gist는 Atlas를 폄하하지 않고 "다른 시점의 합성"이라고 위치 짓는다.

2023 — MemGPT (Packer et al.); Voyager (Wang et al.); Generative Agents (Park et al.); Reflexion (Shinn et al.); ReAct (Yao et al.); Toolformer (Schick et al.); CoT (Wei et al.) [27]. 외장 메모리의 LLM 시대 토대. MemGPT는 OS 가상 메모리 비유로 "main context ↔ archival"을 페이지한다. Karpathy의 LLM Wiki는 archival을 vector store가 아니라 사람이 읽는 markdown vault로 일반화한 것이다. Voyager의 skill library는 "wiki accumulates, RAG re-retrieves" 구분의 가장 깔끔한 사전 증명이다. Generative Agents의 memory stream + reflection은 ingest와 lint를 LLM agent가 자체적으로 돌릴 수 있다는 존재 증명이다.

2024 — FutureHouse WikiCrow / PaperQA2 [34]. Karpathy 18개월 전, FutureHouse가 PaperQA2와 WikiCrow로 LLM-maintained wiki를 이미 시연했다. 단 personal use가 아니라 superhuman literature search라는 목표였다. Karpathy의 2026년 기여는 같은 패턴을 "회사 시스템"에서 "personal idea file"로 일반화한 것이다. 이 점은 (Chapter 4)이 Karpathy를 invent가 아니라 integrate로 다루는 G15 frame과 직결된다.

2026 — Karpathy, LLM Wiki gist + Farzapedia 후속 트윗 [3]. 2026-04-12 Farzapedia 답글에서 Karpathy는 LLM Wiki가 desirable한 네 속성을 명시한다: Explicit (감사 가능한 기억 산출물) / Yours (파일 소유, app lock-in 없음) / Files over apps (markdown 내구성) / BYOAI (모델 독립). Farza의 개인 위키 사례는 2,500개 raw input(일기, Apple Notes, iMessage) → 400개 wiki document로 압축된다. GeekNews는 이 네 속성을 한국어권에 정착시키며 "BYOAI / 파일 우선" 어휘를 표준화했다 [13].

이 30년 라인을 한 줄로 줄이면 이렇다. 외장 두뇌 아이디어는 1945년부터 있었다. 2026년에 추가된 것은 "그 외장 두뇌를 자동으로 유지하는 agent"다. Karpathy의 가장 큰 기여는 패턴의 발명이 아니라, 80년 묵은 라인을 1page idea file로 압축해 16M 명에게 동시에 보여준 것이다. 본 책이 (Chapter 1)부터 Karpathy를 origin이 아니라 integrator로 다루는 이유다.

4.8 회의·반대 의견 — 같이 들어두기

Figure 4.3: Wiki rot vs healthy wiki — 방치된 stale 노트가 누적되는 anti-pattern과 capture→review→consolidate→archive 유지 루프의 대비 — illustration by author (gpt-image assisted)
Figure 4.3: Wiki rot vs healthy wiki — 방치된 stale 노트가 누적되는 anti-pattern과 capture→review→consolidate→archive 유지 루프의 대비 — illustration by author (gpt-image assisted)

이 챕터를 triumphal하게 닫지 않기 위해 세 갈래의 회의를 같이 적어둔다.

"이건 그냥 RAG with extra steps다" (HN 첫날 thread, 가장 큰 진영) [18]. 답: query-time vs ingest-time이라는 단어 한 쌍을 빼면 표면적으로 비슷해 보일 수 있다. 그러나 Denser·Cognition·Karpathy 본인의 정리는 일관된다. 같은 코퍼스를 반복 질의하는 연구 환경에서 ingest-time 합성은 cost·품질 양쪽에서 의미가 있다 [6]. 일회성 Q&A에서는 RAG가 적절하다.

"model collapse — 자기 출력으로 학습하는 형태 아닌가" (HN 첫날 thread, gojomo가 가장 명료히 답함) [18]. 답: LLM Wiki는 inference-time organization이지 training-time recursion이 아니다. raw/는 immutable이고 wiki/는 raw/에서 매번 재합성된다. weights는 갱신되지 않는다. 이 구분이 model collapse 우려를 무력화한다.

"10M+ context window가 오면 이 패턴은 obsolete" (HN 첫날 thread). 답: 부분적으로 맞다. context가 커질수록 ingest-time 합성의 절약 이점은 줄어든다. 그러나 (a) git diff·인용·산문 가독성은 context window 크기와 무관하게 사람에게 가치가 있고, (b) 연구자가 자기 머릿속에 wiki가 살아 있어야 하는 use case에서 LLM Wiki는 도구가 아니라 인지의 외장 피질이다 [25]. context 크기와 무관하게 살아남는다.

Zettelkasten 관점의 비판 [38]. Wenhao Yu는 LLM Wiki가 Zettelkasten의 핵심인 "linking-as-thinking"을 단축한다고 지적한다. 위키는 자라는데 사용자의 mental model은 자라지 않는 cognitive offloading 실패 모드. 본 책 (Chapter 11)에서 직접 다룬다. 짧게 답하면: 이 비판은 옳다. atomic-note discipline (Ahrens)을 schema 차원에서 강제하지 않으면 LLM Wiki는 second brain이 아니라 second junk drawer가 된다. (Chapter 6)의 schema는 이 비판을 first-class concern으로 다룬다.

그래프 DB가 빠졌다 [39]. wiki link 그래프는 scale에서 열화한다. citation graph, 실험 lineage, ACL 경계가 핵심인 use case에서는 진짜 graph DB layer가 필요하다는 주장. 본 책은 이 비판을 수용한다. file-only purism은 personal-/team-scale의 디폴트일 뿐, enterprise·연구실 lineage에서는 hybrid가 옳다. OmegaWiki가 9 entity type × 9 edge type의 knowledge graph를 wiki 위에 얹는 흐름이 그 증거다 [35].

Enterprise reality check [40]. RBAC, retention, audit, classification metadata — 어느 것도 Karpathy의 single-user gist에는 없다. enterprise에서 LLM Wiki는 file-level RBAC, immutable edit history, retention policy를 추가해야 한다. (Chapter 6) schema는 이 enterprise 차원을 마지막에 다룬다.

마지막으로 G15 — Karpathy 프레이밍에 대한 self-citation loop 위험 [42]. 본 책이 검토한 OSS 6개와 분석 글 다수는 모두 Karpathy의 어휘를 통해 분석한다. counter-take는 minority voice다 (Infranodus, Wenhao Yu, AI Critique, innobu). 본 책은 이 의존을 (Chapter 1)과 (Chapter 4)에서 명시적으로 표기하고, Karpathy를 "origin"이 아니라 "Bush 1945부터 이어진 라인의 integrator"로 위치 짓는다. 이 의식적 위치 잡기가 본 서베이의 G15 대응이다.

4.9 다음 챕터로 — OSS·콘텐츠 매트릭스

Karpathy의 gist는 패턴을 정의했다. 다음 한 달 반은 그 패턴이 코드·글·영상으로 어떻게 펴졌는가의 이야기다. (Chapter 5)는 6개의 OSS 구현(Astro-Han, lucasastorian, ussumant, ekadetov, OmegaWiki, Mcptube), 블로그 매트릭스, 영상 계보, HN·Reddit·GeekNews의 바이럴 흐름을 한 표로 묶는다. 본 서베이의 가장 정보 밀도 높은 챕터다. (Chapter 6)은 그 위에서 연구용 schema를 제안한다. wiki rot이라는 측정되지 않은 위험에 대해 honest framing으로.

참고문헌

  1. Karpathy, A. (2026). LLM Wiki — A pattern for building personal knowledge bases using LLMs. GitHub Gist, 2026-04-04.
  2. Karpathy, A., "LLM Wiki announcement (Twitter/X thread)," 2026-04-04. [Karpathy, 2026]
  3. Karpathy, A., "Farzapedia reply — personalization argument for LLM Wiki," 2026-04-12. [Karpathy, 2026]
  4. Karpathy, A. (2017). Software 2.0. Medium.
  5. MindStudio (2026). What Is Andrej Karpathy's LLM Wiki? How to Build a Personal Knowledge Base With Claude Code. MindStudio Blog. [MindStudio, 2026]
  6. Cognition AI (2026). llm-wiki: the reference implementation of Karpathy's self-building AI memory pattern. Cognition blog (re-syndicated). [Cognition, 2026]
  7. Denser.ai (2026). From RAG to LLM Wiki: What Karpathy's idea means for AI knowledge bases. Denser.ai blog. [Denser, 2026]
  8. Analytics Vidhya (2026). LLM Wiki Revolution: How Andrej Karpathy's Idea is Changing AI. Analytics Vidhya blog. [Analytics Vidhya, 2026]
  9. Agentpedia (2026). Karpathy's LLM Wiki: The Complete Guide to His Idea File. Agentpedia blog. [Agentpedia, 2026]
  10. Lobster Pack (2026). Karpathy's LLM Wiki and the rise of "idea files" — why sharing instructions beats sharing code. Lobster Pack blog. [Lobster Pack, 2026]
  11. WebEdge (2026). Karpathy's LLM Knowledge Base System: Full Breakdown of His CLAUDE.md Schema. MindStudio Blog (WebEdge attribution). [WebEdge, 2026]
  12. Starmorph (2026). Karpathy's LLM Wiki: Step-by-step setup guide. Starmorph blog. [Starmorph, 2026]
  13. Park, J. (2026). RAG는 잊어라, Karpathy가 제안하는 'LLM 위키'라는 새로운 지식 관리 패러다임. GeekNews / WikiDocs blog. [Park, 2026]
  14. Anthropic (2026). Claude Code documentation. Anthropic docs. [Anthropic, 2026]
  15. OpenAI (2026). Custom instructions with AGENTS.md (Codex). OpenAI Developers Portal. [OpenAI, 2026]
  16. Fulkerson, A. (2026). Karpathy's Pattern for an LLM Wiki in Production. aaronfulkerson.com blog. [Fulkerson, 2026]
  17. Aimaker (2026). AI-powered second brain from LLM Wiki — 4-month report. Aimaker Substack. [Aimaker, 2026]
  18. Hacker News community, "LLM Wiki — example of an 'idea file' (Hacker News front-page thread)," 2026-04-04. [HN, 2026]
  19. Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arXiv:2005.11401.
  20. Karpukhin, V., Oğuz, B., Min, S., Lewis, P., Wu, L., Edunov, S., et al. (2020). Dense Passage Retrieval for Open-Domain Question Answering. EMNLP 2020. arXiv:2004.04906.
  21. Johnson, J., Douze, M., and Jégou, H. (2019). Billion-scale similarity search with GPUs (FAISS). IEEE Transactions on Big Data. arXiv:1702.08734. DOI:10.1109/TBDATA.2019.2921572.
  22. Izacard, G., Lewis, P., Lomeli, M., Hosseini, L., Petroni, F., Schick, T., et al. (2022). Atlas: Few-shot Learning with Retrieval Augmented Language Models. JMLR 2023. arXiv:2208.03299.
  23. Bush, V. (1945). As We May Think (the Memex proposal). The Atlantic Monthly, July 1945.
  24. Luhmann, N. (1992). Communicating with Slip Boxes — An Empirical Account. Universität Bielefeld (translated essay).
  25. Clark, A. and Chalmers, D. (1998). The Extended Mind. Analysis 58 (1): 7-19. DOI:10.1093/analys/58.1.7.
  26. Ahrens, S. (2017). How to Take Smart Notes. Book (CreateSpace / Independently Published).
  27. Packer, C., Wooders, S., Lin, K., Fang, V., Patil, S. G., Stoica, I., and Gonzalez, J. E. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560.
  28. Wang, G., Xie, Y., Jiang, Y., Mandlekar, A., Xiao, C., Zhu, Y., Fan, L., and Anandkumar, A. (2023). Voyager: An Open-Ended Embodied Agent with Large Language Models. TMLR 2024. arXiv:2305.16291.
  29. Park, J. S., O'Brien, J. C., Cai, C. J., Morris, M. R., Liang, P., and Bernstein, M. S. (2023). Generative Agents: Interactive Simulacra of Human Behavior. UIST 2023. arXiv:2304.03442. DOI:10.1145/3586183.3606763.
  30. Shinn, N., Cassano, F., Berman, E., Gopinath, A., Narasimhan, K., and Yao, S. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS 2023. arXiv:2303.11366.
  31. Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., and Cao, Y. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arXiv:2210.03629.
  32. Schick, T., Dwivedi-Yu, J., Dessì, R., Raileanu, R., Lomeli, M., Zettlemoyer, L., Cancedda, N., and Scialom, T. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023. arXiv:2302.04761.
  33. Wei, J., Wang, X., Schuurmans, D., Bosma, M., Ichter, B., Xia, F., Chi, E., Le, Q., and Zhou, D. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS 2022. arXiv:2201.11903.
  34. FutureHouse (2024). PaperQA2: Superhuman scientific literature search (FutureHouse announcement). FutureHouse blog. [FutureHouse, 2024]
  35. skyllwt (DAIR Lab, PKU) (2026). OmegaWiki — Wiki-centric full-lifecycle AI research platform on Claude Code. GitHub. [skyllwt, 2026]
  36. Astro-Han (2026). Astro-Han/karpathy-llm-wiki — Agent Skills-compatible LLM Wiki for Claude Code/Cursor/Codex. GitHub. [Astro-Han, 2026]
  37. ekadetov (2026). ekadetov/llm-wiki — Claude Code plugin for persistent compounding KBs in Obsidian. GitHub. [ekadetov, 2026]
  38. Yu, W. (2026). What Is Karpathy's LLM Wiki? A Zettelkasten User's Honest Review. yu-wenhao.com blog. [Yu, 2026]
  39. Infranodus (2026). Infranodus on LLM Wiki — graph DBs as the missing layer. Infranodus blog. [Infranodus, 2026]
  40. innobu (2026). Karpathy's LLM Wiki: Second Brain and the Enterprise Reality Check 2026. innobu blog. [innobu, 2026]
  41. AI Critique (2026). Andrej Karpathy's latest concept 'LLM Wiki' and the future of enterprise knowledge. AI Critique blog. [AI Critique, 2026]
  42. Critical Analyst (2026). Research gap analysis — gaps.md (internal). terry-surveys repo. [Critical Analyst, 2026]