Von Karpathys LLM-Wiki zum funktionierenden Second Brain: Meine Umsetzung mit Amazon Quick Desktop

Dima Kramskoy — Senior Cloud Architect bei DoiT International 20+ Jahre Softwareentwicklung · 10 AWS-Zertifizierungen · AWS Community Builder 2026 · Alumni der Architect Master Class von Juval Löwy (2022)

Das Problem: Jedes Gespräch beginnt bei null

Es gibt da ein Anti-Pattern, das mich wahnsinnig macht: Sie führen ein 45-minütiges Tiefengespräch mit einem KI-Assistenten über Ihre Architekturentscheidungen, Trade-offs und Constraints. Sie schließen den Tab. Am nächsten Tag öffnen Sie einen neuen Chat. Er weiß nichts mehr. Und Sie fangen wieder beim Onboarding an.

Multiplizieren Sie das mit Ihrer gesamten Wissenslandschaft: Slack-Threads mit Kontext, der nie wieder auffindbar sein wird, E-Mail-Ketten, in denen Entscheidungen in Antwort #14 versanden, Dokumente, die in drei Versionen auf zwei Drives liegen, und implizites Wissen, das ausschließlich in den Köpfen einzelner Personen steckt.

Niemand würde seine Nachfolge allein anhand des eigenen Slack-Verlaufs einarbeiten wollen. Aber genau das tun wir faktisch mit unseren KI-Tools — wir geben ihnen Fragmente und erwarten ein kohärentes Bild.

Das Kernproblem ist nicht die Intelligenz. GPT-4, Claude, Gemini — sie sind alle brillant. Das Problem ist Amnesie. Jede Session ist ein Kaltstart. Ihr Kontext verteilt sich auf ein Dutzend Tools, und keines davon kennt ein einheitliches Modell von Ihnen und Ihrer Arbeit.

Ich denke seit Monaten darüber nach. Dann hat Karpathy einen Tweet gepostet, der die Lösung auf den Punkt gebracht hat.

Karpathys Inspiration: RAG ruft ab, ein Wiki wächst

Im April 2026 hat Andrej Karpathy auf X über "das LLM-Wiki" gepostet — 17 Millionen Aufrufe, Tendenz steigend. Die Kernidee saß bei mir sofort, wie ein Design-Pattern, das endlich einrastet:

"RAG retrieves. A wiki compounds."

Sein Konzept ist elegant. Drei Schichten:

1. Raw Sources — Artikel, Papers, Tweets, Gespräche, Notizen
2. Wiki — destillierte, strukturierte, miteinander verknüpfte Wissensseiten
3. Schema — die Ontologie, die festlegt, wie Wissen organisiert wird

Seine Analogie sitzt: "Obsidian ist die IDE. Das LLM ist der Programmierer. Das Wiki ist die Codebase."

Matt Paige hat das Konzept in einer exzellenten Analyse aufgeschlüsselt. Der entscheidende Perspektivwechsel: Statt rohe Dokumente in eine Vektordatenbank zu kippen und zu hoffen, dass das Retrieval den richtigen Chunk findet, baut man eine lebendige, strukturierte Wissensbasis, die das LLM über die Zeit pflegt und anreichert.

RAG ist ein Lookup. Ein Wiki ist ein System. Das eine läuft O(1) pro Abfrage. Das andere wächst kumulativ.

Aber eines hat mich an Karpathys Version gestört: Sie ist manuell. Sie sind der Operator. Sie prompten, reviewen, fügen ein, organisieren. Das LLM assistiert, aber Sie steuern. Ich wollte etwas anderes — einen Assistenten, der das für mich übernimmt, kein System, das ich selbst pflegen muss.

Warum Amazon Quick Desktop

Bei der Tool-Auswahl für diese Umsetzung hatte ich eine Checkliste, die direkt aus Karpathys Architektur abgeleitet war:

