LLM wiki Karpathy’ego: po co jest, jak ją wdrożyliśmy i co da się poprawić

„Żmudna część utrzymywania bazy wiedzy to nie czytanie ani myślenie — to księgowość”. Tak Andrej Karpathy tłumaczy, dlaczego ludzie porzucają swoje wiki: koszt utrzymania rośnie szybciej niż pożytek. Gist llm-wiki.md, opublikowany 4 kwietnia 2026 roku, nie jest ani biblioteką, ani benchmarkiem, ani modelem — to półtoratysięczny opis wzorca, przeznaczony do wklejenia własnemu agentowi i zinstancjonowania razem z nim. 22 września zrobiliśmy to w jednym z naszych produkcyjnych projektów — AI Budget Assistant — i w jeden dzień wynieśliśmy z głównego pliku projektu 24 616 słów. Poniżej: czym jest ten wzorzec, w co się u nas zamienił i przede wszystkim co w naszej implementacji wciąż nie działa.

Co zaproponował Karpathy

Typowe doświadczenie pracy z modelem językowym i dokumentami wygląda jak RAG RAG (Retrieval-Augmented Generation) pozwala AI najpierw sprawdzić Twoje dokumenty, a dopiero potem odpowiedzieć — dzięki temu odpowiedzi opierają się na Twoich danych, a nie na domysłach. Pełna definicja →: wgrywasz zbiór plików, model przy każdym pytaniu wyciąga pasujące fragmenty i generuje odpowiedź. To działa, ale wiedza za każdym razem odkrywana jest od zera. Zadaj pytanie wymagające syntezy pięciu dokumentów, a model znów będzie szukał i sklejał fragmenty. Nic się nie kumuluje. Tak działa NotebookLM, tak działa wgrywanie plików do czatu i tak działa większość systemów RAG.

Pomysł z gistu jest inny. Między tobą a źródłami pojawia się LLM wiki LLM wiki to baza wiedzy z plików markdown, którą utrzymuje model językowy: czyta nowe źródła i sam wplata je w istniejące strony razem z odsyłaczami, zamiast szukać wszystkiego od nowa przy każdym pytaniu. Wzorzec opisał Andrej Karpathy. Pełna definicja → — uporządkowany, wzajemnie zlinkowany zbiór plików markdown, który model buduje i utrzymuje przyrostowo. Nowe źródło nie jest tylko indeksowane na później: model je czyta, wyciąga to, co istotne, i wplata w wiki, która już istnieje — poprawia strony encji, rewiduje podsumowania tematów, odnotowuje, gdzie nowe dane przeczą starym twierdzeniom. Wiedza jest kompilowana raz, a potem utrzymywana w aktualności, zamiast być wyprowadzana od nowa przy każdym zapytaniu.

Na tym polega cała różnica: wiki jest artefaktem, który się kumuluje. Odsyłacze już są. Sprzeczności już zostały oznaczone. Synteza już uwzględnia wszystko, co przeczytano. Sam prawie jej nie piszesz — pisze ją model; twoją rolą są źródła, kierunek i dobre pytania. Karpathy opisuje swój układ tak: agent w jednym oknie, Obsidian w drugim, zmiany widoczne na żywo. Obsidian jest IDE, model programistą, a wiki kodem.

Trzy warstwy i trzy operacje

Operacje również są trzy. Ingest — pojawia się nowe źródło, model je czyta, omawia z tobą wnioski, pisze stronę-podsumowanie, aktualizuje indeks i wszystkie dotknięte strony, dopisuje wiersz do dziennika; jedno źródło może dotknąć dziesięciu-piętnastu stron. Query — zadajesz pytanie, model znajduje właściwe strony, czyta je i odpowiada z cytowaniem; i co najważniejsze, dobra odpowiedź wraca do wiki jako nowa strona, żeby twoje poszukiwania kumulowały się tak samo jak przyjęte źródła. Lint — okresowe badanie zdrowia: sprzeczności między stronami, nieaktualne twierdzenia, strony-sieroty bez linków przychodzących, ważne pojęcia bez własnej strony, brakujące odsyłacze, luki w danych.

Osobno stoją dwa pliki służbowe. Indeks jest zorientowany na treść: katalog wszystkiego, co jest w wiki, z linkiem i jednozdaniowym opisem każdej strony. Dziennik jest zorientowany na czas: zapis tylko-do-dopisywania tego, co i kiedy się wydarzyło. Karpathy zauważa, że przy około stu źródłach i kilkuset stronach sam indeks wystarcza, a infrastruktura na osadzeniach nie jest w ogóle potrzebna.

