Miałem ostatnio nieprzyjemną przygodę. Padł mi dysk SSD. Całe szczęście nie straciłem dziesiątek tysięcy zdjęć, ale był to dysk systemowy, a na nim znajdowała się większość projektów Codexa. Same projekty były oczywiście wkomitowane do repozytoriów, więc kod ocalał. Wielkim zaskoczeniem okazało się natomiast to, jak poważnym problemem była utrata czegoś zupełnie innego: kontekstu. Wszystkie czaty, projekty, foldery robocze, cała historia rozmów z modelem zniknęły. Przez kilka tygodni odzyskiwałem ten kontekst i od nowa uczyłem model swojego stacku, swoich konwencji, sposobu pracy. Kod był bezpieczny, ale wiedza o tym, jak z nim pracuję, przepadła razem z dyskiem. Tego dało się uniknąć. Poniżej dowiesz się, jak.
Dlaczego faworyzacja kontekstu pojawia się akurat w tym momencie i dlaczego rezonuje tak mocno. Przez ostatnie lata uwaga branży skupiała się na samych modelach – która firma wypuści mocniejszy model, kto wygra kolejny benchmark, jak duże jest okno kontekstowe. Dziś środek ciężkości się przesunął. Na konferencjach branżowych, w rozmowach praktyków i w pracy zespołów wdrażających AI powtarza się jedna myśl: najistotniejszym filarem nie jest już wybór modelu, lecz kontekst, na którym ten model pracuje. To, co podajesz modelowi, jak ustrukturyzowane, jak aktualne, jak dobrze połączone, decyduje o jakości wyniku bardziej niż to, czy używasz modelu od tego czy innego dostawcy.
Modele zmieniają się co kilka miesięcy, szybciej niż ktokolwiek nadąża je testować. Budowanie czegokolwiek trwałego wokół konkretnego modelu jest stratą czasu. Model, na którym pracujesz dziś, za pół roku będzie przestarzały, ale fakt, że modele się zmieniają, przestaje być problemem w momencie, gdy dobrze zbudujesz fundamenty. Jeśli twoja wiedza żyje w czystej, ustrukturyzowanej, przenośnej warstwie – niezależnej od dostawcy i od konkretnej wersji modelu to wymiana modelu na nowszy staje się banalną operacją. Podpinasz nowszy, mądrzejszy silnik pod tę samą bazę i natychmiast zyskujesz lepsze odpowiedzi, nie tracąc nic z dorobku.
I właśnie na tym polega siła podejścia LLM Wiki. To warstwa kontekstu, która jest celowo oddzielona od silnika, który ją obsługuje. Inwestycja, którą wkładasz, nie idzie w model. Idzie w strukturę: w sposób, w jaki twoja wiedza jest rozłożona, opisana i powiązana. To aktywo, które nie tylko nie traci na wartości, ale przy każdej nowej generacji zyskuje. Ten sam dobrze zbudowany fundament obsłużony mądrzejszym modelem daje mądrzejsze odpowiedzi, bez żadnej dodatkowej pracy z twojej strony.
To stawia całą koncepcję drugiego mózgu w nowym świetle. Nie chodzi w niej tylko o wygodę przechowywania notatek. Chodzi o zbudowanie własnego, trwałego aktywa kontekstowego w świecie, w którym modele są towarem wymiennym, a kontekst — tym, co naprawdę należy do ciebie.
Skąd taki model budowania kontekstu
Andrej Karpathy to jeden z najbardziej szanowanych badaczy AI na świecie, współtwórca podstaw nowoczesnego uczenia maszynowego — opublikował na platformie X coś, co odbiło się echem daleko poza zwykłym cyklem newsów o sztucznej inteligencji. Nie ogłaszał nowego modelu ani wyniku benchmarku. Opisał zmianę w tym, jak sam używa modeli językowych: przesunięcie od generowania kodu do generowania struktury wiedzy. Dzień później opublikował towarzyszący temu wpisowi GitHub Gist zatytułowany „llm-wiki”, który w ciągu kilku tygodni zebrał ponad pięć tysięcy gwiazdek oraz wywołał lawinę społecznościowych implementacji.
Jest to zestaw zasad opisujących, jak strukturyzować osobistą bazę wiedzy, by model językowy mógł z niej naprawdę korzystać, a nie tylko ją przeszukiwać. Karpathy sam określa go jako „idea file”: plik pomysłu zaprojektowany tak, by wkleić go bezpośrednio do agenta LLM: Codexa, Claude Code, OpenCode czy innego który następnie wspólnie z użytkownikiem rozbuduje konkrety. Dokument celowo pozostaje abstrakcyjny. Jego jedynym zadaniem jest zakomunikowanie wzorca; resztę agent dopracuje.
Najgłębsza obserwacja Karpathy’ego brzmi tak: większość systemów „drugiego mózgu” zawodzi nie dlatego, że brakuje im treści, lecz dlatego, że brakuje im struktury, po której model językowy potrafi nawigować. Można mieć dziesięć tysięcy notatek i wciąż dostawać gorsze odpowiedzi niż ktoś, kto ma pięćdziesiąt dobrze zorganizowanych. Problem nie leży jedynie budowaniu i przechowywaniu, ale też w strukturze.
Dlaczego to nie jest kolejny RAG
Aby docenić, na czym polega nowość tego podejścia, trzeba zrozumieć, jak działa dominujący dziś sposób pracy z dokumentami i AI czyli RAG (Retrieval-Augmented Generation). W modelu RAG wgrywa się kolekcję plików, system tnie je na fragmenty i osadza w bazie wektorowej, a w momencie zadania pytania pobiera najbardziej pasujące kawałki i przekazuje je modelowi. Tak działają NotebookLM, wgrywanie plików w ChatGPT i większość systemów RAG. To rozwiązanie funkcjonuje, ale ma fundamentalną wadę: model za każdym razem odkrywa wiedzę od nowa. Nic się nie kumuluje. Kiedy zadasz subtelne pytanie wymagające zsyntetyzowania pięciu dokumentów, model musi za każdym razem na nowo odnaleźć i poskładać odpowiednie fragmenty.
Karpathy nazywa to „pamięcią złotej rybki”. Każda rozmowa zaczyna się od zera. Każdy wgląd wyparowuje, gdy zamykasz sesję. Dziewięćdziesiąt minut, które wczoraj poświęciłeś na przemyślenie problemu — przepadło. Pięć źródeł, które przeczytałeś — przepadło. Model mentalny, który zbudowałeś — przepadł. I tak właśnie 99 procent ludzi używa AI: jako mądrzejszego Google’a, który zapomina o tobie w chwili zamknięcia karty.
Podejście LLM Wiki działa odwrotnie. Zamiast jedynie pobierać dane z surowych dokumentów w momencie zapytania, model przyrostowo buduje i utrzymuje trwałe wiki — uporządkowaną, połączoną wzajemnie kolekcję plików markdown, która stoi pomiędzy użytkownikiem a surowymi źródłami. Kiedy dodajesz nowe źródło, model nie tylko je indeksuje. Czyta je, wydobywa kluczowe informacje i integruje je z istniejącym wiki: aktualizuje strony encji, rewiduje streszczenia tematów, odnotowuje, gdzie nowe dane przeczą starym twierdzeniom, wzmacnia lub podważa ewoluującą syntezę. Wiedza jest kompilowana raz, a potem utrzymywana na bieżąco — nie wyprowadzana ponownie przy każdym pytaniu.
Różnica jest jakościowa. W RAG dodanie źródła oznacza pocięcie go na fragmenty do późniejszego pobrania, a zadanie pytania — składanie odpowiedzi od zera. W LLM Wiki dodanie źródła oznacza, że AI je czyta, streszcza i aktualizuje każdą powiązaną stronę, a zadanie pytania — odczytanie gotowych, wstępnie zsyntetyzowanych stron z cytowaniami już osadzonymi w treści. Z czasem RAG nic nie kumuluje, podczas gdy wiki staje się coraz bogatsze: narastają wzajemne odnośniki, oznaczane są sprzeczności. Krok syntezy nie jest jedynie kompresją — to tłumaczenie surowego materiału na format, którego model faktycznie potrafi użyć. Model znacznie lepiej rozumuje nad dobrze ustrukturyzowaną, pięciusetwyrazową stroną wiki niż nad surową, ośmiotysięczną transkrypcją filmu z YouTube.
Dla osobistej bazy wiedzy — gdzie mówimy o setkach źródeł, a nie milionach — podejście wiki jest niemal zawsze lepsze. To, co powstaje po kilku tygodniach zapisywania i prowadzenia dziennika, zachowuje się mniej jak wyszukiwarka, a bardziej jak asystent badawczy, który przeczytał twoje notatki. Wie, czym się interesowałeś. Wie, z czym się zmagałeś. Potrafi połączyć dzisiejszy wpis o bieżącym problemie z filmem zapisanym trzy tygodnie temu.
Architektura: trzy warstwy
Cały system, niezależnie od liczby dodanych rozszerzeń, opiera się na trzech warstwach. Karpathy określa je jako fundament i wyjaśnia, że najważniejsze w całej koncepcji jest właśnie rozdzielenie odpowiedzialności między nimi. Większość zbieranych informacji autor sugeruje utrzymywać w programie do notatek Obsidian.
Warstwa pierwsza — surowe źródła. To kuratorowana kolekcja dokumentów źródłowych: artykuły, prace naukowe, obrazy, pliki danych, transkrypcje, notatki ze spotkań. Trafia tu wszystko, co chcesz zapamiętać. Ta warstwa rządzi się jedną żelazną zasadą: pliki są niezmienne. Gdy coś tu wyląduje, nie edytujesz tego — nawet literówki. Model czyta z tej warstwy, ale nigdy jej nie modyfikuje. To twoje źródło prawdy. Powód tej niezmienności jest praktyczny: jeśli model kiedykolwiek przepisałby źródło, tracisz możliwość audytu — nie wiesz już, na czym opierają się twoje wnioski. Źródła to skała macierzysta; wszystko inne jest interpretacją. W praktyce ta warstwa to folder o nazwie raw/ (lub sources/), często z podkatalogami w rodzaju raw/articles/.
Warstwa druga — wiki. To katalog plików markdown wygenerowanych przez model: streszczenia, strony encji (osób, firm, narzędzi, produktów), strony koncepcji (idei, frameworków, teorii, metod), porównania, strona przeglądowa, synteza. Tę warstwę model posiada w całości na własność. Tworzy strony, aktualizuje je, gdy napływają nowe źródła, utrzymuje wzajemne odnośniki i pilnuje spójności. Ty czytasz; model pisze. Pojedyncze źródło może dotknąć od dziesięciu do piętnastu stron wiki. Co istotne — ten układ kumuluje się: każde nowe źródło, które model przyjmie, czyni całe wiki mądrzejszym. Sieć staje się gęstsza z czasem.
Warstwa trzecia — schemat. To plik konfiguracyjny, który mówi modelowi, jak wiki jest zbudowane, jakie obowiązują konwencje i jakie procedury stosować przy przyjmowaniu źródeł, odpowiadaniu na pytania czy utrzymaniu bazy. Dla Claude Code jest to plik CLAUDE.md, dla Codexa — AGENTS.md. To kluczowy plik konfiguracyjny: to właśnie on zamienia model w zdyscyplinowanego opiekuna wiki, a nie ogólnego chatbota. Ty i model wspólnie rozwijacie ten dokument w czasie, w miarę jak odkrywacie, co sprawdza się w twojej dziedzinie.
Metafora Karpathy’ego jest precyzyjna: Obsidian jest IDE, model językowy jest programistą, a wiki jest bazą kodu.
Cztery operacje, na których stoi system
Codzienna praca z LLM Wiki sprowadza się do kilku powtarzalnych operacji. Karpathy opisuje trzy podstawowe; w implementacjach na Claude Code mapują się one często na cztery komendy-skille (/capture, /sync, /lint, /digest).
Przyjmowanie źródła (Ingest). Wrzucasz nowe źródło do kolekcji surowej i mówisz modelowi, by je przetworzył. Przykładowy przepływ: model czyta źródło, omawia z tobą kluczowe wnioski, pisze stronę-streszczenie w wiki, aktualizuje indeks, aktualizuje powiązane strony encji i koncepcji w całym wiki, dopisuje wpis do logu. Karpathy osobiście woli przyjmować źródła pojedynczo i pozostawać zaangażowanym — czyta streszczenia, sprawdza aktualizacje, kieruje modelem co do tego, co podkreślić. Ale można też przetwarzać wiele źródeł naraz, z mniejszym nadzorem. Wybór należy do użytkownika; ważne, by udokumentować go w schemacie dla przyszłych sesji.
Zapytanie (Query). Zadajesz pytania bazie wiki. Model szuka odpowiednich stron, czyta je i syntezuje odpowiedź z cytowaniami. Odpowiedź może przybrać różne formy zależnie od pytania — strony markdown, tabeli porównawczej, prezentacji (przez Marp), wykresu (przez matplotlib), kanwy. Najważniejszy wgląd: dobre odpowiedzi można odłożyć z powrotem do wiki jako nowe strony. Porównanie, o które poprosiłeś, analiza, odkryte połączenie — to wszystko jest cenne i nie powinno zniknąć w historii czatu. Dzięki temu twoje eksploracje kumulują się w bazie wiedzy tak samo jak przyjęte źródła.
Kontrola jakości (Lint). Okresowo prosisz model o sprawdzenie kondycji wiki. Model skanuje cały zbiór w poszukiwaniu sprzeczności między stronami, nieaktualnych twierdzeń, które wyparły nowsze źródła, stron-sierot bez przychodzących linków, ważnych koncepcji wspomnianych, ale pozbawionych własnej strony, brakujących odnośników oraz luk w danych, które mógłby wypełnić wyszukiwaniem w sieci. Model dobrze radzi sobie z sugerowaniem nowych pytań do zbadania i nowych źródeł do znalezienia. To utrzymuje wiki w zdrowiu, gdy rośnie.
Indeks i log: jak model nawiguje po rosnącej bazie
Dwa specjalne pliki pomagają modelowi (i tobie) poruszać się po wiki w miarę jego rozrostu, a służą różnym celom.
index.md jest zorientowany na treść. To katalog wszystkiego, co znajduje się w wiki – każda strona wymieniona z linkiem, jednozdaniowym streszczeniem i opcjonalnie metadanymi w rodzaju daty czy liczby źródeł, zorganizowany według kategorii (encje, koncepcje, źródła). Model aktualizuje go przy każdym przyjęciu źródła. Odpowiadając na zapytanie, model najpierw czyta indeks, by znaleźć odpowiednie strony, a potem zagłębia się w nie. Karpathy podkreśla, że to podejście zaskakująco dobrze działa w umiarkowanej skali — około stu źródeł, kilkuset stron — i pozwala uniknąć całej infrastruktury RAG opartej na osadzaniu wektorowym.
log.md jest chronologiczny. To dopisywany wyłącznie na końcu zapis tego, co się działo i kiedy — przyjęcia źródeł, zapytania, przebiegi kontroli jakości. Praktyczna sztuczka: jeśli każdy wpis zaczyna się od spójnego prefiksu (na przykład ## [2026-04-02] ingest | Tytuł artykułu), log staje się parsowalny prostymi narzędziami uniksowymi. Polecenie grep "^## \[" log.md | tail -5 zwróci pięć ostatnich wpisów. Log daje oś czasu ewolucji wiki i pomaga modelowi zrozumieć, co zrobiono ostatnio.
Stos narzędziowy: co jest naprawdę potrzebne
Obsidian pełni rolę interfejsu, „frontendu IDE” dla bazy wiedzy. To lokalna aplikacja do notatek przechowująca pliki markdown na dysku, co utrzymuje cały system przenośnym i działającym offline. Najcenniejszym jej elementem w tym kontekście jest widok grafu, który renderuje powiązania między stronami wiki jako wizualną sieć — sprawia, że luki strukturalne i zbyt gęste klastry stają się widoczne na pierwszy rzut oka. Do Obsidiana dochodzi Obsidian Web Clipper: rozszerzenie do przeglądarki dostępne ze strony obsidian.md, które konwertuje strony internetowe na markdown i jednym kliknięciem zapisuje je do folderu surowego.
Codex to drugie narzędzie — agentowe środowisko AI od OpenAI z funkcją automatyzacji. To właśnie agent, który czyta plik schematu, przetwarza nowe źródła, pisze strony wiki i przeprowadza kontrole jakości. Karpathy zaznacza, że jego „idea file” jest zaprojektowany tak, by wkleić go bezpośrednio do Codexa lub podobnego agenta i błyskawicznie zainicjować system. Warto wiedzieć, że to samo podejście działa równie dobrze z Claude Code różnica sprowadza się głównie do nazwy pliku schematu (AGENTS.md versus CLAUDE.md).
Budowa krok po kroku
Proces zaczyna się od utworzenia nowego sejfu w Obsidianie. Jest to po prostu folder na dysku, w którym zamieszkają wszystkie pliki markdown. Następnie wkleja się specyfikację Karpathy’ego do Codexa wraz z instrukcją w rodzaju: „Jesteś teraz moim agentem LLM wiki. Zaimplementuj ten plik pomysłu jako mój kompletny drugi mózg. Przeprowadź mnie krok po kroku przez utworzenie pliku schematu z pełnymi zasadami i podstawowych folderów”. Agent na tej podstawie tworzy strukturę: warstwę źródeł, warstwę wiki, plik schematu oraz dwa pliki nawigacyjne (index.md i log.md).
Tu pojawia się praktyczna pułapka, o której warto wiedzieć z wyprzedzeniem. Codex ma tendencję do nadmiarowego generowania, potrafi stworzyć pięćdziesiąt plików, gdy potrzeba pięciu. Lekarstwem jest komenda w rodzaju: „zbuduj tylko to, co jest wyraźnie wymienione w planie Karpathy’ego”. Agent przycina wtedy strukturę do minimalnej specyfikacji. Karpathy sam radzi, by pierwsza wersja pozostała mała: nie przeprojektowywać schematu, nie nadbudowywać wyszukiwania, nie importować całego cyfrowego życia w jeden weekend. Zacząć od dziesięciu źródeł, upewnić się, że przyjmowanie, zapytania i kontrola jakości działają naturalnie — a dopiero potem rozbudowywać. Pierwsze kilka przyjęć wymaga nadzoru, konwencje nazewnictwa będą ewoluować, niektóre strony na początku będą chaotyczne. To normalne.
Gdy szkielet stoi, przechodzi się do faktycznego użytku. Otwiera się artykuł, który chce się zapisać, i wysyła go do sejfu przez Web Clipper. W ustawieniach clippera nazwa vaultu musi się dokładnie zgadzać, a folder docelowy należy ustawić na raw/articles, by artykuł wylądował w warstwie źródłowej, a nie został zmieszany z generowanym wiki.
Wpychanie treści: gdzie tkwi codzienne tarcie
Najbardziej praktyczny punkt tarcia w całym systemie to dostarczanie treści do folderu surowego. Jeśli to irytujące, po prostu nie będziesz tego robił. Web Clipper redukuje ten wysiłek do jednego kliknięcia i ma jedną szczególnie użyteczną cechę: automatycznie pobiera pełne transkrypcje filmów z YouTube. Wchodzisz na dowolny film, klikasz clipper, a cała transkrypcja ląduje w folderze raw/ jako plik markdown z frontmatterem zawierającym tytuł źródła, URL, datę zapisu i tag „web-clip”. Bez kopiowania, bez zewnętrznego serwisu do transkrypcji. To samo dotyczy całych podcastów z YouTube — można wysłać do Obsidiana zarówno link, jak i pełną transkrypcję.
Warto znać jedno ograniczenie: Web Clipper nie pobiera automatycznie nazwy kanału YouTube do frontmattera. Trzeba dodać do pliku agents.md linijkę instruującą agenta, by przy przetwarzaniu klipów z YouTube wydobywał nazwę kanału z adresu URL i dopisywał ją do frontmattera pliku źródłowego. To jednolinijkowa edycja pliku markdown — dokładnie ten rodzaj dostosowania, do którego architektura jest zaprojektowana.
Dla notatek ze spotkań sprawdza się narzędzie Granola, które potrafi automatycznie wstrzykiwać transkrypcje bezpośrednio do bazy wiedzy. Oznacza to, że twoje rozmowy na żywo i połączenia przez Zoom zasilają ten sam system co klipy z sieci. Warstwa wejściowa staje się kompleksowa bez wymagania ręcznego wysiłku przy każdym pojedynczym źródle.
Karpathy dodaje jeszcze jedną wskazówkę dotyczącą obrazów: w ustawieniach Obsidiana (Files and links) warto ustawić „Attachment folder path” na stały katalog, na przykład raw/assets/, a w skrótach klawiszowych przypisać hotkey do polecenia „Download attachments for current file”. Po sklipowaniu artykułu jedno naciśnięcie pobiera wszystkie obrazy na dysk lokalnie, dzięki czemu model może je oglądać i się do nich odwoływać zamiast polegać na adresach URL, które mogą przestać działać. Co istotne, modele nie potrafią natywnie odczytać markdownu z osadzonymi obrazami w jednym przebiegu; obejściem jest najpierw odczytanie tekstu, a potem osobne obejrzenie wybranych obrazów.
Automatyzacja i kopia zapasowa
Dwie ostatnie warstwy systemu czynią go naprawdę autonomicznym. Pierwsza to automatyczne linkowanie wiki — funkcja automatyzacji Codexa pozwala uruchamiać przetwarzanie cyklicznie, na przykład co godzinę, tak by agent przetwarzał wszystko, co napłynęło, bez dotykania systemu przez użytkownika. To zamyka pętlę: treść wpada przez Web Clipper, a agent w tle czyta ją, syntezuje i wplata w istniejącą sieć stron.
Druga to kopia zapasowa na GitHub. Ponieważ całe wiki to po prostu repozytorium git złożone z plików markdown, otrzymujesz za darmo historię wersji, rozgałęzianie i współpracę. Backup całego drugiego mózgu sprowadza się do regularnego commitowania i pushowania do zdalnego repozytorium. Nie ma uzależnienia od dostawcy, nie ma zastrzeżonej bazy danych, nie ma subskrypcji poza samym modelem.
Karpathy wspomina też o opcjonalnych narzędziach CLI dla większej skali. Gdy wiki rozrośnie się na tyle, że sam plik indeksu przestaje wystarczać, warto zbudować małą wyszukiwarkę po stronach. Dobrym wyborem jest qmd — lokalna wyszukiwarka plików markdown z hybrydowym wyszukiwaniem BM25/wektorowym i ponownym rankingiem przez LLM, działająca w całości na urządzeniu, dostępna zarówno jako CLI, jak i serwer MCP. Można też zlecić modelowi „zwibowanie” prostszego skryptu wyszukiwania, gdy pojawi się taka potrzeba.
Dlaczego to działa – i czego nie rozwiązuje
Sednem skuteczności tego podejścia jest jedna rzecz, którą Karpathy ujmuje wprost. Żmudna część utrzymywania bazy wiedzy to nie czytanie ani myślenie — to księgowość. Aktualizowanie odnośników, utrzymywanie streszczeń na bieżąco, odnotowywanie, kiedy nowe dane przeczą starym twierdzeniom, pilnowanie spójności na dziesiątkach stron. Ludzie porzucają wiki, bo ciężar utrzymania rośnie szybciej niż wartość. Modele językowe się nie nudzą, nie zapominają zaktualizować odnośnika i potrafią dotknąć piętnastu plików w jednym przebiegu. Wiki pozostaje utrzymane, ponieważ koszt utrzymania jest bliski zeru. Zadaniem człowieka jest kuratorować źródła, kierować analizą, zadawać dobre pytania i myśleć o tym, co to wszystko znaczy. Zadaniem modelu jest cała reszta.
Sam Karpathy umieszcza tę ideę w długiej tradycji intelektualnej. Wzorzec jest pokrewny duchowi „Memexu” Vannevara Busha z 1945 roku — wizji osobistego, kuratorowanego magazynu wiedzy ze skojarzeniowymi ścieżkami między dokumentami. Wizja Busha była bliższa temu niż temu, czym stała się sieć: prywatna, aktywnie kuratorowana, z połączeniami między dokumentami równie cennymi jak same dokumenty. Część, której Bush nie potrafił rozwiązać, to pytanie, kto wykonuje utrzymanie. Model językowy je przejmuje.
Uczciwość wymaga jednak odnotowania ograniczeń, które ujawniają się dopiero przy skali. W komentarzach pod gistem Karpathy’ego pojawiła się rzeczowa krytyka. Gdy przechodzi się od dziesięciopikowego demo do prawdziwego archiwum — na przykład dziesięcioletniej historii korespondencji prezesa firmy — okazuje się, że zamiast prostego systemu plików próbuje się zbudować złożoną bazę danych na neuronach. Pojedyncza zmiana w jednym dokumencie może wywołać kaskadę rewizji w dziesiątkach plików, co w klasycznej bazie SQL załatwiają indeksy w milisekundy, a w LLM Wiki wymaga łańcucha wywołań modelu pochłaniających czas i tokeny. Model nie ma wbudowanego pojęcia integralności referencyjnej — usunięcie lub zmiana nazwy pliku zostawia martwe „inteligentne linki”. W dużych archiwach pojawia się też „ślepota temporalna”: dane z 2018 roku wypływają tak, jakby były aktualne. Konkluzja krytyków jest wyważona: dla statycznych archiwów to prawdopodobnie najlepszy sposób na szybkie „wskrzeszenie” historii starych projektów, ale dla żywego środowiska firmowego podejście „to tylko folder plików markdown” grozi utratą kontroli nad danymi.
Karpathy zresztą sam to przewiduje, gdy zaznacza, że pierwsza wersja powinna pozostać mała, że indeks wystarcza tylko w umiarkowanej skali, a powyżej niej przydaje się prawdziwa wyszukiwarka. To wzorzec, nie sztywna implementacja — i właśnie dlatego nadaje się przede wszystkim do osobistej i badawczej skali setek źródeł, do której film Wolfe’a jest skrojony.
