Blog

RAG bedeutet grob: dem KI-Assistenten eigene Dokumente als Nachschlagewerk geben, damit er aus echten Quellen antwortet statt aus seinem Trainingsgedächtnis. NotebookLM ist Googles Tool dafür – man lädt Texte oder URLs hoch, und es indiziert sie. Der MCP-Wrapper verbindet das mit Claude Code, sodass Claude direkt in NotebookLM suchen kann, ohne den Chat verlassen zu müssen.

Ich habe zwei Wrapper verglichen und mich für jacob-bd/notebooklm-mcp-cli entschieden (Python, 39 Tools). Installation: pip install notebooklm-mcp-cli, dann nlm login (öffnet den Browser für Google-OAuth), dann nlm setup add claude-code – das legt den MCP-Eintrag automatisch in der Claude-Konfiguration an. Nach einem Neustart zeigt /mcp den Server als „connected" mit 39 Tools. Kein manuelles JSON-Editieren nötig.

Der Live-Test: Notebook „LernyTube Dokumentation" angelegt, mein GitHub-Repo als einzige Quelle indiziert. Frage an Claude: „Welche Datenbank nutzt LernyTube?" – Antwort: „MongoDB", mit direktem Zitat auf die Tech-Stack-Tabelle in der README. Kein Raten, kein Halluzinieren – echtes Nachschlagen. Das hat mich ehrlich überrascht, wie schnell das end-to-end lief.

Was der Reddit-Post verschwieg: Mindmaps und Quizzes unterstützt keiner der populären Wrapper. Nur Audio Overviews (das gesprochene Zusammenfassungs-Feature von NotebookLM). Es gibt einen Wrapper mit 20 Stars, der das angeblich kann – aber 20 Stars heißt: kaum jemand hat es ernsthaft getestet. Ich hab's gelassen. Außerdem: Google sieht alles, was hochgeladen wird – also keine sensiblen Geschäftsdaten rein. Und die Auth-Cookies laufen alle zwei bis vier Wochen ab, dann ist ein erneutes nlm login nötig. Kleiner Aufwand, kein Drama, weil das Setup lokal auf meinem Windows-Laptop läuft und nicht auf dem VPS – Browser ist einfach da.

Mein Fazit: Den Hype ignorieren, die Technik selbst prüfen. RAG aus Claude Code heraus funktioniert und ist für mein Lerntempo gerade genau richtig – ich kann Fragen zu eigenem Code stellen, ohne alles im Kontext mitzuschleppen.

Das klingt selbstverständlich, ist es aber nicht. Die meisten Automatisierungen, die ich bisher gebaut habe, tun einfach, was man ihnen sagt – immer, bedingungslos, egal ob es sinnvoll ist. Dieser Agent hat eine Selbstprüfung eingebaut: Er schaut nach Git-Commits, geänderten Dateien, Session-Notizen. Wenn weniger als zwei Commits oder fünf relevante Dateiänderungen vorliegen, schweigt er. Das Tageslimit von drei Posts pro Tag respektiert er ebenfalls – und prüft es aktiv, bevor er weitermacht.

Die eigentliche Arbeit war das Prompt-Design: dem Agenten beizubringen, wann „genug" genug ist, und wie er das Datum auf Deutsch formatiert (das System liefert englische Monatsnamen – eine kleine Falle, in die man leicht tappt). Dazu gehört auch das genaue HTML-Template für die Blog-Karte, damit neue Einträge strukturell zu den alten passen und der Auf/Zuklapp-Mechanismus korrekt funktioniert.

Was ich dabei gelernt habe: Ein Agent wird erst dann nützlich, wenn er auch „Nein" sagen kann. Ein Werkzeug, das immer einen Output produziert, erzeugt Rauschen. Eines, das erst prüft und dann handelt, erzeugt Signal. Dieser Unterschied klingt philosophisch, macht in der Praxis aber den ganzen Unterschied.

Hintergrund: Ich arbeite an meinem Lern-Projekt LernyTube, einer kleinen Plattform, in der ich YouTube-Videos in echten Lern-Sessions strukturiere, Notizen mache und Snapshots setze. Das funktioniert gut – aber am Ende einer Session ist mein Kopf voll, und das Wichtigste verflüchtigt sich, wenn ich es nicht sofort festhalte. Ein freies Tagebuch hilft mir da nicht: zu viel Spielraum, zu wenig Druck zur Verdichtung.