Czym to się różni od RAG i od zwykłej dokumentacji

Od RAG — miejscem, w którym zachodzi synteza. W RAG zachodzi w chwili odpowiedzi i umiera razem z nią. W wiki zachodzi w chwili przyjęcia źródła i zostaje na dysku. Koszt pytania spada nie dlatego, że wyszukiwanie się poprawiło, ale dlatego, że nie ma już wiele do odpowiadania: połowa pracy została wykonana wcześniej.

Od zwykłej dokumentacji — tym, kto płaci za utrzymanie. Dokumentacja gnije nie z lenistwa, tylko dlatego, że księgowość odsyłaczy kosztuje dużo, a jej wartość jest rozsmarowana po przyszłości. Model się nie nudzi, nie zapomina zaktualizować odsyłacza i potrafi dotknąć piętnastu plików w jednym przebiegu. Koszt utrzymania spada niemal do zera — i to jedyny powód, dla którego wiki w ogóle może przetrwać.

Jest jednak warunek, który gist wypowiada łagodnie, a u nas okazał się twardy: musi istnieć pętla, a nie jednorazowy akt. Przekonaliśmy się o tym najdroższą drogą.

Dlaczego się za to wzięliśmy: 104 tysiące tokenów przed pierwszą linią kodu

AI Budget Assistant to monorepo: API API to interfejs, przez który dwa systemy wymieniają dane automatycznie — bez eksportów do Excela i przeklejania ręką. Pełna definicja → na NestJS, aplikacja mobilna na Expo, panel administracyjny na Next.js, trzy boty czatowe i dwa pakiety współdzielone. Jego CLAUDE.md — plik, który agent wczytuje w całości w każdej sesji — urósł do 77 100 słów. To mniej więcej 104 tysiące tokenów Token to fragment tekstu, zwykle kawałek słowa, w którym modele AI mierzą i długość zapytania, i koszt — rachunek wystawiany jest za tokeny, nie za pytania. Pełna definicja →, 187 punktów najwyższego poziomu, a największy z nich liczy 4 629 słów.

Plik był dokładny. Rytuał zamykania zadania dopisywał do niego wszystko, czego dowiedziano się po drodze, i to uczciwie działało. Zła była forma: agent płacił 104 tysiące tokenów, zanim zaczął pracować, a znalezienie jednego faktu oznaczało grepowanie pliku bez nawigacji. Punkt na 4 629 słów to już nie dokumentacja, tylko cztery różne tematy pod jednym nagłówkiem.

Wiki, która kłamała przez cztery miesiące

Najciekawsze jest to, że katalog docs/wiki w tym repozytorium już istniał. Piętnaście stron napisanych w maju, w dobrej formie. Problem był jeden — po maju nigdy nic do nich nie trafiło.

We wrześniu wiki twierdziła: 11 funkcji AI — było ich 18; 8 języków — jest dziewięć; 30 modułów API — czterdzieści osiem. Plik trendów zdrowia zawierał dokładnie jeden punkt danych, z 14 maja.

To nie jest nieszkodliwe. Nieaktualna wiki jest gorsza niż jej brak: agent ją czyta i z przekonaniem podaje złą liczbę, a człowiek, który tę liczbę dostał, nie ma powodu jej sprawdzać. Brakująca strona przynajmniej odsyła do kodu.

Pierwszy przebieg czytania po ponownym uruchomieniu znalazł dziesięć nieaktualnych twierdzeń na dwóch stronach. Najgorszym był opis synchronizacji: strona przedstawiała ogólną kolejkę jako ścieżkę synchronizacji aplikacji mobilnej, podczas gdy dwie kluczowe funkcje tej kolejki mają zero miejsc wywołania w całym repozytorium. Trzy z tych samych błędów żyły też w CLAUDE.md i zostały tam poprawione.

Nasza decyzja: CLAUDE.md staje się schematem

Projekt zapisaliśmy osobnym dokumentem przed pracą — cztery decyzje, a każda z nich zamykała konkretny sposób umierania.