• ✅ Langzeitgedächtnis, das über Gespräche hinweg erhalten bleibt
• ✅ Knowledge Graph (extrahiert automatisch Entitäten und Beziehungen aus Slack, E-Mail, Kalender)
• ✅ Semantische Suche über lokale Dateien
• ✅ Lese- und Schreibzugriff auf mein Dateisystem
• ✅ Hintergrundaufgaben (recherchiert, während ich an anderen Dingen arbeite)
• ✅ Verbundene Tools (Gmail, Slack, Google Calendar, MCP-Server)
• ✅ Action Layer (kann E-Mails entwerfen, Docs erstellen, Meetings buchen)

Amazon Quick Desktop hatte bereits alles, was Karpathy beschreibt — eingebaut und mit echten Arbeitstools verbunden. Es ist kein Chat-Fenster. Es ist eine Runtime.

Kurzer Vergleich:

Die entscheidende Weichenstellung: Ich wollte einen Assistenten, der Wissen FÜR mich kumuliert — kein System, das ich selbst pflegen muss. Der Pflegeaufwand eines manuellen Wikis killt jede Adoption. Ich habe das ein Dutzend Mal erlebt.

Was ich gebaut habe (in 1 Woche)

Ordnerstruktur

~/SecondBrain/
├── raw/                          # Unverarbeitete Inputs
│   ├── articles/
│   ├── transcripts/
│   └── captures/
├── wiki/                         # Destilliertes Wissen
│   ├── concepts/                 # Mentale Modelle, Frameworks
│   │   ├── second-brain-architecture.md
│   │   ├── rag-vs-wiki-pattern.md
│   │   └── approval-workflow-pattern.md
│   ├── entities/                 # Personen, Organisationen, Tools
│   │   ├── doit-international.md
│   │   └── amazon-quick.md
│   ├── projects/                 # Laufende Arbeit
│   │   ├── genai-skill-share-talk.md
│   │   └── voice-capture-pipeline.md
│   ├── sources/                  # Indexierte Referenzen
│   │   └── karpathy-llm-wiki.md
│   └── log/                      # Tägliches Output-Tracking
│       ├── 2026-05-19.md
│       ├── 2026-05-20.md
│       └── ...
├── SCHEMA.md                     # Die Ontologie
└── mkdocs.yml                    # Automatisch ausgelieferte Dokumentation

SCHEMA.md (Auszug)

# SecondBrain Schema v1.0

## Seitentypen
- **concept**: Ein mentales Modell, Pattern oder Framework. Pflichtangaben: Definition, Einsatzkontext, Anti-Patterns, verwandte Konzepte.
- **entity**: Eine Person, Organisation oder ein Tool. Pflichtangaben: Rolle/Zweck, Bezug zu meiner Arbeit, Datum der letzten Interaktion.
- **project**: Laufende oder abgeschlossene Arbeit. Pflichtangaben: Status, Stakeholder, Entscheidungsprotokoll, nächste Schritte.
- **source**: Ein aufgenommener Artikel/Talk/Paper. Pflichtangaben: URL, Kernerkenntnisse (max. 5), Verbindung zu bestehenden Konzepten.
- **log**: Tageseintrag. Automatisch generiert. Erfasst: erstellte Seiten, aktualisierte Seiten, beantwortete Fragen, ausgeführte Aktionen.

## Namenskonvention
kebab-case. Keine Datumsangaben in Dateinamen (das gehört ins Frontmatter).

## Querverweis-Regeln
Jede neue Seite MUSS auf mindestens eine bestehende Seite verlinken. Verwaiste Seiten sind ein Warnsignal.

Der Stack

• MkDocs + Material Theme — liefert das Wiki automatisch lokal unter localhost:8000 aus
• launchd plist — startet MkDocs beim Login (macOS). Null Reibung beim Aufrufen.
• Amazon Quick — liest und schreibt das Wiki, schlägt Updates vor, beantwortet Fragen daraus
• Semantische Indexierung — Quick indexiert ~/SecondBrain/ und durchsucht es kontextbezogen

Der Approval-Workflow

Das ist entscheidend. Nichts wird ohne mein OK geschrieben. Der Ablauf:

1. Ich sage "ingest this article" oder teile einen Link
2. Quick liest ihn und schlägt eine neue Wiki-Seite vor (oder Updates an bestehenden)
3. Ich sehe den Diff — neue Inhalte hervorgehoben, Querverweise angezeigt
4. Ich genehmige, ändere oder lehne ab
5. Genehmigte Inhalte werden auf die Platte geschrieben, MkDocs aktualisiert sich automatisch

15+ Wiki-Seiten in der ersten Woche. Nicht durch Schinderei — aus Gesprächen, die ich ohnehin geführt habe.

Ein Tag im Leben

Morgens:

"Guten Morgen"

Quick antwortet mit: priorisierten E-Mails (markiert oder von Schlüsselpersonen), Slack-Threads, die meine Antwort brauchen, dem heutigen Kalender mit Vorbereitungsnotizen zu den Meetings. Kein Informationsschwall — ein Briefing.

Tagsüber:

"Ingest this: [Link zu Architektur-Blogpost]"

Quick liest den Beitrag, identifiziert 3 Kernkonzepte, schlägt eine neue sources/-Seite und Updates an zwei bestehenden concepts/-Seiten vor. Ich überfliege den Diff, genehmige, fertig. 90 Sekunden.

"Entwirf einen Blogpost über die Second-Brain-Umsetzung"

Quick zieht aus meinen Wiki-Seiten, kennt meinen Stil (aus dem Gedächtnis früherer Texte) und strukturiert den Beitrag in meinem bevorzugten Format. Ich bearbeite, ich schreibe nicht bei null los.

"Blockiere morgen 2 Stunden für Deep Work an der Voice-Capture-Pipeline"

Prüft meinen Kalender, findet einen Slot, bucht ihn und ergänzt Vorbereitungsnotizen aus der Seite projects/voice-capture-pipeline.md.

Im Hintergrund:

Während ich in Meetings bin, recherchieren Hintergrundaufgaben Themen, die ich zuvor eingereiht habe. Wenn ich zurückkomme: "Ich habe 3 relevante Papers zur Pflege von Knowledge Graphs gefunden. Soll ich sie aufnehmen?"

Der kumulative Effekt ist real. Ab Tag 5 hat es Fragen beantwortet, indem es über mehrere Wiki-Seiten hinweg synthetisiert hat — Seiten, deren Genehmigung ich längst vergessen hatte.

Die Voice-Capture-Erweiterung (PoC)

Die besten Ideen kommen beim Gehen, nicht am Schreibtisch. Also habe ich eine Pipeline gebaut:

Architektur

iPhone Shortcuts (oder Plaud NotePin Wearable)
    → API Gateway (REST)
        → Lambda (Upload-Handler)
            → S3 (Audio-Bucket)
                → S3 Event → Lambda (Transkriptions-Trigger)
                    → AWS Transcribe
                        → Lambda (Nachverarbeitung)
                            → Amazon Quick Knowledge Base
                                → Wiki-Seite vorgeschlagen

So funktioniert es

1. Ich tippe einen Shortcut auf meinem iPhone an (oder der NotePin nimmt Umgebungsaudio auf)
2. Audio wird über API Gateway + Lambda nach S3 hochgeladen
3. Ein S3-Event triggert die Transkription über AWS Transcribe
4. Das Transkript wird bereinigt, in Chunks zerlegt und in die Knowledge Base von Quick gepusht
5. Beim nächsten Öffnen von Quick: "Du hattest eine Sprachaufnahme zum Thema [Thema]. Soll ich eine Wiki-Seite erstellen?"

AWS-Gesamtkosten: Bruchteile eines Cents pro Aufnahme. Die Lambda-Funktionen sind trivial — je 50 Zeilen. Der eigentliche Wert liegt im Schließen der Schleife: Gedanke → Aufnahme → strukturiertes Wissen → handlungsfähig.

Ehrliche Bewertung: 7/10

Was funktioniert