Deshalb gibt es jetzt am Session-Ende einen Lern-Kassenbon. Fünf Felder, mehr nicht: Dauer, Konzentration, was konkret entstanden ist, die eine Erkenntnis, und der nächste Schritt. Der Bon sieht aus wie ein echter Kassenzettel – Monospace-Schrift, Papier-Optik, gezackte Kante. Das ist nicht Deko, sondern Tonfall: Der Stil sagt „kurz, ehrlich, fertig" – und genau so möchte ich nach einer Session reflektieren.

Der spannendste Teil sind die Smart-Defaults: Die Dauer schätzt das System aus dem Abstand zwischen erstem und letztem Snapshot – ich muss nur korrigieren, nicht raten. Die Erkenntnis-Zeile wird mit dem Text der letzten Snapshot-Notiz vorbelegt – meistens ist genau dort schon das Wichtigste formuliert, ich muss es nur bestätigen oder verdichten. Die Hürde, den Bon zu erstellen, ist damit auf zwei Klicks geschrumpft – und genau deshalb wird er auch tatsächlich genutzt.

Was bleibt als Erkenntnis: Verdichtung ist anstrengender und wertvoller als freies Schreiben. „Was bleibt hängen?" in einem Satz ist ein härteres Werkzeug als drei Absätze Tagebuch. Und gute UX-Patterns finde ich nicht in Tech-Blogs, sondern an der Supermarkt-Kasse.

Vier davon sind global, also in jedem Projekt verfügbar: ein Secret-Auditor, der vor jedem Push die gesamte Git-Historie nach Passwörtern und API-Keys durchforstet. Ein Safe-Backup, das vor riskanten Operationen schnell einen lokalen Commit anlegt. Ein CI-Predictor, der die GitHub-Workflows einmal mental durchspielt, bevor ich pushe – damit ich nicht reaktiv auf rote Builds reagieren muss. Und ein Deletion-Guardian, mein Lieblings-Agent: ein digitaler Türsteher, der bei jedem rm -rf oder DROP TABLE zuerst klassifiziert, was gelöscht werden soll, und im Zweifel einfach stoppt.

Dazu kamen sechs projekt-spezifische Helfer: Tester für Whisky-Kuratorium, LernyTube und EIS Schuh-Atelier, ein Excel-Importer für die Whisky-Vorlage, und für vita.eiskopani.de gleich zwei – einer für die Playwright-Tests, einer der direkt zu Hostinger deployt, ohne Rückfragen. Der zehnte ist der Blog-Autor: er entscheidet selbst, ob heute genug passiert ist, prüft mein Tageslimit (maximal drei Beiträge), und postet erst, wenn die HTML-Struktur konsistent ist. Er hängt am Session-Ende-Hook und meldet sich anschließend per Telegram.

Die Erkenntnis, die mich heute am meisten gefreut hat: ein Türsteher schlägt einen Schadensbegrenzer. Lieber einmal mehr stoppen als einmal zu viel löschen.

Die unangenehme Wahrheit: Tests prüfen nur, was sie testen. Sie ersetzen keinen Audit. Konkret hatte ich drei Lücken übersehen:

1. Der echte Anthropic-API-Key stand im Klartext in der docker-compose.yml. Nicht im Git-Repo, aber jeder mit Server-Zugriff hätte ihn lesen können. Fix: Schlüssel in eine .env mit chmod 600, im Compose nur noch ${ANTHROPIC_API_KEY} referenziert. Gleiches gilt für das DB-Passwort.

2. XSS im Frontend. Der KI-Output (Kernaussage, Stichworte, Bewertung) wurde direkt per innerHTML in das Dashboard gerendert. Wenn ein User in seine simulierte E-Mail <script>-Tags einschmuggelt und Claude diese im extrahierten Text spiegelt – Code-Ausführung im Browser. Fix: eine winzige esc()-Funktion, die HTML-Sonderzeichen escapt, und konsequent vor jedem dynamischen Wert anwenden.

3. Keine Schutz-Header. Keine Content-Security-Policy, kein X-Frame-Options, kein X-Content-Type-Options, keine Referrer-Policy. Fix: eine FastAPI-Middleware, die alle vier auf jede Antwort setzt – fünf Zeilen Code.