Pierwsza: CLAUDE.md przestaje być magazynem treści i staje się schematem — właśnie tą trzecią warstwą z gistu. Zostają w nim reguły na poziomie repozytorium, konwencje, niezmienniki nienależące do żadnej pojedynczej funkcjonalności, zmienne środowiskowe, procedura wdrożenia i wskaźnik do indeksu. Wszystko faktograficzne o konkretnej funkcjonalności przenosi się na stronę wiki. Jedno źródło prawdy — bo wiki obok żywego, wciąż rosnącego CLAUDE.md to dokładnie sposób, w jaki umarła poprzednia wiki.

Druga: migracja jest przyrostowa, nigdy jednym przebiegiem. Zadanie, które dotyka funkcjonalności, przenosi jej opis z CLAUDE.md na stronę w ramach tego samego zadania. Przeniesienie 77 tysięcy słów za jednym posiedzeniem to praca mechaniczna z dużą szansą zgubienia niuansów, a niuanse są tu całą wartością.

Trzecia: dwa poziomy — koncentratory domen i strony funkcjonalności. Piętnaście istniejących stron staje się koncentratorami: czym jest domena, gdzie są punkty wejścia, linki do stron funkcjonalności pod nią. Ziarnistość zgrała się z tym, jak przychodzi praca: jedno zadanie to zwykle jedna funkcjonalność, więc zadanie zawsze ma oczywistą stronę docelową. Drobiazg, ale to on zamienia ingest z decyzji w odruch.

Czwarta: koncentratory leżą w katalogu głównym wiki (nazwy plików zachowane — już się do nich linkuje z innych miejsc), a strony funkcjonalności w podkatalogu.

Szablon strony i sekcja, dla której się ją otwiera

Sześć sekcji, jedna forma w całej wiki. Czym to jest — dwa, trzy zdania: jaki problem rozwiązuje i dla kogo. Punkty wejścia — pliki ze ścieżkami, od czego zacząć czytanie. Kluczowe pojęcia — mechanizm, nie samouczek. Niezmienniki — co nie może się zepsuć, sformułowane jako reguła, z uzasadnieniem. Znane luki — czego świadomie nie zrobiono i dlaczego, żeby nikt nie decydował tego od nowa. Historia — linki do zgłoszeń: dlaczego jest tak, jak jest.

Niezmienniki to sekcja, dla której otwiera się stronę, i właśnie jej w starej wiki nie było. „Nie przywracaj aktualizacji znacznika synchronizacji per trasa”, „rozwiąż klucz główny serwera, zanim użyjesz identyfikatora jako klucza obcego” — te zdania były w CLAUDE.md, ale pogrzebane wewnątrz czterotysięcznych punktów i osiągalne wyłącznie grepem.

Dwie reguły o uczciwości formy. Sekcję naprawdę pustą lepiej pominąć, niż wpisać w nią „brak”: nieobecna sekcja uczciwie czyta się jako „jeszcze nie badane”, a słowo „brak” czyta się jako twierdzenie. I strona nie ma prawa podawać liczby: liczniki dezaktualizują się po cichu, więc gdy audyt znajduje liczbę na stronie, właściwą poprawką jest ją usunąć, a nie zaktualizować. Ten artykuł jest artefaktem z datą i liczby w nim są; strona wiki takiego przywileju nie ma.

Trzy rytuały

flowchart TB
  SCH["Schemat:<br/>reguły repozytorium<br/>i wskaźnik do indeksu"] --> IDX
  subgraph ENTRY["Trzy wejścia"]
    T["Zadanie ukończone"]
    Q["Pytanie odpowiedziane"]
    W["Cotygodniowa kontrola"]
  end
  T --> PAGE["Strona funkcjonalności:<br/>mechanizm, niezmienniki,<br/>znane luki"]
  Q --> PAGE
  PAGE --> IDX["Indeks:<br/>koncentrator na domenę,<br/>strona na funkcjonalność"]
  PAGE --> LOG["Dziennik:<br/>jeden wiersz na wpis"]
  W --> LINT["Skrypty bez modelu:<br/>martwe linki, sieroty,<br/>strony wyprzedzone przez kod"]
  LINT --> REP["Raport w jednym<br/>długowiecznym zgłoszeniu"]
  REP --> READ["Audyt czytający w sesji:<br/>dwie, trzy strony porządnie"]
  READ --> PAGE
  READ --> LOG
  IDX --> ANS["Odpowiedź z podaną<br/>ścieżką strony"]

