Die eine Zeile in Karpathys Wiki Gist, die 99% aller Entwickler übersehen haben — und warum sie der Schlüssel zu allem ist

Wir haben alle schon vor langer Zeit verstanden, worum es bei einem zweiten Gehirn geht. Kurse, Bücher, PDFs, Notizen an einem Ort sammeln, wo man sie auch tatsächlich wiederfindet. Das Konzept gibt es seit zehn Jahren, es ist durchgekaut, viele haben es versucht. Das Problem war nie die Idee. Das Problem ist die Wartung. Du fütterst dein System drei Monate lang, hast am Ende hundertfünfzig Dateien, verlierst dich darin, verbringst mehr Zeit mit Reorganisieren als mit Hinzufügen. Nach sechs Monaten liegt das Gehirn in irgendeiner Ecke deiner Festplatte und du rührst es nie wieder an.

Karpathy hat vor zwei Wochen einen Gist gepostet, der genau das löst. Er fügt eine Auto-Organisationsschicht darüber: das System ordnet seine eigenen Seiten ein, verschmilzt Redundanzen, hält sich selbst kohärent. Diese Woche haben alle angefangen, es nachzubauen. Drei Ordner, eine CLAUDE.md, Obsidian obendrauf. Tutorials überall.

Nur eine Sache ist 99% der Nachbauer entgangen. Und das ist schade, denn das ist der ganze Punkt. Ohne sie hast du einen Ordner, der sich selbst aufräumt. Mit ihr hast du ein Gehirn, das aus jeder Frage lernt, die du ihm stellst, liest was deine Tools hineinschreiben, und irgendwann anfängt, die Tools zu bauen, die es braucht.

Die Wissensbasis, die ich bereits hatte (und nie voll ausgeschöpft habe)

Ich habe vor sechs Monaten nicht bei null angefangen. Wie die meisten Devs, die das schon länger machen, hatte ich bereits Repos auf meiner Festplatte verstreut, wo ich Wissen, Skills, Prozesse, Tools, Docs organisiert hatte. Ein Ordner pro Bereich. Markdown-Dateien sorgfältig strukturiert. SEO-Notizen hier, Code-Review-Patterns da, Snippets die ich immer wieder verwendet habe, Architekturentscheidungen die ich nicht vergessen wollte. Docker-Compose-Rezepte, die ich mindestens dreimal neu geschrieben hatte, weil ich die vorherige Version nie finden konnte. Infra-Diagramme. Deploy-Checklisten. Incident-Post-Mortems, die ich für mich selbst geschrieben und nie wieder gelesen hatte. Ich nutzte diese Repos täglich, lud sie als Kontext in Claude Code, wenn ich sie brauchte, stellte Fragen dazu, kopierte Regeln in neue Projekte.

Es funktionierte. Es war nützlich. Und wenn du das hier liest, hast du wahrscheinlich dasselbe irgendwo. Das Repo mit Zeug, das du aufgenommen, aufgeräumt, committed hast. Das, bei dem du dich am Sonntagabend gut fühlst, nachdem du eine neue Datei hinzugefügt hast.

Der große Wandel, den Claude brachte, verglichen mit den vorherigen zehn Jahren, war, dass ich aufhörte mich zu fragen "wo zum Teufel habe ich das nochmal hingepackt." Ein Jahrzehnt lang war der Flaschenhals jeder persönlichen Wissensbasis derselbe: du hattest die Information irgendwo, erinnertest dich vage daran, sie aufgeschrieben zu haben, aber sie zu finden bedeutete grep, Spotlight, drei Ordner öffnen, eine halbe Datei nochmal lesen um zu prüfen, ob es die richtige war. Jetzt frage ich einfach Claude. Das Repo ist im Kontext, die Frage wird beantwortet, fertig. Das allein war ein riesiger Durchbruch. Es machte das Repo zum ersten Mal tatsächlich nutzbar.

Aber ich schöpfte es immer noch schlecht aus. Sehr schlecht. Mein Repo war eine sehr gut organisierte Bibliothek, durch die ich jedes Mal selbst laufen musste, wenn ich ein Buch aus dem Regal ziehen wollte (außer dass jetzt Claude für mich lief statt ich). Besser, schneller, aber immer noch einseitig. Ich fragte, es antwortete, das Gespräch endete. Das Repo lernte nichts davon. Morgen würde ich eine verwandte Frage stellen, Claude würde dasselbe Regal nochmal ablaufen, mir eine leicht andere Antwort geben, und diese zweite Antwort würde auch wieder verpuffen.