• Struktur — Das Schema erzwingt Konsistenz. Seiten sind auffindbar und nützlich.
• Kumulierung — Antworten in Woche 2 sind spürbar besser als in Woche 1. Das System weiß Dinge.
• Verbundene Tools — Slack-Kontext reichert Wiki-Seiten an. Kalenderkenntnis ermöglicht echte Terminplanung.
• Action Layer — Es weiß nicht nur Dinge, es tut Dinge. Entwürfe, Slides, Buchungen.
• Semantische Suche — "Was hatte ich zu X entschieden?" funktioniert tatsächlich über das gesamte Wiki.

Wo es noch hakt

• Querverweise — Noch nicht vollständig automatisch. Manche Seiten bleiben zu schwach verlinkt.
• Health Checks — Geplante Audits für veraltete oder verwaiste Seiten habe ich noch nicht implementiert.
• Geplante Aufnahme — Kein Cron für "prüfe diese 5 RSS-Feeds täglich". Noch alles manuell.
• Widerspruchserkennung — Ungetestet. Was passiert, wenn neue Infos bestehenden Wiki-Seiten widersprechen?

Was wir BESSER gemacht haben als Karpathys ursprüngliche Vision

Seine Vision ist der Bauplan. Aber sie ist read-only — Dateien, die man abfragt. Meine produziert: entwirft E-Mails, erstellt Slides, bucht Meetings, schreibt Blogposts. Das Wiki ist nicht nur Nachschlagewerk; es ist eine Handlungsquelle.

So können Sie starten (5 Schritte)

Sie brauchen mein komplettes Setup nicht, um daraus Nutzen zu ziehen. Hier die Abstufung:

Die 5 Schritte

1. Verbinden Sie Ihre Tools — Slack, Gmail, Kalender, ein lokaler Ordner. Das sind 10 Minuten in den Einstellungen.
2. Reden Sie einfach los — Das Gedächtnis wächst ab Tag 1. Jedes Gespräch lernt etwas über Sie dazu.
3. Sagen Sie nach wichtigen Gesprächen "remember this" — explizite Gedächtnisanker.
4. Legen Sie ~/SecondBrain/ + SCHEMA.md an — Wenn Sie tiefer einsteigen wollen, geben Sie dem System Struktur.
5. Stellen Sie eine Frage, die alles umspannt — "Was waren meine wichtigsten Entscheidungen letzte Woche?" Sie sind drin.

Drei Commitment-Stufen

Starten Sie bei 🟢. Im Ernst. Das Wissen wächst kumulativ, egal ob Sie Infrastruktur bauen oder nicht. Die Wiki-Struktur macht es nur sichtbar und überprüfbar.

Fazit

Ihre KI sollte nicht in jedem Gespräch bei null anfangen.

Die Tools sind da. Das Muster ist erprobt. Karpathy hat die Architektur gezeigt; Amazon Quick liefert die Runtime. Die Lücke zwischen "KI-Assistent" und "Second Brain" besteht nur aus Struktur + Persistenz + verbundenen Tools.

Kumulieren > Abrufen. Jedes Gespräch, jeder aufgenommene Artikel, jede genehmigte Wiki-Seite macht die nächste Interaktion klüger. Das ist kein Retrieval — das ist Wachstum.

Klein anfangen. Es wächst von selbst. Darum geht es.

Ein letzter Gedanke — und der kommt von Jocko Willink, nicht aus der KI-Forschung: Extreme Ownership, angewandt auf Wissen. Wenn eine Information in Ihrer Welt existiert — ein Slack-Thread, ein halb erinnerter Konferenz-Talk, eine Idee auf einem Morgenspaziergang — und Sie sie nicht festhalten, gehört sie Ihnen nicht. Sie besitzt Sie, indem sie genau dann nicht verfügbar ist, wenn Sie sie am dringendsten brauchen.

Festhalten. Strukturieren. Wachsen lassen.

Dieser Beitrag ist mit Hilfe meines Second Brains entstanden — gespeist aus Wiki-Seiten, die ich in der Woche zuvor aufgebaut hatte. Die Ironie ist mir nicht entgangen. Das ist genau der Punkt.

Vorgestellt beim GenAI Community Skill Share von DoiT am 22. Mai 2026. Dank an die rund 27 Kolleginnen und Kollegen, die scharfe Fragen gestellt und das Thema weitergedacht haben.