O Query warto powiedzieć osobno, bo w pierwszej wersji naszego projektu tego punktu nie było — a bez niego wzorzec jest złożony do połowy. Ingest kumuluje wiedzę ze zmian. Bez Query wiki nigdy nie zacznie kumulować wiedzy z pytań: sesja, która spędziła godzinę na udowodnieniu, dlaczego coś zachowuje się tak, a nie inaczej, i nie zmieniła ani linijki kodu, nie zostawia żadnego śladu. Diagnoza kończąca się zdaniem „wszystko działa poprawnie” jest najgorszym przypadkiem: po poprawce zostaje przynajmniej commit i zgłoszenie, po czystej diagnozie nie zostaje nic, i to właśnie ją następna sesja zbada od nowa.

Druga reguła tego samego rytuału: odpowiadać, cytując ścieżkę strony. Odpowiedź bez cytowania jest nie do odróżnienia od wymyślonej na poczekaniu, a czytający nie może ani sprawdzić źródła, ani go poprawić. A jeśli strona rozminęła się z kodem, to samo w sobie jest znaleziskiem: stronę poprawia się w tej samej odpowiedzi, zamiast ją po cichu omijać.

Dlaczego w naszym CI nie ma ani jednego wywołania modelu

Lint jest podzielony na dwie części według tego, co gdzie w ogóle może się wykonać.

Część sprawdzalna maszynowo działa co tydzień w CI. Pierwszy skrypt weryfikuje, że każdy link między stronami prowadzi do istniejącego pliku, że każda cytowana ścieżka jest na dysku i że żadna strona funkcjonalności nie została sierotą bez linku z indeksu. Drugi porównuje datę ostatniego commita strony z datami commitów plików, które ona cytuje, i zgłasza strony, których kod wyprzedził je o trzy lub więcej commitów. Pierwszy kończy się kodem niezerowym, drugi zawsze zerowym: to raport, nie szlaban. Nikt nie powinien być blokowany na scalaniu dlatego, że strona jest tydzień do tyłu. Oba trafiają komentarzem do jednego długowiecznego zgłoszenia, a nie do nowego co tydzień — inaczej repozytorium zarośnie niemal identycznymi raportami, których nikt nie czyta.

Żaden krok tego przepływu nie wywołuje modelu i nie jest to asceza. Claude Code działa w tym projekcie na abonamencie, więc nie ma klucza API, który można by włożyć do sekretów repozytorium — a zadanie wymagające klucza po prostu nigdy by się nie uruchomiło. Dlatego czytająca połowa lintu — sprzeczności między stronami, brakujące odsyłacze, luki w danych — jest umiejętnością uruchamianą wewnątrz sesji, gdzie model jest już opłacony. Raport o dezaktualizacji służy jej jako kolejność priorytetów: strona z dwudziestoma commitami za sobą to miejsce, w które trzeba spojrzeć najpierw; strona z trzema wymaga zapewne tylko rzutu oka.

I jeszcze jedna reguła wyciągnięta z poprzedniej porażki: przeczytać dwie, trzy strony porządnie, zamiast przebiegać wzrokiem wszystkie. Pobieżny przegląd z wnioskiem „wygląda dobrze” to dokładnie ten mechanizm, dzięki któremu poprzednia wiki pozostawała błędna przez cztery miesiące.

Gdzie świadomie rozeszliśmy się z gistem

Trzy różnice, wszystkie trzy wynikające z tego, że nasza dolna warstwa nie jest dolną warstwą wiki osobistej.

Nie mamy warstwy surowych źródeł. U Karpathy’ego dolną warstwą jest niezmienny zbiór artykułów, PDF-ów i obrazów. U nas źródłem prawdy jest sam kod, a wiki go streszcza. To zmienia naturę błędu. W wiki osobistej źródło jest statyczne, a strona rozmija się z nim tylko wtedy, gdy została źle napisana. U nas źródło zmienia się codziennie, więc strona może stać się nieprawdziwa, nie będąc ani razu edytowana. Stąd raport o dezaktualizacji, którego w gistcie w ogóle nie ma: potrzebujemy sygnału, że pod stroną przesunęła się ziemia.

Zakazaliśmy liczb na stronach. W wiki osobistej liczba to fakt ze źródła. U nas liczba jest prawie zawsze licznikiem czegoś w repozytorium i dezaktualizuje się pierwsza. To bezpośrednia konsekwencja „11 funkcji AI” przy 18: strona, która nie podaje liczby, nie może podać jej błędnie.