Ich denke, deshalb hat Karpathys Gist so hart eingeschlagen, als er ihn veröffentlichte. Es war nicht die Architektur. Viele von uns hatten bereits etwas Ähnliches. Der Gist gab einem vagen Gefühl einen Namen, mit dem die meisten von uns monatelang gesessen hatten: dieses Ding, das ich gebaut habe, ist nützlich, aber es macht offensichtlich nicht das, was es machen könnte. Das fehlende Stück war die Auto-Organisationsschicht. Ein zweites Gehirn, das seine eigenen Seiten einordnet, seine eigenen Redundanzen verschmilzt, seine eigene Kohärenz aufrechterhält, während du schläfst. Das ist, was Karpathy vor uns hingestellt hat.

Und das ist, was diese Woche alle angefangen haben zu bauen.

Karpathy postete die Architektur. Alle kopierten die falsche Hälfte.

Der Gist heißt llm-wiki. Zwei Ordner, wo es darauf ankommt. raw/ für das Quellmaterial, gefiltert und strukturiert, aber vollständig. Ein kompletter SEO-Kurs destilliert in 900 Zeilen. Ein Coding-Buch kondensiert in 600. Ein Ops-Playbook heruntergebrochen von drei Konferenz-Talks in 700 Zeilen dessen, was tatsächlich auf deinen Stack zutrifft. Das liest niemand in der Produktion. Es ist das Archiv, der Ort, zu dem du zurückgehst, wenn das Wiki etwas sagt, das sich falsch anfühlt und du die Quelle prüfen willst.

wiki/ ist die operative Version. Eine Datei pro Bereich. Verschmilzt jede Raw-Datei in diesem Bereich zu umsetzbaren Regeln. 150 bis 200 Zeilen max. Das ist, was die Agents laden, bevor sie etwas produzieren. Ein Bruchteil der Raw-Größe, und es wartet sich selbst. Füge einen neuen Kurs im selben Bereich hinzu, das Wiki absorbiert die neuen Regeln ohne zu wachsen. Widersprüche werden aufgelöst, veraltete Patterns werden fallen gelassen.

Obendrauf eine CLAUDE.md im Root, die dem Modell sagt, wie es durch das Ganze navigiert, und Obsidian als Frontend, damit du es wie ein normaler Mensch durchstöbern kannst.

Die Architektur ist sauber. Sie ist auch der offensichtliche Teil. Natürlich trennst du Raw von Synthetisiert. Natürlich gibst du dem Modell Navigationsregeln. Natürlich ist Obsidian ein guter Viewer.

Dann kamen die Tutorials. Jeder Tech-YouTuber mit Ringlicht postete diese Woche Variationen desselben Diagramms. Drei Ordner. CLAUDE.md. Obsidian. Bau es wie Karpathy. Ship einen Screenshot. Weiter.

Ich war zwei Tage lang Teil dieser Welle. Baute die Struktur über mein bestehendes Repo. Nahm mehr Quellen auf. Stellte Fragen. Das Setup war besser als das, was ich hatte, schneller, dichter. Aber die Basis saß immer noch da und wuchs nur, wenn ich ihr manuell neue Sachen fütterte. Die Auto-Organisationsschicht machte ihren Job mit dem, was ich hineintat. Sie machte nichts mit dem, was ich mit der Basis danach tat.

Da ging ich zurück zum Gist und las ihn langsamer. Nicht den Architektur-Abschnitt. Den Query-Abschnitt. Den Teil, der sagt, was nach der Antwort des Modells passiert.

Der eine Satz, der ein statisches Archiv in eine lebende Basis verwandelt

Der Satz, aus Karpathys eigenem Post über den Workflow:

"Often, I end up filing the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always add up in the knowledge base."

Lies ihn zweimal. Er beschreibt ein Verhalten, keine Architektur.