Was ich daraus mitnehme: Security-Audit ist eine eigene Phase, kein Nebenprodukt grüner Tests. Tests sichern App-Logik ab – Deployment-Artefakte (Compose, .env, Workflows) und Frontend-Rendering müssen separat durchgesehen werden. Ich habe dafür jetzt eine eigene Memory-Regel angelegt: „Bandit/Tests grün ≠ sicher; docker-compose, .env, Frontend-XSS, HTTP-Header explizit prüfen."

Bonus-Lektion am gleichen Tag: Drei Push-Zyklen, weil ich nach jedem CI-Fehler einzeln gefixt habe statt vorher den Workflow + die Repo-Struktur einmal zu lesen. Auch das ist jetzt eine Memory-Regel. Manchmal ist die teuerste Zeit die, in der man sich für „schnell mal pushen" entscheidet.

Antwort: Ja, wenn man das E-Mail-System komplett simuliert. Die KI-Extraktion bleibt echt (Claude Haiku 4.5), alles andere – Versand, Posteingang, Antwort – passiert im Browser. Damit lässt sich der gesamte Workflow demonstrieren, ohne externe Abhängigkeiten.

Architektur: FastAPI + PostgreSQL im Docker-Container, fünf Tabellen (Umfragen, Teilnehmer, Zuordnung, Antworten, Seminar-Referenzen), ein einseitiges Vanilla-JS-Dashboard. Jede Umfrage bekommt eine ID im Format UMF-2026-001. Wer eine Antwort simuliert, gibt sie als „E-Mail" mit dieser ID im Betreff ein – das System parst die ID per Regex, schickt den Freitext an Claude und speichert das JSON-Resultat als JSONB.

Human-in-the-Loop: Jede KI-Extraktion landet zuerst im Status PENDING. Erst nach manueller Freigabe geht die Antwort in die Auswertung – wird sie abgelehnt, ist die Extraktion verworfen. Ein simpler, aber wichtiger Schritt: Die KI ist hier ein Vorschlag, kein Urteil.

Eskalation: Ein zusätzlicher Endpoint /eskalieren findet alle überfälligen Versendungen (Frist überschritten, keine Antwort) und markiert sie. Das passt gut zum Use-Case, in dem regelmäßig Erinnerungen rausgehen müssen.

Tests: 18 Unit-Tests (ID-Generierung, Betreff-Parsing, KI-Output-Validierung), 23 Integrationstests gegen eine echte Postgres-Test-DB (alle API-Endpunkte), 26 Security-Tests (SQL-Injection-Payloads, Input-Validierung, HTTP-Methoden, XSS-Regression, Schutz-Header). Dazu Bandit für statische Code-Analyse und Safety für CVE-Checks – alles in einer GitHub-Actions-Pipeline mit vier parallelen Jobs.

Das Schöne an dem Ansatz: Wenn Outlook oder ein anderer Mail-Connector irgendwann tatsächlich angedockt werden muss, ist das nur eine Eingangsroute mehr. Die Logik dahinter – Parsen, KI-Extraktion, Review, Eskalation – bleibt unverändert. Simulation war hier kein Notnagel, sondern die ehrliche Antwort auf die Frage, welcher Teil der Wertschöpfung tatsächlich neu ist: nicht das Versenden, sondern das Verstehen der Antworten.

Also erst mal sortiert: Ein Idempotency Key sorgt dafür, dass ein doppelt abgeschickter Request nicht zweimal ausgeführt wird – klassisch bei Zahlungen, damit 50 € nicht versehentlich zweimal abgebucht werden. Da ich keine Payment-Flows habe, fällt das weg. Rate-Limit und IP-Throttling dagegen schützen öffentliche Endpoints vor Brute-Force und Flood-Angriffen – und genau das hat mir gefehlt.

Der kritische Punkt auf meinem Server ist der Musik-Upload-Proxy (FastAPI + SFTP), über den die Admin-Seite MP3-Dateien auf Hostinger schickt. Er ist zwar per Bearer-Token geschützt, aber SHA-256 ist schnell zu brute-forcen, und bei jedem fehlgeschlagenen Versuch würde der Server bis zu 50 MB Upload-Body entgegennehmen, bevor überhaupt die Auth greift. Klassisches DoS-Risiko.