Nie budujemy wyszukiwarki. Gist proponuje qmd, lokalną wyszukiwarkę po markdown z hybrydowym BM25 i wyszukiwaniem wektorowym. Na razie wystarcza indeks: wiki czyta się po ścieżkach, dokładnie tak, jak agent czyta kod. Żadnych osadzeń ani magazynu wektorowego — i wrócimy do tej decyzji, gdy indeks przestanie mieścić się w jednym spojrzeniu, a nie wcześniej.

Co dał pierwszy dzień

Jedno zadanie wdrożeniowe i dwa zwykłe zadania z ingestem, a CLAUDE.md przeszedł drogę 77 100 → 63 916 → 59 394 → 52 484 słowa. Dwanaście najcięższych punktów zostało wyniesionych. Największy z nich, na 4 629 słów, okazał się czterema tematami pod jednym nagłówkiem i zamienił się w cztery osobne strony — co samo w sobie jest diagnozą tego, jak wiedza żyła wcześniej.

Do tego strony, które narodziły się nie z migracji, lecz ze zwykłych zadań: rozjazd identyfikatorów kategorii między telefonem a serwerem, przez który filtr nie znajdował nic, oraz licznik odświeżania widżetu przeciekający między plikami mobilnego zestawu testów i przypisujący awarię temu zestawowi, który akurat biegł. Obie strony istnieją wyłącznie dlatego, że rytuał zamykania zadania prowadzi teraz do wiki, a nie do CLAUDE.md.

Co w tym układzie jeszcze nie działa

Najuczciwsza sekcja, i dłuższa, niż byśmy chcieli.

Sekcja odpowiedzi na pytania w dzienniku wciąż jest pusta. Ingest zadziałał sześć razy, audyt czytający raz, Query zero razy. Dopóki tak jest, mamy nie wiki w sensie gistu, lecz dobrze zorganizowaną dokumentację projektu, która kumuluje się wyłącznie ze zmian. Powód jest oczywisty: ingest jest wbudowany w obowiązkowy rytuał zamykania zadania, a zapisanie odpowiedzi to osobna decyzja, którą trzeba podjąć dokładnie w chwili, gdy pytanie jest już odpowiedziane i chce się iść dalej. Rytuał wygrywa z intencją — potrzebny jest więc rytuał, a nie przypomnienie.

Migracja zatrzyma się nie dlatego, że się skończyła. W CLAUDE.md zostało 52 484 słowa, a najcięższe punkty są już na zewnątrz. Dalej każde kolejne przeniesienie daje coraz mniej przy tym samym koszcie, a reguła „przenosi ten, kto dotyka” oznacza, że funkcjonalności, których nikt nie dotyka, nie przeprowadzą się nigdy. Możliwe, że tak właśnie jest słusznie — ale wtedy resztę trzeba uczciwie nazwać „tym, co żyje w schemacie”, a nie „kolejką migracji”, bo inaczej latami będziemy liczyć jako niedokończone to, czego postanowiliśmy nie robić.

Oba skrypty widzą mniej, niż się wydaje. Kontrola ścieżek działa tylko na ścieżkach zakotwiczonych w katalogu głównym repozytorium, a strony zgodnie z prawem cytują ścieżki względem własnej aplikacji — takie cytaty nie są sprawdzane w ogóle. To świadomy kompromis: kontroler, który zgaduje katalog bazowy, produkuje znaleziska, którym przestaje się ufać, a to gorsze niż wąski kontroler, który zawsze ma rację. Ceną jest jednak to, że część odsyłaczy pozostaje poza kontrolą. Raport o dezaktualizacji pozostaje tymczasem przybliżeniem opartym na commitach: nie wie, czy zmieniła się treść, a trzy commity kosmetyczne wyglądają dla niego tak samo jak trzy, które zepsuły opisany mechanizm.

Koncentratory są prawie nieprzeczytane. Jest ich piętnaście, napisano je w maju, a audyt czytający dotarł do dwóch. Następny cel jest już wskazany w dzienniku — strona API, której schemat bazy danych ma 46 commitów od ostatniej edycji strony. Dopóki koncentratory nie zostaną przeczytane przeciwko kodowi, najwyższy poziom nawigacji pozostaje dokładnie tym artefaktem, który raz już skłamał.