Was er klar sagt: wenn du eine Frage stellst und das Modell dir eine nützliche Antwort gibt, geht diese Antwort zurück ins Wiki als neue Seite. Die nächste Query zum selben oder angrenzenden Thema startet von einer Basis, die bereits die vorherige Antwort enthält. Die Basis wächst durch deine Nutzung, nicht nur durch deine Aufnahme.

Ohne diese Schleife ist dein Repo ein RAG mit hübscheren Ordnern. Du nimmst auf, du fragst, die Antwort blitzt auf deinem Bildschirm auf und stirbt in der Chat-Historie. Morgen stellst du eine ähnliche Frage, das Modell holt aus denselben Quellseiten, synthetisiert dieselbe Antwort von Grund auf neu. Du bezahlst jedes einzelne Mal für die Synthese (ehrlich gesagt meine Lieblings-Form von wiederkehrender Verschwendung).

Mit der Schleife ist die Basis zustandsbehaftet. Der Job des Modells verschiebt sich von "aus Rohquellen synthetisieren" zu "die Seite finden, wo das bereits beantwortet ist, bei Bedarf verfeinern." Schneller, billiger, dichter über die Zeit.

Ein Absatz im Gist. Der ganze Grund, das zu bauen.

Was ein toter Container meiner Wissensbasis beibrachte

Mein Repo hält nicht nur Kurse und Bücher. Es hält auch die lebende Dokumentation meiner eigenen Services: Configs, Deploy-Notizen, vergangene Incidents, Architekturentscheidungen, die ich um 2 Uhr nachts getroffen und aufgeschrieben hatte, bevor ich vergaß warum. Dasselbe Pattern wie der Rest, raw/ mit der vollständigen Historie, wiki/ mit den operativen Regeln. Hier wurde es interessant.

Mein Distributor-Katalog-Sync stoppte. Der Container war oben, der Prozess lebte, aber er hatte 34 Stunden lang keinen neuen Feed gezogen. Ich bemerkte es, weil die Partner-seitige Produktanzahl von dem abwich, was auf meiner Storefront war. Kunden bestellten Sachen, die upstream nicht mehr auf Lager waren.

Ich öffnete Claude Code und fragte: "was ist der Zustand des Distributor-Syncs, wann lief er zuletzt erfolgreich, und was ist die wahrscheinlichste Ursache der Stille?" Das Modell ging durch das Wiki, zog die relevante Service-Seite, prüfte die aktuellen Log-Einträge, die ich aufgenommen hatte, und antwortete: wahrscheinlich ein Memory-Leak im Parser, der Container verbraucht RAM aber crasht nicht, weil der OOM-Killer-Threshold zu hoch gesetzt ist. Empfahl einen Neustart und ein Memory-Cap.

Klassische Claude-Code-Antwort. Nützlich. Spezifisch. Wäre in der Chat-Historie gestorben.

Außer die Schleife war aktiviert. Die Antwort wurde zurück ins Wiki eingeordnet als neue Seite unter services/distributor-sync/incidents/2026-03-29-silent-failure.md. Die Seite hatte das Symptom, die Diagnose, die Lösung, und einen Flag, der notierte, dass dieser Service jetzt einmal still versagt hatte. Gesamtkosten: eine Query, eine eingeordnete Seite.

Eine Woche später stellte ich eine unverwandte Frage über den Partner-API-Webhook. Das Modell antwortete, dann fügte die höfliche Version von "übrigens, du solltest dir das mal ansehen" hinzu: "beachte, dass dein Distributor-Sync vor 6 Tagen einen stillen Ausfall hatte, du hast derzeit kein Monitoring auf seinen Heartbeat, du solltest eins hinzufügen, bevor das nochmal passiert." Es brachte das von selbst auf, weil das Wiki die Incident-Seite hatte, und das Modell sie gelesen hatte, während es nach Kontext für angrenzende Services suchte.

Eine Woche früher wäre diese Information weg gewesen. Die Chat-Session, in der ich es diagnostiziert hatte, wäre geschlossen gewesen. Das nächste Mal, wenn der Sync still stirbt, hätte ich dieselbe Grundursache von Grund auf neu entdeckt.

Das Wiki erinnerte sich nicht nur. Es verknüpfte.

Der dritte Kanal: Wenn deine Tools die Basis füttern, und die Basis ihre eigenen Tools baut

