Du sitzt vor der API-Dokumentation von OpenAI, hast gerade deinen ersten API-Key generiert und fragst dich: „Okay, was baue ich jetzt damit?“ Das war der Moment, in dem ich beschloss, nicht groß zu philosophieren, sondern einfach ein Tool zu schreiben – ein Social-Media-Post-Generator. Simpel, aber ausreichend komplex, um zu verstehen, wie die API tatsächlich funktioniert. Und nebenbei lernte ich etwas über Authentication, das mir später bei größeren Projekten ersparte, vorher reinzurechnen.
Das Problem: Posts ohne Prompt-Engineering
Die meisten Chat-Tools funktionieren nach dem gleichen Prinzip: Du schreibst einen möglichst präzisen Prompt, schickst ihn los und hoffst auf ein brauchbares Ergebnis. Das ist mächtig, aber auch fehleranfällig. Wer nicht weiß, wie man gute Prompts schreibt, bekommt schlechte Ergebnisse. Und wenn deine Nutzenden später Posts für LinkedIn, Instagram und Twitter schreiben sollen – das sind völlig unterschiedliche Anforderungen an Länge, Tonalität und Format.
Meine Idee war eine Ebene Abstraktion dazwischen: Der Nutzende beschreibt nur, was der Post kommunizieren soll. Alles andere – Plattform, Medium, Tonalität – wird über Formulareingaben gesteuert. Die App übersetzt das intern in einen strukturierten Prompt. So wurde ein komplexes Problem auf einmal zugänglich.
Die Architektur: Parameter statt Freiheit
Das Interface ist bewusst minimalistisch. Vier Eingabefelder, vier Selects, fertig. Hier die Logik dahinter:
Was der Nutzende einfach macht:
- Beschreibung eingeben (was soll der Post aussagen?)
- Plattform wählen (LinkedIn? Instagram? Twitter?)
- Medium definieren (einzelner Post, Story, Carousel?)
- Vibe festlegen (professionell, locker, inspirierend, aktivierend?)
Was die App intern macht:
Diese Parameter landen in einem strukturierten Prompt-Template. Statt „Schreib was über unser neues Feature“ wird das zu: „Schreib einen Instagram Carousel Post (3 Slides) mit inspirierendem Vibe über unser neues Feature. Fokus: User Benefits, max. 80 Zeichen pro Slide, Emoji-freundlich.“
Die OpenAI-API bekommt diese strukturierte Anfrage, nicht das vage Original. Die Qualität der Outputs stieg damit um ein Vielfaches.
Intern nutzte ich einen einfachen Prompt-Builder, der die Parameter zusammensetzt. Nichts Komplexes – nur String-Konkatenation mit intelligenten Defaults. Aber dieser einfache Mechanismus war der Schlüssel, warum das Tool für nicht-technische Nutzende überhaupt sinnvoll war.
Der erste Kontakt mit einem Auth-Provider: Clerk
Hier kam der zweite wichtige Lernpunkt: Authentifizierung. Mein erstes Projekt hatte ich noch selbst mit Sessions und Cookies gebastelt – das funktionierte, war aber fragil. Diesmal wollte ich es richtig machen.
Clerk war meine erste Wahl. Und das war eine großartig pragmatische Entscheidung. Statt selbst OAuth-Flows zu implementieren, User-Sessions zu managen und Sicherheit zu überdenken, integrierte ich Clerk als Drop-in-Lösung.
Was Clerk für mich erledigte:
- Sign-up und Login mit vorgefertigten UI-Komponenten
- Session-Management im Backend (signierte JWTs)
- User-Datenverwaltung (ID, E-Mail, Metadaten)
- Das sichere Weitergeben der User-ID an meine API
Das klingt vielleicht banal, aber es war ein wichtiger Moment für mich. Ich erkannte, dass es nicht immer schlau ist, wenn man nicht jede Schicht der Infrastruktur selbst bauen kann. Clerk war gut dokumentiert, sicher und ich konnte mich auf die AI-Features konzentrieren.
Die Integration war simpel: Clerk-Middleware im Backend, Clerk-Components im Frontend, und jeder API-Request konnte die User-ID aus dem Token extrahieren. Keine selbstgebauten Sicherheitslöcher, keine Session-Bugs.
Herausforderungen, die ich unterschätzt habe
Konsistente Outputs bei variablen Inputs
Ein LLM ist nicht deterministisch. Zwei identische Requests können unterschiedliche Ergebnisse liefern. Das war ein Problem, wenn ich die gleiche Anfrage zweimal in Tests gestellt habe und unterschiedliche Outputs erwartete. Die Lösung: Temperature auf 0.7 runterfahren, damit es konsistent bleibt, aber nicht roboterhaft wirkt.
Plattform-spezifische Constraints
Twitter hat 280 Zeichen, LinkedIn ist ausführlich, Instagram ist visuell. Das LLM musste diese Unterschiede wirklich verstehen. Twitter Posts sind schneller geschrieben, aber getrickst man bei der Zeichenkontrolle, passt der Post nicht. Ich musste das Template mehrfach justieren, bis die Outputs konsistent passten.
Meine Leasings aus dem kleinen Projekt
Auf der Oberfläche: ein simpler Social-Media-Generator. Tatsächlich war es ein Crash-Kurs in drei Dingen.
- Wie man generative KI wirklich nutzt. Nicht als Blackbox, sondern als Werkzeug mit Eingabe-Output-Logik. Struktur in die Prompts bringen, Parameter nutzen, den Output evaluieren. Das unterscheidet ein brauchbares Tool von Spielerei.
- Abstraktionsebenen bauen. Nicht die volle Komplexität den Nutzenden geben. Sie wollen ihre Posts generiert bekommen, nicht Prompt-Engineering lernen. Je simpler das Interface, desto besser die UX – aber dafür braucht es saubere interne Logik.
- Professional Dependencies einbauen. Clerk zeigte mir, dass ich nicht alles selbst bauen muss. Auth ist kritisch für Sicherheit – warum das Risiko eingehen, wenn es erprobte Lösungen gibt? Das war ein Paradigmenwechsel: „Build vs. Buy“ intelligent entscheiden.
Direkter Einfluss auf spätere Projekte
Meine ersten Ansätze einer KI-Suite (an der ich später arbeitete) ist konzeptionell ein direkter Nachfahre dieses kleinen Tools. Statt freier Prompts wird die Generierung durch Parameter gesteuert. Deshalb. Wie wichtig sind strukturierte Anleitungen für gute Ergebnisse? Hier habe ich etwas gelernt. Vertrauen Sie professionellen Lösungen zur Authentifizierung? Auch hier.
Manche halten dieses Projekt für eine „Spielerei“. Ich sehe es anders: Es war eine Lernschleife. Bauen, um zu lernen, nicht lernen, um zu bauen. Das ist der Unterschied zwischen Theorie und Praxis.