Plik trendów zdrowia zaprojektowano jako szereg czasowy i zawiera jeden punkt z 14 maja. Dopóki cotygodniowy raport wychodzi komentarzem do zgłoszenia, trend nie ma się fizycznie gdzie kumulować. A to, czy wiki żyje, czy umiera, pokazuje właśnie trend, a nie pojedynczy zrzut: jeden tydzień z pięcioma znaleziskami nie znaczy nic, pięć tygodni z rosnącą liczbą znaczy wszystko.

I najważniejsze: nie wiemy, ile to oszczędza. Mamy osobny model kosztu agenta i pokazuje on, że waga kontekstu jest jedną z większych pozycji rachunku. Ale 104 tysiące tokenów na starcie sesji opisuje to, co było, a nie to, co jest: ile agent czyta teraz, nie zmierzyliśmy ani razu. Uczciwa odpowiedź na pytanie „co to dało w pieniądzach” brzmi dziś: nie wiemy, i jest to przedmiot pomiaru, a nie zgadywania. Pomiar nie jest trudny: średnia objętość przeczytanego na sesję, przed i po, na porównywalnych zadaniach. Jeszcze go nie zrobiliśmy, a do tego czasu każda liczba oszczędności w tym artykule byłaby zmyślona.

Jak powtórzyć to u siebie w jeden wieczór

Wklej gist własnemu agentowi i poproś o zinstancjonowanie wzorca pod twoje repozytorium — dokument jest napisany dokładnie po to. Jest celowo abstrakcyjny i kończy się zdaniem, że jego jedynym zadaniem jest przekazanie wzorca, a resztę agent wymyśli sam.

Dalej cztery rzeczy, z których każda okazała się u nas obowiązkowa.

Zadeklaruj schemat w pliku, który agent czyta zawsze. Bez wskaźnika do indeksu w pierwszych liniach świeża sesja nigdy się nie dowie, że wiki istnieje, i będzie dopisywać do starego pliku. Zapisaliśmy to w dzienniku osobnym wierszem w dniu uruchomienia, bo to jedyna część układu, której nie można odłożyć.

Ustal jeden szablon strony i umieść w nim sekcję niezmienników. Całą resztę szablonu można zmienić później; niezmienniki to powód, dla którego ktokolwiek otwiera stronę przed edycją kodu.

Przypnij ingest do rytuału, który i tak jest obowiązkowy. U nas to zamknięcie zadania: zgłoszenie, strona, jeden wiersz w dzienniku. Rytuał, o którym trzeba pamiętać, nie jest wykonywany.

Postaw tani lint, zanim uzbiera się dużo stron. Kilkaset linii Pythona, bez modelu, uruchamiane co tydzień. Nie znajdzie sprzeczności, ale znajdzie martwe linki i sieroty — czyli dokładnie te defekty, których pojedynczo nikt nie zauważa, dopóki nie będzie ich trzydziestu.

I jedno ostrzeżenie na koniec. Moment, w którym wiki zaczyna kłamać, wygląda dokładnie jak moment, w którym wszystko jest w porządku: strony są, linki działają, agent odpowiada pewnie. Jedyna różnica polega na tym, czy ktokolwiek przeczytał te strony przeciwko kodowi w ciągu ostatnich czterech miesięcy.

Podsumowanie

Wzorzec Karpathy’ego nie rozwiązuje problemu wyszukiwania, tylko problem kumulacji: wiedza jest kompilowana raz i utrzymywana, zamiast być wyprowadzana od nowa przy każdym pytaniu. Wewnątrz repozytorium zamienia się to w prostą przestawkę — główny plik agenta staje się schematem, wiedza przenosi się na strony, a trzy operacje stają się trzema rytuałami.

U nas pierwszy dzień oznaczał 24 616 słów mniej w pliku wczytywanym w każdej sesji i siedemnaście stron funkcjonalności zamiast punktów listy. Nie dał jak dotąd niczego z drugiej operacji: ani jednej odpowiedzi na pytanie odłożonej z powrotem do wiki. I nie dał żadnej zmierzonej liczby oszczędności — bo jej nie zmierzyliśmy.

Jeśli z tego artykułu warto wynieść jedną myśl, to tę: artefakt prawie nigdy nie jest winny. Poprzednia wiki była dobrze napisana i kłamała przez cztery miesiące, bo nie miała pętli. Wartość wzorca leży nie w układzie plików, lecz w tym, że czyni utrzymanie na tyle tanim, żeby pętla w ogóle mogła zaistnieć.