Prompt Engineering ist keine Strategie

In vielen Unternehmen wird derzeit viel Zeit darauf verwendet, bessere Prompts zu schreiben. Workshops werden gebucht, Prompt-Bibliotheken angelegt, Teams geschult. Die Annahme dahinter: Wenn wir nur die richtigen Formulierungen finden, werden unsere KI-Anwendungen endlich das tun, was wir brauchen.

Diese Annahme greift zu kurz.

Prompt Engineering ist ein Werkzeug – kein strategisches Fundament. Wer hofft, durch geschicktere Prompts grundlegende Unklarheiten zu umgehen, wird feststellen, dass die Ergebnisse schwanken, Anwendungen nicht skalieren und die erhoffte Produktivität ausbleibt.

Das Problem liegt selten am Prompt. Es liegt daran, was vor dem Prompt nicht geklärt wurde.

Warum Prompts keine Anforderungen ersetzen

Ein Prompt ist im Kern eine Anweisung an ein Sprachmodell. Er beschreibt, was das Modell tun soll, manchmal auch wie. Was er nicht leisten kann: herausfinden, was Sie eigentlich wollen.

Wenn eine Fachabteilung nicht genau weiß, welche Fälle ein System abdecken soll, welche Ausnahmen es gibt, welche Qualität akzeptabel ist – dann fehlt diese Klarheit auch im Prompt. Oder schlimmer: Der Prompt suggeriert Klarheit, die nicht existiert.

Das führt zu einem bekannten Muster bei KI-Projekten mit Sprachmodellen: Die ersten Demos funktionieren. Die Pilotphase zeigt vielversprechende Ergebnisse. Aber sobald das System in den echten Betrieb geht, häufen sich Randfälle, unerwartete Ausgaben, Beschwerden.

Der Reflex ist dann oft, den Prompt zu verbessern. Noch präzisere Formulierungen. Noch mehr Beispiele. Noch längere Anweisungen.

Manchmal hilft das kurzfristig. Aber es behandelt Symptome, nicht Ursachen. Denn das eigentliche Problem ist nicht die Formulierung – es ist das fehlende Fundament darunter.

Was Prompt Engineering leisten kann – und was nicht

Prompt Engineering hat seinen Platz. Es ist sinnvoll, wenn Sie bereits wissen:

• Welchen fachlichen Zweck die Anwendung erfüllen soll
• Welche Eingaben zu erwarten sind und in welcher Qualität
• Welche Ausgaben akzeptabel sind und welche nicht
• Welche Randfälle existieren und wie damit umgegangen werden soll
• Wer die Anwendung nutzt und mit welchen Erwartungen

Wenn diese Fragen beantwortet sind, hilft Prompt Engineering dabei, die Antworten in eine Form zu bringen, die ein Sprachmodell verarbeiten kann. Es ist eine Übersetzungsleistung.

Was Prompt Engineering nicht leisten kann:

• Fachliche Unklarheiten auflösen
• Anforderungen ermitteln, die niemand dokumentiert hat
• Entscheidungen treffen, die das Unternehmen nicht getroffen hat
• Konsistenz herstellen, wo keine Konsistenz definiert ist

Diese Unterscheidung ist zentral. Sie erklärt, warum manche Teams mit relativ einfachen Prompts verlässliche Ergebnisse erzielen – während andere trotz ausgefeilter Prompt-Strategien kämpfen.

Der Unterschied liegt nicht in der Prompt-Kompetenz. Er liegt in der Klarheit, die vor dem Prompt existiert.

Typische Fehleinschätzungen bei KI-Prompts in der Softwareentwicklung

Drei Annahmen begegnen uns häufig, die zu Problemen führen:

Annahme 1: Das Modell versteht den Kontext

Sprachmodelle haben kein Verständnis Ihres Unternehmens, Ihrer Prozesse oder Ihrer Kunden. Sie haben statistisch gelernte Muster. Wenn Ihr Prompt nicht explizit macht, welche Regeln gelten, welche Ausnahmen existieren, welche Begriffe wie verwendet werden – dann arbeitet das Modell mit Annahmen. Diese Annahmen können zufällig passen. Oder auch nicht.

Annahme 2: Mehr Beispiele lösen das Problem