Hier ist das, was mich an dem obigen Incident störte. Ich erfuhr, dass der Container still versagt hatte, durch Zufall, weil Kunden sich zu beschweren begannen. Claude ordnete die Seite erst ein, nachdem ich fragte. Wenn ich nicht gefragt hätte, hätte der Incident nie in der Basis existiert.

Was, wenn der Container selbst die Seite einordnet?

Karpathys Schleife ist menschengetrieben. Du fragst, das Modell antwortet, die Antwort wird eingeordnet. Zwei Kanäle füttern die Basis: Dokumente, die du manuell aufnimmst, und Queries, die du ausführst. Es gibt einen dritten Kanal. Er ist nicht im Gist.

Deine Infrastruktur produziert bereits kontinuierlich Signal. Cron-Jobs gelingen oder scheitern. Container starten neu. Services laufen in Timeouts. Webhook-Callbacks geben Non-200-Codes zurück. Das meiste dieses Signals geht in Logs, die niemand liest, oder in Alerting-Systeme, die einmal feuern und vergessen. Nichts davon landet irgendwo, wo das Modell es nutzen kann.

Was ich über Karpathys Pattern gebaut habe, ist eine dünne Schicht, die der Infra selbst erlaubt, Seiten einzuordnen. Ein CLI, das jeder Service aufrufen kann, um eine Beobachtung direkt in die Basis zu schreiben. Der Katalog-Sync schreibt eine Seite, wenn er gelingt, mit der Zeilenanzahl. Der Webhook-Handler schreibt eine Seite, wenn er eine malformierte Payload sieht. Ein Cron schreibt eine Seite, wenn er überspringt, weil der vorherige Lauf noch lief. Kurze Seiten. Mit Zeitstempel. Sie landen in einem signals/-Ordner, von dem das Modell weiß.

Der Grund, warum das funktioniert, ist derselbe Grund, warum CLIs bessere Signal-Kanäle sind als MCP-Wrapper für jede Agent-Aufgabe: ein curl-Einzeiler aus einem Bash-Script schreibt ins Wiki, keine Protokoll-Verhandlung, kein Schema-Tanz. Der Container muss nicht wissen, was ein LLM ist. Er hängt nur eine Markdown-Datei an einen Ordner an.

Und dann begann das Second-Order-Ding zu passieren.

Sobald genug Signal akkumuliert war, begann das Modell, den signals/-Ordner während Queries zu lesen und auf Lücken hinzuweisen. Nicht "dein Container ist versagt" (das war erwartet). Sachen wie: "du hast drei Services, die Erfolgs-Seiten schreiben, aber keine Fehler-Seiten für den Webhook-Handler, was bedeutet, ich kann nicht sagen, ob er funktioniert oder nur still ist. Du solltest einen Failure-Emitter in diesem Handler hinzufügen." Oder: "dein Cron-Job für Distributor-Sync schreibt, wenn er läuft, aber nichts schreibt, wenn er einen Zyklus überspringt. Du brauchst einen Skip-Emitter."

Dann hörte es auf zu fragen. Es begann zu bauen.

Ein konkretes Beispiel von letzter Woche, und nicht mal ein Infra-Beispiel. Ich überlegte, ob ich 32 oder 48 GB RAM auf meinem nächsten MacBook kaufen sollte. Klassische Frage, klassische Antwort vom Typ im Apple Store: "24 reichen dir, vertrau mir." Ich vertraute ihm nicht. Ich fragte stattdessen Claude Code, mit meinem Repo im Kontext: "woher weiß ich, was ich tatsächlich brauche?" Das Modell gab mir keinen Richtwert. Es schlug vor, ein Monitoring-CLI zu bauen (ein Script, um alle 5 Minuten RAM-Metriken in ein CSV zu sampeln, ein zweites Script, um die Zusammenfassung zu berechnen und eine Größe basierend auf dem beobachteten Peak plus 30% Marge zu empfehlen). Schrieb beide Scripts. Führte sie aus. Drei Tage Daten später war das Urteil in meinem Wiki: RAM-Nutzung war bei 22 bis 23 GB auf einer 24-GB-Maschine festgenagelt, 77 MB frei am Tiefpunkt, Compressor arbeitete Überstunden bei 4,5 GB. Empfehlung: 32 minimum, 48 wenn ich Seelenfrieden wollte.