Die Lösung: Rate-Limit-Middleware direkt auf Traefik-Ebene – kein Code-Rebuild nötig, blockt schon, bevor der große Body durchkommt. Vier Zeilen im docker-compose.yml: average=20, period=1m, burst=40 pro IP. Für mich beim Hochladen völlig unkritisch – für einen Angreifer bedeutet das, dass Brute-Force auf den Token statistisch unmöglich wird.

Seitenfund beim Reinschauen ins docker-compose.yml: Das SFTP-Passwort stand dort im Klartext. „Nicht heute" habe ich kurz gedacht – dann korrigiert vom User: „Warum nicht heute?" Gute Frage, kein guter Grund. Also gleich hinterher: Passwort in eine .env-Datei mit chmod 600, .gitignore daneben, env_file-Referenz im Compose-File. Damit ist auch ein späterer Git-Push des Verzeichnisses safe.

Lektion: Security-Fachbegriffe sind keine Checkliste, die man komplett abhaken muss. Erst verstehen, welches Problem sie lösen, dann prüfen, ob man dieses Problem überhaupt hat. Und wenn man dann doch etwas absichert: richtig, nicht halb.

Lösung für Teil eins: ein eigener MCP-Hub-Server unter mcp.eiskopani.de. MCP steht für Model Context Protocol – der Standard, über den Claude Tools von außen einbinden kann. Der Hub läuft als Docker-Container, hat die vier Projektverzeichnisse (LernyTube, Whisky, EIS, vita) read-only eingebunden und stellt Tools bereit wie list_projects, read_project_file oder run_shell. Jede neue Claude-Session kennt ab sofort alle Projekte automatisch. Authentifizierung per Secret im URL-Query, HTTPS via Traefik + Let's Encrypt.

Teil zwei war härter. Meine Telegram-Pipeline – ich schicke eine Nachricht ans Bot, und Claude Code erledigt die Aufgabe auf dem Server – hatte bisher ein Zwischenglied: Ein lokales Ollama-Modell (Qwen 2.5 Coder 7B) sollte die Nachricht in einen strukturierten Task formatieren. Klang clever, war in der Praxis aber ein Problem: Das Modell braucht 4,3 GB RAM, mein VPS hat nur 3,4 GB frei. Jeder zweite Aufruf endete mit Memory-Error.

Die ehrliche Erkenntnis: Claude Code selbst ist das smarte LLM. Warum soll ein zweites, kleineres Modell davor versuchen, Dinge zu „verstehen", wenn das eigentliche Modell dahinter das viel besser kann? Also Ollama komplett aus dem Workflow entfernt. Die Telegram-Nachricht geht jetzt direkt als Markdown-Datei in den Claude-Inbox-Ordner, ein systemd-Watcher pollt alle fünf Sekunden, Claude Code übernimmt, antwortet via Stop-Hook zurück an Telegram. Kein RAM-Problem, kein Memory-Error, und die Reaktionszeit ist spürbar schneller.

Beide Änderungen teilen eine Lektion: Komplexität ist kein Qualitätsmerkmal. Ein Layer, der Ressourcen frisst ohne Mehrwert zu bringen, muss raus – auch wenn er am Anfang schlau wirkte.

Also habe ich alle meine Projekte durchsucht – vita.eiskopani.de, das Whisky-Kuratorium und LernyTube. Das Ergebnis: Keines davon setzt Browser-Cookies. Was ich im Code gefunden habe, sind ausschließlich serverseitige Datenbank-Sessions (SQLAlchemy Session) – die haben mit Browser-Cookies nichts zu tun.

Kein Google Analytics, kein Tracking, keine Third-Party-Cookies. Das bedeutet: Ein Cookie-Banner wäre nicht nur unnötig, sondern sogar fragwürdig. Consent für etwas abfragen, das gar nicht stattfindet? Das verwirrt Besucher und ist rechtlich unsauber.

Die Lektion: Nicht jede „Best Practice" passt zu jedem Projekt. Erst prüfen, was technisch tatsächlich passiert – dann entscheiden. Falls ich später mal Login-Cookies oder Analytics einbaue, kommt der Banner dazu. Bis dahin bleibt er weg.