Few-Shot-Prompting – also das Mitgeben von Beispielen – ist eine etablierte Technik. Aber sie funktioniert nur, wenn die Beispiele die relevanten Muster abdecken. Wenn Sie selbst nicht systematisch erfasst haben, welche Fälle es gibt, werden Ihre Beispiele Lücken haben. Das Modell generalisiert dann auf Basis unvollständiger Information.

Annahme 3: Die Fachabteilung kann das nebenbei machen

In manchen Unternehmen wird erwartet, dass Fachabteilungen ihre eigenen Prompts entwickeln. Das kann funktionieren – aber nur, wenn vorher jemand die Anforderungen strukturiert hat. Ohne diese Struktur entstehen individuelle Lösungen, die nicht zusammenpassen, nicht wartbar sind und bei Personalwechsel verschwinden.

Der Zusammenhang zwischen Fachlichkeit und Prompt-Qualität

Gute Prompts sind ein Ausdruck fachlicher Klarheit. Sie entstehen nicht durch Kreativität beim Formulieren, sondern durch Präzision beim Denken.

Ein Beispiel: Ein Unternehmen möchte eingehende Kundenanfragen automatisch kategorisieren. Der erste Prompt-Versuch lautet sinngemäß: "Kategorisiere die folgende Anfrage."

Das funktioniert – manchmal. Aber die Kategorien schwanken. Manche Anfragen landen in falschen Kategorien. Die Fachabteilung ist unzufrieden.

Die Reaktion: Der Prompt wird erweitert. Kategorien werden aufgelistet. Definitionen ergänzt. Beispiele hinzugefügt. Der Prompt wächst auf zwei Seiten.

Die Ergebnisse werden etwas besser. Aber neue Probleme entstehen: Anfragen, die in mehrere Kategorien passen könnten. Anfragen, die in keine passen. Kategorien, die sich überschneiden.

Das eigentliche Problem: Das Kategoriensystem selbst war nie sauber definiert. Es ist historisch gewachsen, inkonsistent, von verschiedenen Personen unterschiedlich verstanden. Kein Prompt kann diese Unschärfe auflösen – er kann sie nur sichtbar machen.

Die Lösung lag nicht im Prompt Engineering. Sie lag darin, das Kategoriensystem zu überarbeiten. Die Fachlichkeit zu klären. Erst danach wurde der Prompt fast trivial.

Wann LLM-Prompt-Fehler auf tiefere Probleme hinweisen

Bestimmte Muster bei Prompt-Problemen deuten darauf hin, dass die Ursache nicht im Prompt liegt:

Schwankende Ergebnisse bei scheinbar ähnlichen Eingaben: Wenn das Modell bei vergleichbaren Anfragen unterschiedlich reagiert, fehlt oft eine klare Definition, was "ähnlich" bedeutet und wie damit umgegangen werden soll.

Endlose Prompt-Iterationen ohne Stabilisierung: Wenn jede Anpassung neue Probleme erzeugt, ist das Gesamtsystem möglicherweise nicht prompt-fähig strukturiert. Die Anforderungen widersprechen sich oder sind zu komplex für einen einzelnen Prompt.

Hohe Abhängigkeit von einzelnen Personen: Wenn nur bestimmte Mitarbeiter "gute Prompts" schreiben können, liegt das oft daran, dass diese Personen implizites Wissen haben, das nie dokumentiert wurde. Das ist kein Prompt-Problem – es ist ein Wissensmanagement-Problem.

Ständige Ausnahmen und Sonderfälle: Wenn der Prompt immer länger wird, weil ständig neue Ausnahmen hinzukommen, war die ursprüngliche Systematik möglicherweise unvollständig. Ausnahmen sind normal – aber sie sollten vorher bekannt sein, nicht erst im Betrieb entdeckt werden.

Was vor dem ersten Prompt geklärt sein sollte

Bevor Zeit in Prompt Engineering investiert wird, lohnen sich grundlegendere Fragen:

Was soll das System konkret leisten? Nicht abstrakt ("Effizienz steigern"), sondern konkret: Welche Eingabe führt zu welcher Ausgabe? Was passiert in Grenzfällen?

