Nicht nur ein Ingenieur.
Ein Entwickler mit Anspruch.
Ich habe 2012 angefangen, Android-Apps in Java zu schreiben, als Smartphones die Menschen noch überraschten.
In 13 Jahren habe ich über weite Teile des Stacks gearbeitet: natives Android und iOS, dann React Native, dann Full-Stack-Web mit React, Next.js und Node, und zuletzt Backend-Dienste in Python mit FastAPI. 2025-26 habe ich LLM-gestützte Funktionen auf Azure OpenAI gebaut: einen Proof of Concept für Dokumenten-RAG mit PII-Schwärzung vor dem Modell sowie Integrationen mit drei Agent-Plattformen hinter einer einzigen Orchestrierungsschicht.
Was mir das Jahrzehnt auf Mobile hinterlassen hat, ist die Gewohnheit, unter Einschränkungen zu bauen. Eine veröffentlichte App lässt sich nicht heiß patchen, also hört Abwärtskompatibilität auf, optional zu sein. Und man baut für das Gerät, das man bekommt: In einem Backend-Dienst sind Thread-Anzahl und Batch-Größe über die App-Service-Stufen hinweg konfigurierbar, damit er auf der günstigsten Stufe läuft, die die Last trägt.
Jetzt gehe ich tiefer in die Zuverlässigkeitsseite von KI-Systemen: Evaluierung, Retrieval-Korrektheit und Kosten.
Performance ist ein Feature
Schnell und fehlertolerant by design, nicht zufällig. Die meisten meiner Verbesserungen kamen daher, den langsamen Pfad erst zu messen statt ihn zu raten.
KI als Kern, nicht als Dekoration
Wenn ich ein LLM einsetze, soll es echte Arbeit leisten: Retrieval, das das richtige Dokument liefert, Schwärzung vor dem Prompt, eine echte Schnittstelle dahinter. Kein Chatbot-Wrapper, der auf ein bestehendes Produkt geklebt wird.
Nutzerinstinkt aus dem Mobile-Bereich
13 Jahre Lieferung an echte Nutzer gibt einem eine Perspektive, die die meisten Backend-Ingenieure nie bekommen. Ich habe nie vergessen, wer auf der anderen Seite der API ist.
Ehrliche Evolution
Android 2012. Retrieval-Systeme 2026. Ich gehe tief in das, was kommt, gebe aber nicht auf, was noch funktioniert.