Noel Schmitt

Schlagwort: OpenAI

  • Wie ich der KI beibrachte, bessere Markennamen zu finden als wir

    Du sitzt in der vierten Stunde eines Naming-Workshops. Fünf Personen, ein leeres Flipchart, und irgendwer schlägt wieder „Brandify“ vor. Bei einem White-Label-Unternehmen mit 30 neuen Produkten pro Quartal ist das nicht skalierbar – es ist ein Burnout-Generator. Also habe ich gebaut, was fehlte: ein internes Tool, das kreative Prozesse nicht ersetzt, sondern intelligent strukturiert.

    Das Problem: Kreativität braucht Grenzen

    Naming ist ein seltsames Handwerk. Es ist gleichzeitig künstlerisch und datengetrieben, intuitiv und methodisch. Der klassische Prozess sieht so aus: Briefingrunde, Brainstorming, manuelle Domain-Checks, parallele Markenrecherche, Diskussionen, Überarbeitungen. Bei großen Unternehmen mit mehreren Produktlinien wird das zur Zeitfalle.

    Das Kernproblem war nicht die fehlende Kreativität im Team. Das Problem war die Struktur: Weder hatten wir klare Kriterien, noch konnten wir schnell iterieren. Jede neue Ideenrunde war ein Neustart statt eine Verfeinerung.

    Dann kam die Frage: Was, wenn wir diesen Prozess strukturieren und in einen Vorgang mit intuitiver UI gießen könnten?

    Entscheidung: Parameter statt Freitext-Prompts

    Ich hätte zwei Wege gehen können. Der erste: Ein einfaches Interface, bei dem jede Person direkt einen Prompt schreiben kann – „gib mir kreative Tech-Namen“. Das wäre schnell gebaut, aber würde das Problem nicht lösen.

    Der zweite Weg war aufwendiger, aber konzeptionell sauberer: Vor der KI-Generierung zwingt das System den Nutzende, sich selbst klar zu werden. Was genau wird benannt? Welche Werte soll der Name transportieren? Wie abstrakt darf es sein?

    Ich entschied mich für den zweiten Weg – nicht weil es weniger Arbeit ist (das Gegenteil ist der Fall), sondern weil er das eigentliche Problem adressiert: schlechtes Briefing führt zu schlechten Namen, nicht mangelnde KI-Qualität.

    Die Parameter wurden damit zur Struktur:

    Produktbeschreibung: Was ist das Produkt wirklich? Bei „Heizungsservice für Ältere“ ist das anders als bei „Tech-Startup für Gebäudeautomation“ – obwohl beide mit Heizung zu tun haben.

    Kreativitätslevel: Slider von „Kunstname“ (Zalando, Spotify – komplett abstrakt) bis „beschreibend“ (heizung24.de – funktional). Das gibt dem System vor, wie weit es abstrahieren soll.

    Namenslänge: Ein Wort? Wortkombination? Diese Entscheidung hat massive Auswirkungen auf Merkbarkeit und spätere Domain-Verfügbarkeit.

    Das Gegenstück zu dieser Struktur war: Keine freie Texteingabe. Kein „gib mir mal was Cooles“. Nur klare, parametrische Vorgaben.

    Technische Umsetzung: Struktur trifft Iteration

    Der Kern ist ein ausgeklügelter System-Prompt für die Claude API. Dieser Prompt ist nicht einfach eine Eingabe – er ist selbst das Produkt von 20+ Iterationen. Er enthält explizite Regeln für Namensgenerierung: phonetische Eigenschaften, kulturelle Kontexte, Suchmaschinen-Optimierung im Hinterkopf.

    Das Interface ist absichtlich simpel. Nicht weil es leicht zu bauen war, sondern weil Komplexität nirgends hin sollte außer in die intelligente Parameter-Verarbeitung dahinter.

    Der Workflow in der Praxis:

    Nach der Generierung einer Namen-Liste kommt der entscheidende Moment: das Favoriten-System. Der Nutzende markiert Namen, die in die richtige Richtung gehen. Startet er eine neue Iteration, erhält die KI nicht nur die ursprünglichen Parameter zurück, sondern auch die Information „das waren die bisherigen Favoriten“.

    Das System lernt Pattern. Es merkt sich: „Okay, wir bevorzugen konkrete Anker-Wörter“ oder „keine Kunstwörter unter drei Silben“. Die nächste Iteration wird präziser. Und die nächste noch mehr.

    So entsteht ein fokussierter Arbeitsbereich, statt jedes Mal in der Breite zu generieren. Das ist der entscheidende Unterschied zu einzelnen KI-Anfragen.

    Domain-Intelligenz als zweiter Layer:

    Ein Name ist nur so gut wie seine Verfügbarkeit. Also wurde ein Domain-Check direkt in den Workflow integriert – nicht als Nachgedanke, sondern als gleichwertiger Prüfschritt neben der Kreativität.

    Der Trick dabei: Das System erkennt den Kontext. Endet ein Name zufällig auf „-io“, wird auch die „.io“-Domain geprüft. Ist der Produktname regional bezogen, könnten „.berlin“ oder „.hamburg“ sinnvoller sein als „.com“. Diese Logik ist hard-coded – nicht weil KI-Prompts das nicht könnten, sondern weil dedizierter Code zuverlässiger ist.

    So sieht ein Nutzender auf einen Blick: Welche Namen sind nicht nur kreativ stark, sondern auch praktisch verfügbar?

    Kosten- und Nutzungs-Tracking:

    Bei internen Tools ist einer der unterschätzten Aspekte: Transparenz über Kosten. Das System trackt Token-Verbrauch und Generierungen pro Person, pro Team, pro Monat. Das dient nicht der Kontrolle, sondern der Orientierung: Rentiert sich dieses Tool? Welche Teams nutzen es? Wo skaliert es?

    Diese Daten sind für die Weiterentwicklung essentiell. Sie zeigen, ob die Parameter-Struktur tatsächlich Zeit spart oder ob Teams trotzdem zu viele Iterationen brauchen.

    Was nicht funktioniert hat (und was ich gelernt habe)

    Fehler 1: Zu viele Parameter am Start

    Mein ursprünglicher Prompt für die Namensgenerierung war überambitioniert. Ich wollte, dass die KI gleichzeitig auf Phonetik, kulturelle Sensibilität und Markenverfügbarkeit achtet. Das Ergebnis: generische Namen, weil der Prompt zu viel zu gleichzeitig verarbeiten musste.

    Die Lösung war, den Prompt zu reduzieren und einzelne Anforderungen in separate Layer zu verschieben – Domain-Check ist Automatisierung, nicht KI-Prompt. Das hat Qualität und Geschwindigkeit sofort verbessert.

    Fehler 2: UX-Komplexität nach oben gedacht statt nach unten

    Ich dachte: „Wenn ich alle Parameter visuell elegant gestalte, nutzen auch Nicht-Tech-Personen das Tool.“ Das ist naive gewesen. Was tatsächlich funktionierte, waren mehrere Dinge:

    Sinnvolle Defaults (Namenslänge=mittel war für 80% der Cases richtig). Kontextuelle Hinweise direkt im Interface („Warum fragst du das?“). Und ein Tutorial, das nicht peinlich wirkt, sondern die erste Nutzung zeigt.

    Fehler 3: Zu viel Automatisierung

    Mein Plan war: Alles automatisieren, auch die Markenschecks. Die Realität: Markenrecherche ist rechtlich komplex. Die Integration der DPMA-API ist sinnvoll, aber sie ersetzt keine menschliche Prüfung – sie bereitet sie vor. Diese Unterscheidung habe ich zu spät verstanden.

    Das Tool sollte Recherchezeit sparen, nicht rechtliche Prüfung ersetzen.

    Was das Projekt zeigt

    Es ist leicht, „ein Naming-Tool mit KI“ zu beschreiben. Es ist deutlich schwerer, eines zu bauen, das schneller ist als Brainstorming und bessere Ergebnisse liefert.

    Der Schlüssel war nicht die KI-Integration. Der Schlüssel war: Kreative Prozesse brauchen Struktur, um skalierbar zu werden. Parameter erzwingen klares Denken. Iteratives Feedback macht Vagueness unmöglich. Automatisierte Recherche spart die echte Arbeitszeit.

    Wenn ich das Projekt heute neu starten würde, würde ich nicht anders vorgehen – das Konzept funktioniert – aber ich würde drei Dinge von Anfang an einplanen:

    Markenrecherche als Feature, nicht als Gimmick. Die DPMA-Integration sollte Teil des MVPs sein, nicht eine „nice-to-have“ für später.Bessere Fehlertoleranz in Prompts. Der Claude-Prompt brauchte zwei Überarbeitungen, bis er konsistent gute Namen generierte. Das hätte durch frühere QA vermieden werden können.

    Das Tool ist heute in Nutzung, spart geschätzten 20-30 Stunden pro Monat bei der Naming-Recherche ein und hat sich innerhalb von drei Monaten selbst finanziert. Aber der echte Wert liegt nicht in der KI-Integration – er liegt darin, dass Menschen jetzt strukturiert kreativ sein können statt unstrukturiert zu brainstormen.

  • Wie befähigt man eine Marketingabteilung zur Nutzung von KI in Zeiten der Compliance und DSGVO?

    Du sitzst gemeinsam mit dem Kunden in einem Meeting und hörst zum hundertsten Mal: „Wir können keine KI einsetzen. ChatGPT ist nicht freigegeben.“ Nebenan kämpft die Marketing-Abteilung mit generischen Social-Media-Posts, weil niemand Zeit für Prompt-Engineering hat. Das war die Realität in den meisten Unternehmen (mittlerweile haben die meisten es ja geschafft, Lösungen zu finden) – KI-Potenzial trifft auf berechtigte Angst vor Kontrollverlust.

    Was wenn es einen dritten Weg gäbe? Nicht ChatGPT für alle (unmöglich), nicht KI-Verzicht (rückständig), sondern eine maßgeschneiderte Plattform, die KI-Power mit Enterprise-Sicherheit verbindet.

    Das echte Problem: Flexibilität ohne Leitplanken führt zu Mittelmäßigkeit

    Die klassischen Chat-Interfaces sind für die Daily Driver oder Prompt Experten gebaut. Du brauchst KI-Intuition, um gute Prompts zu schreiben. Du musst wissen, welche Parameter wichtig sind, welche Ton-Variationen funktionieren, welche Struktur zum Output führt. Für den Rest der Organisation ist das eine hohe Hürde.

    Gleichzeitig waren offene Zugänge zu ChatGPT oder Claude in regulierten Unternehmen oft ein No-Go. Die Angst vor Datenlecks ist nicht paranoid – sie ist berechnet. Mitarbeitende, die unachtsam ein Geschäftsgeheimnis in die falsche KI eingibt, kann erheblichen Schaden anrichten.

    Das Ergebnis ist eine paradoxe Situation: KI wird als transformativ gepriesen, aber in der Realität schleppend adoptiert. Und wenn sie genutzt wird, oft ohne klare Leitplanken – die Outputs sind mittelmäßig, weil die Nutzenden nicht wissen, wie man KI richtig brieft.

    Der Ansatz: Spezialisierte Tools statt generischer Chat

    Das Konzept ist einfach: Jeder Use Case bekommt sein eigenes Interface. Jedes Tool hat vordefinierte Felder, hinter denen ein optimierter Systemprompt arbeitet. Die Nutzer beantworten Fragen aus Formularen. Am anderen Ende kommt hochwertiger, passender Inhalt heraus.

    Das funktioniert, weil die Arbeit am Aufbau der Architektur schon erledigt ist. Statt dass 500 Mitarbeitende einzeln lernen, wie man einen Social-Media-Post optimal strukturiert, haben drei Fachleute einmal den perfekten Ablauf definiert und in ein Tool übertragen.

    Tool 1: Social Media Creator – Multichannel aus einer Quelle

    Stell dir vor, du hast einen wertvollen Blogartikel geschrieben. Das hätte LinkedIn, Instagram und Twitter gut getan. Aber jeder Kanal muss anders sein.

    Der Social Media Creator fragt systematisch ab: Welche Kanäle? LinkedIn, Twitter, Instagram oder alle drei? Welche Tonalität soll es sein? Ist da ein Aufruf zum Handeln? Ein konkretes Angebot?

    Die KI macht das nicht. Sie erstellt nicht einfach die gleiche Botschaft in drei Varianten. Sie passt sich intelligent an: Die LinkedIn-Version wird tiefer, die Twitter-Version knackig und provokativ, die Instagram-Version visuell und emotional. Jede Version klingt anders, weil sie für ihre Plattform optimiert ist.

    Der Nutzer kopiert, was er braucht, und bespielet seine Kanäle. Kein Trial-and-Error, keine Prompt-Engineering-Sessions. Und immer mit der Sprache des Unternehmens abgestimmt.

    Tool 2: Podcast Processing Pipeline – Die Content-Kette

    Das Podcast-Tool zeigt das beste Konzept der ganzen Suite: die Verzahnung von Tools.

    Ein Podcast wird aufgenommen und transkribiert. Dann wird das Transkript in den Social Media Creator überführt. Dort werden drei LinkedIn-Posts mit den wichtigsten Erkenntnissen, Instagram Stories mit den wichtigsten Aussagen und ein Tweet-Thread mit den besten Zitaten des Gastes erstellt. Gleichzeitig wird eine optimierte Beschreibung für Podcasts erstellt. Diese enthält Keywords für SEO.

    Das ist keine automatische Textkopie. Das ist intelligente Format-Transformation. Ein Podcast-Transkript wird einmal erstellt und dann in fünf verschiedenen Formaten veröffentlicht. Diese sind aber nicht identisch, sondern passen zum Kontext.

    Man spart viel Zeit. Normalerweise kostet es einen halben Tag, einen Podcast zu erstellen. Hier geht es nur wenige Minuten. Die Qualität bleibt gleich, weil alle Ausdrucke aus den gleichen optimierten Systemprompts kommen.

    Tool 3: Brand Voice Checker – Deine Sprachpolizei

    Hier sitzt die unsichtbare Intelligenz der Plattform. Der Brand Voice Checker stellt sicher, dass nichts, was deine Organisation verlässt, an den Corporate Guidelines vorbeischleicht.

    Du hinterlegst die Regeln einmal: Anrede Du oder Sie? Wie heißt dein Produkt korrekt? Aktive oder passive Sprache? Welche Tonalität ist gewünscht? Was sind absolute No-Gos?

    Jeder generierte Text läuft durch diese Prüfung – entweder automatisch oder manuell. Das System prüft nicht starr. Es versteht Kontext: Ein interner Slack-Post hat andere Standards als eine Pressemitteilung. Eine Kundenansprache unterscheidet sich von einer Geschäftspartner-Kommunikation.

    Die Ergebnisse werden in einer Ampel visualisiert. Grün: alles in Ordnung. Gelb: Verbesserungsvorschläge. Rot: kritische Abweichungen. So erkennst du auf einen Blick, wo du handeln musst.

    Geplant ist eine automatische Adaptionsfunktion: Du clickst „Änderung übernehmen“, und der Text wird sofort korrigiert. Kein manuelles Umschreiben nötig.

    Optional: Humanisierung durch ZeroGPT Integration

    Ein zusätzliches Sicherheitsnetz ist in Planung – die Integration der ZeroGPT API zur „Humanisierung“ von Texten. Falls ein Text zu sehr nach KI klingt, kann er hier noch einen letzten Schliff bekommen.

    Das ist bewusst optional. Wenn die Tools richtig genutzt werden, sollte dieser Schritt nicht nötig sein. Aber als Auffangnetz für unachtsame Nutzende hat es seinen Wert.

    Die technische Realität: Pragmatismus statt Purismus

    Phase 1: OpenAI API für schnelle Validierung

    Aktuell läuft die Plattform über die Standard-OpenAI-API. Das war die richtige Entscheidung für den Anfang. Schnelle Entwicklung, funktionierender Proof of Concept, beweist den Business Value. Das ist klassisches pragmatisches Bootstrapping.

    Phase 2: Azure OpenAI für Datenschutz-Puristen

    Die nächste Stufe ist die Migration zu Azure OpenAI. Das ist kein Marketing-Fluff – das ist ein fundamentaler Unterschied in regulierten Industrien.

    Mit Azure OpenAI Service bleiben deine Daten in europäischen Rechenzentren. GDPR-Compliance ist nicht optional, sie ist garantiert. Microsoft bietet Enterprise-Grade-SLAs. Du hast Kontrolle über deine Infrastruktur. Das macht die Plattform für Finance, Pharma und andere stark regulierte Sektoren erst diskussionsfähig.

    Phase 3: Self-Hosted für maximale Kontrolle

    Langfristig ist eine vollständig selbst gehostete Lösung (über zum Beispiel Ollama) geplant. Keine externen APIs, keine Cloud-Abhängigkeiten, maximale Kontrolle. Das ist allerdings ein erheblicher Investment-Schritt – in Hardware, in Betriebskompetenz, in Infrastruktur.

    Der pragmatische Pfad: Erst validieren mit OpenAI, dann zu Azure migrieren für besseren Datenschutz, erst dann in Self-Hosting investieren. So wird sichergestellt, dass die Investition sich tatsächlich lohnt, bevor man die Komplexität einer eigenen Infrastruktur auf sich nimmt.

    Warum das für regulierte Unternehmen funktioniert

    Kontrolle statt Shadow-AI: Statt Mitarbeitende mit freiem Zugang zu ChatGPT auszustatten (wo sie alles eingeben können, inklusive sensibler Daten), gibt es eine kontrollierte Plattform mit spezifischen, vordefininierten Use Cases.

    Qualität durch Architektur: Die Systemprompts sind nicht von Hand geschrieben, sondern iterativ optimiert worden. Nutzer müssen keine Prompt-Experten sein – sie beantworten Fragen und bekommen guten Content.

    Was dieses Projekt wirklich zeigt

    An der Oberfläche ist es eine Content-Creation-Suite. Darunter liegt ein System, das die echten Herausforderungen regulierter Unternehmen adressiert: Compliance-Anforderungen, Qualitätssicherung, niedrige Einstiegshürden, intelligente Automatisierung.

    Die zentrale Herausforderung war nicht, ChatGPT zu wrappen. Die Herausforderung war, KI so zu designen, dass sie jeder nutzen kann – unabhängig von technischem Know-how – und gleichzeitig sicherzustellen, dass alle Outputs den Unternehmensstandards entsprechen.

    Das ist nicht „ein paar Custom GPTs basteln“. Das ist ein durchdachtes Ökosystem: spezialisierte Tools, intelligente Verzahnung, automatisierte Qualitätssicherung, progessive Datenschutz-Architektur.

    Was ich anders machen würde

    Die Azure-OpenAI-Migration hätte früher stattfinden sollen. Es ist ein enormer Wettbewerbsvorteil für regulierte Industrien, und der Proof of Concept hätte auf dieser Foundation gebaut werden können statt später zu migrieren. Der initiale Trade-off zwischen schneller Entwicklung und Datenschutz-Puritanismus war pragmatisch, aber im Nachhinein wäre es besser gewesen, beide Anforderungen von Start an zu ernst zu nehmen.

    Auch hätte die Brand Voice Checker Komplexität unterschätzt werden können. Kontextbasierte Prüfung ist knifflig – jede neue Industrie, jedes neue Unternehmen hat andere Anforderungen. Das zu generalisieren ist schwieriger als gedacht.

    Die Key Learnings

    Tools schlagen Plattformen für Enterprise-Adoption: Ein großes, flexibles System verliert gegen spezialisierte, strukturierte Tools. Menschen nutzen lieber etwas, das ihnen genau sagt, was sie eingeben sollen.

    Prompt-Architektur ist ein Produkt-Feature: Gute Systemprompts sind nicht kostenlos. Sie erfordern tiefe Domain-Expertise und iterative Optimierung. Das ist aber genau der Value, den die Plattform bieten kann.

    Content-Verzahnung skaliert Linear: Die Effizienzgewinne entstehen nicht aus einzelnen Tools, sondern aus intelligenter Workflow-Automation zwischen ihnen. Ein Podcast generiert fünf Content-Formate – das ist nicht dreimal so viel Aufwand, sondern 20% Mehraufwand.

  • Meine ersten Gehversuche mit der OpenAI-API

    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.

    1. 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.
    2. 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.
    3. 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.