Die Ursache war, dass meine Upload-Admin-Seite die Dateien nur lokal im Browser gespeichert hat (localStorage), aber nie auf den Server hochgeladen hat. Das habe ich komplett umgebaut: Jetzt gibt es einen Upload-Proxy auf meinem VPS, der die MP3-Dateien per SFTP direkt an den Hostinger-Webserver schickt. Drag & Drop in die Admin-Seite → Fortschrittsbalken → fertig auf dem Server. Löschen geht auch direkt über den Button.

Technisch ist das ein kleiner FastAPI-Service mit Paramiko (Python SFTP-Bibliothek), der hinter Traefik unter lernytube.eiskopani.de/music-api/ erreichbar ist. Die Authentifizierung nutzt denselben Passwort-Hash wie die Admin-Seite – keine doppelte Pflege.

Und weil „es funktioniert" nicht reicht, habe ich 14 Playwright-Tests geschrieben, die den Player automatisiert prüfen: Ist die Playlist da? Funktioniert Next/Prev? Kann man die Lautstärke ändern? Und vor allem: Sind alle 25 MP3-Dateien auf dem Server erreichbar (kein 404)? Alle Tests grün.

Die Antwort war überraschend klar. Microservices lösen ein Teamproblem: Wenn fünf Teams gleichzeitig an einem Produkt arbeiten, braucht man unabhängige Deployments. Wenn ein Service 100-mal mehr Last bekommt als der Rest, will man ihn separat skalieren. Beides trifft auf mich nicht zu. Ich arbeite allein, meine Projekte haben überschaubare Last, und mein Server hat nicht mal genug RAM für Ollama ohne Swap.

Was Microservices kosten würden: mehr Container, mehr RAM-Verbrauch, Service Discovery, Health Checks, Retry-Logik, Distributed Tracing statt einfachem Logging. Jeder dieser Punkte ist ein eigenes Rabbit Hole – und keiner davon macht meine Schuh-Galerie oder mein Whisky-Kuratorium besser.

Mein Ansatz: Ein sauberer Monolith pro Projekt. Whisky-Kuratorium, LernyTube und EIS Schuh-Atelier sind bereits getrennte Repositories mit eigenen Containern – das ist die richtige Schnittlinie. Innerhalb jedes Projekts sorgen Router, Services und Models für Ordnung, ohne dass ich dafür Netzwerk-Calls zwischen Containern brauche.

Die wichtigste Erkenntnis: Architektur-Entscheidungen sollten von den eigenen Rahmenbedingungen ausgehen, nicht vom letzten Conference Talk. Ein Solo-Projekt auf einem VPS ist kein Netflix. Und wenn ein Projekt irgendwann wirklich wächst, kann ich Module immer noch extrahieren – aber dann aus einer funktionierenden Codebasis heraus, nicht aus einer vorzeitig zerlegten.

Dazu kamen GitHub-Actions-Pipelines, die bei jedem Push automatisch loslaufen – mit echten Datenbanken als Service-Container, nicht mit Mocks. Denn genau da hatten wir vorher ein Problem: Mock-Tests bestanden, aber die echte Datenbank verhielt sich anders. Diese Lektion sitzt jetzt im Code statt nur im Kopf.

Was dabei sichtbar wird: Testmanagement und Release-Steuerung beim InGe-Tool, agiles Projektmanagement mit Scrum und SAFe, Prozessautomatisierung mit Power Apps und Power Automate, Stakeholder-Kommunikation quer durch den Konzern. Dazu kommen Seminare wie IREB, ITIL und Leading SAFe – und natürlich die laufende Weiterbildung zur Software Developerin (IHK) mit Python, SQL und Web-Entwicklung.

Besonders spannend finde ich, wie sich der rote Faden zieht: Egal ob Kreditvergabe digitalisieren, Formulare in Form.io bauen oder heute eigene Docker-Container auf dem VPS betreiben – es ging immer darum, Abläufe zu verstehen und dann besser zu machen.

Dazu kam ein Mini-Kalender auf dem Dashboard, der die eigenen Lernsessions tagesgenau anzeigt und filtert – so sieht man auf einen Blick, wann man wie viel gelernt hat. Über 900 neue Zeilen Code an einem Tag, verteilt auf 15 Dateien: Routen, Modelle, HTML-Templates und JavaScript. Es fühlt sich gut an, wenn aus einer Idee Schritt für Schritt ein echtes Produkt wird.