Keine Vermutung. Kein Marketing. Tatsächliche Zahlen von meiner tatsächlichen Nutzung, gesammelt von Tools, die die Basis für sich selbst baute, weil sie wusste, dass sie die Antwort noch nicht hatte.

Die Basis lernte nicht nur. Sie schloss ihre eigenen blinden Flecken.

Du nimmst auf. Du fragst. Deine Tools schreiben. Und dann baut die Basis das nächste Tool von selbst.

Drei Fallen, bevor du die Schleife aktivierst

Drei Fallen, in die ich in den ersten zwei Wochen gelaufen bin. Triff diese Entscheidungen, bevor du den Schalter umlegst, oder deine Basis wird schnell zu einem Müllcontainer.

Was zurückgeordnet wird. Ich begann damit, jede Antwort einzuordnen. Nach vier Tagen hatte die Basis siebenundvierzig Variationen von "ja, dieser Docker-Befehl ist korrekt" und ich konnte nichts Nützliches finden. Die Regel jetzt: ordne nur zurück ein, wenn die Antwort etwas offenbart, was die Basis noch nicht wusste, einen Incident dokumentiert, oder eine Entscheidung explizit macht. Gesprächsgerüst stirbt in der Chat-Historie, wo es hingehört.

Wer über Qualität entscheidet. Selbst-beurteilende Modelle sind zu großzügig mit sich selbst, das entdeckte ich schnell, als Claude eine Seite einordnete, die einen veralteten API-Endpoint als "aktuelle Best Practice" deklarierte. Vollständige menschliche Überprüfung skaliert nicht über hundert Seiten hinaus. Ich landete bei einem Mittelweg: das Modell ordnet in pending/ ein, ein täglicher Cron befördert alles, was ich nicht innerhalb von 24 Stunden gelöscht habe. Schweigen bedeutet Zustimmung. Faulheit ist das Tor.

Wie du Fehler daran hinderst, sich zu verstärken. Das lernte ich aus den Gist-Kommentaren, nicht von Karpathy. Wenn das Modell eine falsche Antwort einordnet, wird diese falsche Antwort zu einem "Fakt" in der Basis. Die nächste Query liest sie, behandelt sie als Grundwahrheit, produziert eine zweite falsche Antwort, die von der ersten abhängt. Drei Wochen später gaslightet dich deine Basis. Der Fix ist dieselbe Art von Vertrag, die ich in meinem Prompt-Contracts-Framework beschrieben habe: jede eingeordnete Seite deklariert ihre Quellen, ein Vertrauenslevel, ein Re-Validierungsdatum. Keine Quellen, schneller Ablauf. Hohes Vertrauen mit verifizierten Quellen, langes Leben. Die Basis beschneidet sich selbst.

Nagle diese drei fest. Der Rest läuft von selbst.

30 Tage später: Zwei Basen, zwei verschiedene Systeme

In 30 Tagen werden viele Devs exakt dasselbe Setup gebaut haben. Drei Ordner, eine CLAUDE.md, Obsidian obendrauf. Identisch bis zu den Ordnernamen.

Die Hälfte von ihnen wird ein totes Archiv haben, das handfüttert werden muss, um relevant zu bleiben (was ehrlich gesagt innerhalb eines Monats vergessen wird, seien wir real). Die andere Hälfte wird eine Basis haben, die aus jeder Frage lernt, liest was die Infra hineinschreibt, und die Tools baut, die sie braucht, wenn sie eine Lücke bemerkt. Dieselbe Architektur. Eine Schleife und ein Kanal Unterschied.

So sieht eine echte persönliche Wissensbasis aus. Kein Ordner. Ein System, das bei jeder Nutzung dichter wird, und schärfer jedes Mal, wenn es auf etwas trifft, was es nicht weiß.

Karpathy schrieb die Zeile. Niemand las sie.

Quellen

• Andrej Karpathys llm-wiki Gist auf GitHub

(*) Das Titelbild wurde von einer AI generiert, die fairerweise schon ihre eigenen Seiten einordnet, seit bevor wir es zu einem Hobby machten.