Senior Web Engineer mit KI-Schwerpunkt

Eigenes System, technische Tiefe.

• FastAPI
• SQLite
• NetworkX
• FAISS
• Ollama
• Qwen3
• bge-m3
• RX 6900 XT

Problem

Klassische Wissensspeicher – Ordner, Wikis, statische Vektor-Systeme – halten Wissen statisch. Sie zeigen weder Widersprüche über die Zeit, noch die Entwicklung des eigenen Denkens oder emotionale Gewichtungen.

Meine Rolle

Alleinige Konzeption, Architektur und Implementierung: Backend (FastAPI), CLI (Typer), 3D-Frontend (React + Three.js) und der komplette lokale Modell-Stack.

Lösung

Event-Sourcing-light: SQLite als einzige Quelle der Wahrheit, NetworkX als flüchtiger Graph-Cache, FAISS (IndexFlatIP) für Embeddings (bge-m3). Lokale LLMs via Ollama (Qwen3:8b, VLM qwen2.5vl:7b) treiben spezialisierte Agenten (präfrontaler Kortex, Temporallappen, limbisches System, Zirbeldrüse, Entity Resolver). Das Frontmatter von Notizen und Dokumenten wird auf Hirnareale gemappt; ein Hemisphären-Split trennt Logik (links, analytisch) und Design (rechts, kreativ). Die Decay-Rate modelliert ein Langzeitgedächtnis – Wissen verblasst im Ranking, ohne je gelöscht zu werden. Context Engineering statt naiver Vektorsuche, alles local-first auf einer RX 6900 XT.

Ergebnis

Real implementiert (Living Spec v1.2): 12 CLI-Befehle, REST-API, 3D-Graph mit LOD, Sentiment- und Widerspruchsanalyse, Entity-Dedup, deutsches TTS und Vault-Import – vollständig ohne Cloud lauffähig. Modellwahl per eigenem Benchmark statt Bauchgefühl.

Erkenntnisse

Ein append-only Event-Log macht das System reparierbar: „rebuild" spielt alles neu ein – ideal bei Modell- oder Schema-Wechsel. FAISS IndexFlatIP schlägt IVF bis ~100k Vektoren (kein Training, sauberes Löschen). Und: Spec und Code als Living Document synchron halten, sonst verwaisen beide.

KI in Produktion, Multi-Modell-Pipeline.

• Multi-Modell-Architektur
• KI-Funktionen
• Bildgenerierung

Problem

Content-Produktion lief komplett händisch: recherchieren, schreiben, posten, Bildmaterial erstellen oder einkaufen – zeitaufwändig und nicht skalierbar.

Meine Rolle

Konzeption und Umsetzung des generativen Blog-Systems und des datengetriebenen Frontends.

Lösung

LLM-gestützte Websuche für die Recherche, ein datengetriebenes Frontend mit React und SQLite sowie ein generatives Blog-System, das Beiträge inklusive Bildmaterial erzeugt.

Ergebnis

Von der Recherche bis zum veröffentlichten Beitrag rund 7 Minuten statt manueller Stunden – auf Wunsch vollautomatisch per Cronjob. Live im Einsatz auf dataso.de/blog.

Erkenntnisse

Der Engpass verschiebt sich vom Schreiben aufs Kuratieren: Ein datengetriebenes Frontend hält die generierten Inhalte konsistent und wartbar. Vollautomatisierung ist technisch möglich – redaktionelle Leitplanken entscheiden über die Qualität.

Solides Frontend-Handwerk im Unternehmenskontext.

• React Router 7
• Tailwind CSS
• API-first

Problem

Eine bestehende WordPress-Basis sollte durch einen modernen, wartbaren Stack abgelöst werden – schneller, mobile-first und ohne CMS-Ballast.

Meine Rolle

Frontend-Design und -Umsetzung.

Lösung

Generatives Frontend mit Vision-Model, ein durchgängiges Designsystem sowie API-first- und Mobile-first-Architektur auf modernem Stack (React Router 7, Tailwind CSS).

Ergebnis

Moderne, API-getriebene Plattform statt WordPress – live unter commodity-board.com. Lighthouse-Score von 55 % (alte Seite) auf 100 % (neue Seite).

Erkenntnisse

WordPress erfolgreich abgelöst: Ein moderner, API-first Stack ist wartbarer und schneller als die gewachsene CMS-Installation. Die saubere Entkopplung von Frontend und Datenquelle macht den Umstieg beherrschbar.

Context Engineering als Konzept — die Kern-Positionierung.

• TypeScript
• PostgreSQL
• Qwen3
• Ollama

Problem

Notizen, Learnings und Recherche lagen verstreut in losen Dateien. Um ein LLM sinnvoll mit dem eigenen Wissen zu füttern, fehlte eine strukturierte, kontinuierlich wachsende Quelle statt einzelner Snippets.

Meine Rolle

Konzeption und Umsetzung im Alleingang – Datenmodell, Backend und lokale LLM-Anbindung.

Lösung

Ein eigenes, persönliches Wiki nach dem Karpathy-Muster: Wissen wird fortlaufend akkumuliert und strukturiert in PostgreSQL abgelegt, TypeScript als durchgängiger Stack, Qwen3 via Ollama für lokale LLM-Funktionen. Fokus auf Context Engineering – das Wiki liefert gezielt den richtigen Kontext ins Modell statt naiver Vektorsuche.

Ergebnis

Persönliche, wachsende Wissensbasis, die als lokale Kontextquelle für LLM-Abfragen dient – vollständig ohne Cloud.

Erkenntnisse

Context Engineering in der Praxis: strukturierte, akkumulierte Notizen schlagen naive Vektorsuche. Der Wert entsteht durch konsequente Pflege – ein Wiki ist nur so gut wie die Disziplin dahinter.