Im Header leuchtet ab sofort die aktuell besuchte Seite in Champagner-Gold mit einem weichen Glow und einer dunklen Patina-Linie darunter – wie ein Messingschild in einer alten Bibliothek. Die roten Trennlinien unter den Überschriften sind goldenen gewichen, alle Buttons tragen nun Kupfer-Gold mit Navy-Schrift, und das Motto-Band auf der Startseite hat das schreiende Rot gegen ein cremefarbenes Band mit goldenen Linien getauscht.

Drei Vorschläge habe ich Claude machen lassen, eine Test-Seite gebaut, im Browser verglichen, entschieden – und dann lief alles automatisch durch: CSS angepasst, Cache-Buster gebumpt, per SFTP deployt, in GitHub gesichert. Zum Abschluss noch das Portrait auf wer-bin-ich ausgetauscht. Manchmal ist ein guter Tag einfach ein Tag, an dem die Seite endlich so aussieht, wie sie sich anfühlen soll.

Das Ergebnis: Sichere Passwörter generiert (64 Zeichen, kryptografisch zufällig), Datenbank mit den neuen Credentials neu aufgesetzt, ein zentrales Auth-Modul gebaut, alle Routen auf saubere Bearer-Token im Header umgestellt (statt Token in der URL), CORS auf die richtige Domain eingegrenzt, Passwort-Validierung serverseitig verschärft, der Excel-Upload auf 10 MB begrenzt – und am Ende ein Git-Push und ein neuer Blog-Eintrag.

Was übrig blieb: drei Punkte, die wirklich meine Entscheidung brauchen – ein DNS-Eintrag beim Provider, meine echte Admin-Email, und der erste visuelle Test im Browser. Genau die Art von Arbeitsteilung, die ich mir vorgestellt hatte: Die KI macht das Stumpfe und Mechanische, ich treffe die Entscheidungen, die nur ein Mensch treffen kann.

Im zweiten Teil des Tages ging es um Sicherheit: Sichere Passwörter generiert, CORS auf die Domain eingegrenzt, der Login-Mechanismus von URL-Parametern auf richtige Bearer-Token im Header umgestellt, Passwort-Validierung serverseitig verschärft. Aus einem Prototyp wird langsam ein produktionsreifes System.

In einer einzigen Session haben wir die komplette Infrastruktur aufgebaut: Docker-Container, PostgreSQL-Datenbank, Nutzer-System mit Einladungs-Hierarchie (man muss freigeschaltet werden), JWT-Authentifizierung und eine vollständige API für die Sammlung. Das Highlight: Ein Excel-Import, der eine ganze Sammlung per Drag-and-Drop einlesen kann – mit automatischer Erkennung, ob eine Flasche bereits existiert. Manchmal passiert an einem Tag mehr, als man für eine Woche plant.

Das Ergebnis: Ein funktionierender Workflow, der eine Nachricht wie „Baue einen Logout-Button" entgegennimmt, per lokalem KI-Modell (Ollama) in eine strukturierte Entwicklungsaufgabe verwandelt und in eine Warteschlange schreibt. Neu dazu kam ein /status-Befehl, der auf Knopfdruck zeigt, welche Aufgaben offen und erledigt sind. Kleine Nachricht, große Wirkung.

Und eine Ende-Datei, die sicherstellt, dass am Schluss nichts verloren geht. Die echte Herausforderung? Alle laufenden Projekte, Zugangsdaten, Infrastrukturdetails und Arbeitsregeln so zu strukturieren, dass eine KI in Sekunden einsatzbereit ist – ohne dass ich jedes Mal von vorne erklären muss. Das ist wie ein perfektes Briefing für einen neuen Kollegen, den man immer wieder frisch begrüßt.

Es ist der Entschluss, meinen Lernweg öffentlich zu machen. Nicht als Hochglanz-Portfolio, sondern als echtes Tagebuch meiner Entwicklung.

Dieser Blog wird von mir und meinem KI-Assistenten Claude gepflegt. Nach jeder Arbeits-Session entsteht hier ein Eintrag – damit nichts verloren geht und du nachvollziehen kannst, wie Projekte wirklich entstehen.