Wer nutzt das System und mit welchen Erwartungen? Ein System für Sachbearbeiter hat andere Anforderungen als eines für Kunden. Die Fehlertoleranz unterscheidet sich. Die Qualitätskriterien auch.

Welche Qualität ist akzeptabel? Bei manchen Anwendungen ist 80% Genauigkeit ausreichend. Bei anderen nicht. Diese Entscheidung muss vor dem Prompt getroffen werden – nicht danach anhand von Beschwerden korrigiert.

Wie wird mit Fehlern umgegangen? Jedes System produziert Fehler. Die Frage ist, wie sie erkannt, korrigiert und verhindert werden. Ein guter Prompt macht Unsicherheit transparent. Aber was dann damit passiert, ist eine organisatorische Frage.

Wie sieht der Lebenszyklus aus? Anforderungen ändern sich. Prozesse ändern sich. Wer pflegt den Prompt? Wer entscheidet über Anpassungen? Wer testet?

Diese Fragen haben nichts mit Prompt Engineering zu tun. Sie haben mit solider Vorarbeit zu tun – der gleichen Vorarbeit, die bei jeder Softwareentwicklung notwendig ist.

Der Unterschied zwischen Taktik und Strategie

Prompt Engineering ist taktisch. Es optimiert, wie eine bestehende Lösung funktioniert. Es verbessert Formulierungen, testet Varianten, misst Ergebnisse.

Strategie ist etwas anderes. Sie entscheidet, welche Probleme gelöst werden sollen. In welcher Reihenfolge. Mit welchen Mitteln. Zu welchem Zweck.

Wenn Prompt Engineering zur Strategie erklärt wird, fehlt oft beides: Die taktische Arbeit wird überfrachtet mit Erwartungen, die sie nicht erfüllen kann. Und die strategische Arbeit findet nicht statt, weil alle mit Prompts beschäftigt sind.

Das Ergebnis sind Projekte, die technisch funktionieren, aber fachlich am Ziel vorbeigehen. Oder die fachlich sinnvoll wären, aber technisch instabil bleiben.

Der Ausweg ist nicht komplexeres Prompt Engineering. Er ist Klarheit über Anforderungen, bevor die erste Zeile Prompt geschrieben wird.

Handlungsempfehlungen

Trennen Sie Anforderungsarbeit von Prompt-Arbeit: Beides ist wichtig, aber es sind verschiedene Tätigkeiten mit verschiedenen Kompetenzen. Die Fachabteilung definiert, was das System tun soll. Jemand mit technischem Verständnis übersetzt das in Prompts.

Dokumentieren Sie Anforderungen technologieneutral: Schreiben Sie auf, was das System leisten soll – unabhängig davon, ob ein Sprachmodell, eine Datenbank oder ein Regelwerk dahinter steht. Diese Dokumentation ist auch dann wertvoll, wenn Sie später die Technologie wechseln.

Investieren Sie in Randfälle: Die meisten Prompts funktionieren für den Standardfall. Qualität zeigt sich im Umgang mit Ausnahmen. Sammeln Sie systematisch Randfälle, bevor Sie den Prompt schreiben – nicht danach.

Messen Sie Ergebnisse an fachlichen Kriterien: Nicht daran, wie clever der Prompt ist. Sondern daran, ob das System tut, was es soll. Wenn die Kriterien unklar sind, klären Sie sie zuerst.

Fazit

Prompt Engineering hat seinen Platz. Es ist ein nützliches Werkzeug, um gut definierte Anforderungen in eine Form zu bringen, die Sprachmodelle verarbeiten können.

Was es nicht leisten kann: Klarheit erzeugen, die vorher nicht existiert. Anforderungen ersetzen, die niemand dokumentiert hat. Entscheidungen abnehmen, die das Unternehmen treffen muss.

Gute Prompts entstehen aus Klarheit – nicht umgekehrt. Wer diese Reihenfolge beachtet, spart sich Iterationen, reduziert Frustrationen und erhöht die Wahrscheinlichkeit, dass KI-Projekte tatsächlich den erhofften Nutzen bringen.

Die wichtigste Frage ist nicht: Wie formulieren wir den Prompt? Sondern: Was soll das System eigentlich tun – und für wen?