Von der Alchemie zur Architektur: Die Entwicklung des Prompt Engineerings

1779 wurde über dem Severn in Shropshire, England, die erste große Eisenbrücke der Welt eröffnet. Ihr Architekt Thomas Farnolls Pritchard und der Erbauer Abraham Darby III standen vor einer besonderen Aufgabe: Sie mussten einen völlig neuen Werkstoff, Gusseisen, in einem bis dahin beispiellosen Maßstab im Brückenbau einsetzen. In den 1770er-Jahren gab es zwar schon einige theoretische Ansätze zur Statik, doch Pritchard stützte sich vor allem auf Methoden aus der Zimmerei: Er verband die Eisenteile mit Schwalbenschwänzen und Zapfenverbindungen, weil er nicht wusste, wie man Gusseisen sonst zusammenfügt. Das Ergebnis war massiv überdimensioniert, mit weit mehr Stützen als nötig, aber es funktionierte. Die Brücke steht bis heute, ein Beleg für praktische Ingenieurskunst, bei der Erfahrungswissen und vorsichtiges Konstruieren ausglichen, was der Theorie noch fehlte.

Wenn Kritiker Prompt Engineering als „im Grunde Glücksspiel“ abtun, wiederholen sie ein bekanntes Muster: Sie halten die chaotische empirische Phase einer jungen Disziplin für einen Beweis, dass ihr jede Berechtigung fehlt. Das Feld entwickelt sich aber schneller, als die Skeptiker ahnen, und die Forschung von 2025 zeigt sowohl echte Fortschritte als auch hartnäckige Probleme, die jede ehrliche Bewertung anerkennen muss.

Das Problem der Fragilität

Das Argument der Skeptiker hat etwas für sich. Die KI-Forscherin Maria Sukhareva hält „Prompt Engineering“ wegen der Unberechenbarkeit für eine Fehlbezeichnung: „Es gibt keine richtigen oder falschen Prompts. Die Empfindlichkeit von Prompts, die fehlende Erklärbarkeit und der Zufall in der Ausgabe machen Prompt Engineering im Grunde zu Glücksspiel.“

Eine Studie von Meincke, Mollick und Kollegen aus dem Jahr 2025 untermauert das mit harten Daten. Winzige Änderungen am Prompt (umgestellte Anweisungen, leicht andere Formulierungen, sogar andere Bewertungsmetriken) führten zu drastisch anderen Ergebnissen. Das ist kein anekdotischer Frust, sondern systematische Fragilität, gemessen und dokumentiert.

Dieser Befund sollte jeden Triumphalismus über die Reife von Prompt Engineering dämpfen. Das Feld mag Frameworks und Werkzeuge entwickeln, aber es baut auf grundlegend instabilem Boden.

Theorie, Optimierung und Musterbildung

Wer das Feld ganz abtut, übersieht allerdings echte Entwicklungen. Eine Reihe von Arbeiten aus dem Jahr 2025 zeigt die Verschiebung weg vom reinen Trial-and-Error hin zu systematischen Ansätzen.

Das ACL-Framework von X. Zhang behandelt Prompts als Selektoren über verborgene Zustandstrajektorien und definiert Komplexitätsmaße, die bei Reasoning-Aufgaben Leistungssteigerungen von über 50% ermöglichten. Wang, Moazeni und Klabjan setzten bayessche Optimierung ein, um den Prompt-Raum effizienter zu durchsuchen als durch zufälliges Ausprobieren. Santos und Kollegen untersuchten mit evolutionären Algorithmen, wie strukturelle Merkmale von Prompts mit der Leistung zusammenhängen. Zusammen bilden diese Arbeiten eine frühe Theorie, vergleichbar mit der Balkentheorie im Bauingenieurwesen: Sie versuchen zu erklären, warum bestimmte Prompts funktionieren, statt nur zu dokumentieren, dass sie es tun.

Die Einschränkungen zählen aber. Zhangs Framework wurde vor allem an Reasoning-Benchmarks validiert. Ob es sich auf andere Modelle und Domänen übertragen lässt, ist unbewiesen. Bayessche Optimierung braucht ein erhebliches Rechenbudget, unter Umständen Hunderte von Modellaufrufen pro optimiertem Prompt, was für die meisten Entwicklungsteams nicht praktikabel ist. Musterzuordnungen liefern statistische Tendenzen, keine deterministischen Regeln.

Am aufschlussreichsten ist vielleicht die Arbeit von Dimitri Schreiter zur Spezifität des Vokabulars. Demnach schwankt die optimale Präzision je nach Domäne unvorhersehbar: Allzu technische Sprache verschlechterte manchmal die Leistung bei MINT-Aufgaben, und medizinische Prompts reagierten uneinheitlich auf klinische Terminologie im Vergleich zu laienverständlicher. Die Befunde stammen aus Auswertungen von GPT-3.5 und GPT-4. Ob sie auch für Claude, Gemini oder offene Modelle gelten, ist unbekannt. Das ist die zentrale Schwierigkeit des Felds: Das Wissen wächst, aber ob es sich übertragen lässt, bleibt ungewiss.

Werkzeuge, die Probleme sichtbar machen

GPR-bench von Morishige und Koshihara könnte die praktisch wichtigste Entwicklung sein: Regressionstests für das Verhalten von LLMs. Das Werkzeug verfolgt die Leistung von Prompts über Modellversionen hinweg und zeigt Drift, sobald sie auftritt.

Man sollte aber klar sehen, was das leistet. GPR-bench sagt Ihnen, wann Ihr Prompt nicht mehr funktioniert. Es repariert ihn nicht und erklärt auch nicht, warum er versagt hat. Für die Ursachensuche brauchen Sie weiterhin erfahrene Fachleute: War es ein Modell-Update, eine subtile Empfindlichkeit gegenüber der Formulierung oder eine veränderte interne Repräsentation? Das Werkzeug macht Probleme sichtbar und messbar, und das ist besser als ein Blindflug. Es eine Lösung zu nennen, geht aber über das hinaus, was es derzeit gibt.

Neuere Arbeiten aus dem Team von Mira Murati weisen in eine andere Richtung: LLMs deterministisch machen. Heute können identische Prompts selbst bei einer auf null gesetzten Temperature leicht unterschiedliche Ausgaben liefern, weil der Sampling-Prozess subtil nichtdeterministisch ist. Muratis Gruppe experimentiert mit Techniken, die bei identischen Eingaben identische Ausgaben garantieren. Damit würden Prompts zu reproduzierbaren Anweisungen statt zu probabilistischen Wetten.

Bei breiter Verwendung wäre das ein echter Umbruch. Die Empfindlichkeit von Prompts gegenüber Formulierung oder Kontext bliebe, aber eine Dimension der Variabilität wäre stabilisiert, die der Kritik „Prompt Engineering ist Glücksspiel“ Nahrung gegeben hat. Deterministische Ausgaben würden Regressionstest-Frameworks wie GPR-bench weit leistungsfähiger machen: Wenn ein Prompt versagt, wüssten Sie, dass Modelländerungen oder Designfehler die Ursache sind und nicht zufällige Varianz.

Die Einschränkung: Im großen Maßstab ist das noch nicht im Einsatz, und welchen Preis es hat, ist unklar. Determinismus könnte etwa die Vielfalt der Ausgaben bei kreativen Aufgaben verringern. Trotzdem ist es einer der konkretesten Schritte dahin, LLMs als berechenbare technische Komponenten zu behandeln.

Das Problem der Reproduzierbarkeit unterscheidet sich außerdem stark je nach Deployment-Modell. Bei Open-Weight-Systemen (Llama, Mistral) können Teams Versionen festschreiben und Konsistenz erreichen, verzichten dafür aber auf Verbesserungen. Bei reinen API-Anbietern (OpenAI, Anthropic) sind Sie von deren Versionierung und Update-Zeitplänen abhängig.

Wie das tatsächlich aussieht

Nehmen wir ein konkretes Szenario: Ein mittelgroßes SaaS-Unternehmen setzt Claude ein, um Kundensupport-E-Mails zu klassifizieren und Antworten zu entwerfen. Zunächst schreibt sein Prompt Engineer die Anweisungen per Trial-and-Error und testet Varianten, bis die Genauigkeit 85% erreicht. Das funktioniert, bis Claude ein Update bekommt.

Mit GPR-bench bemerkt das Team die Verschlechterung sofort: Die Genauigkeit fällt auf 72%. Aber was jetzt? Das Unternehmen braucht jemanden, der sowohl das Fachwissen aus dem Kundensupport als auch das Verhalten von LLMs versteht, um zu klären, ob es an der Empfindlichkeit gegenüber Formulierungen, an veränderten Modellfähigkeiten oder an Effekten des Kontextfensters liegt. Das Team könnte Sasakis Muster-Taxonomie anwenden, um den Prompt umzubauen, mit reflexiven Techniken aus Djeffals Arbeit eine Selbstkorrektur einbauen oder anhand von Schreiters Befunden zur Spezifität des Vokabulars die Terminologie anpassen.

Das ist systematischer als das Vorgehen von 2023: Es gibt Frameworks, Werkzeuge und dokumentierte Muster. Klassisches Engineering ist es aber nicht. Jede Korrektur verlangt Ermessensentscheidungen, Fachwissen und schrittweises Nachbessern. Die Muster helfen, bis sie es nicht mehr tun. Die Werkzeuge zeigen Probleme, aber jemand muss sie fachkundig deuten. Und bei alldem kann im nächsten Monat ein weiteres Modell-Update wieder alles kaputt machen.

Rechnen Sie das auf eine Organisation mit Dutzenden LLM-gestützten Funktionen hoch, und die Rolle des „Prompt Engineers“ wird klar: Das ist niemand, der deterministischen Rezepten folgt, sondern jemand, der sich in probabilistischen Systemen mit Frameworks zurechtfindet, die die Chancen verbessern, ohne Ergebnisse zu garantieren.

Die Frage nach dem Beruf

Das führt zur entscheidenden Frage: Ist „Prompt Engineering“ ein dauerhafter Beruf oder eine Kompetenz für den Übergang? Die Bezeichnung wird wohl nicht bleiben. Je besser Modelle Anweisungen befolgen, desto eher dürfte die Spezialrolle zerfallen: Manche Techniken gehen im UX-Design auf (Conversational Interfaces), manche in der Softwareentwicklung (Workflow-Orchestrierung), manche in der Spezialisierung auf einzelne Domänen (juristische, medizinische, technische Anwendungen).

Denken Sie an SQL in den 1990er-Jahren. Anfangs war „Datenbankprogrammierer“ eine eigene Rolle. Irgendwann wurde das Schreiben von Abfragen zu einer Fähigkeit, die sich auf Analysten, Entwickler und Fachleute verteilte. Prompt Engineering scheint sich in dieselbe Richtung zu bewegen: Die Fähigkeiten bleiben und entwickeln sich weiter, aber die Berufsbezeichnung markiert eine Übergangsphase, in der die Praxis systematisiert wird, bevor sie sich auf andere Disziplinen verteilt.

Die Wette lautet nicht, ob Prompt Engineering verschwindet. Das wird es nicht. Die Wette lautet, ob daraus eine eigene berufliche Identität wird oder eine Sammlung von Techniken, die in bestehenden Rollen zum Einsatz kommen. Die aktuellen Trends sprechen für Letzteres.

Die probabilistische Grenze

Das Bild der Iron Bridge zeigt gut, wie die praktische Ingenieursarbeit der Theorie vorausgeht. An einem grundlegenden Punkt trägt es aber nicht mehr: Der Brückenbau fand schließlich zu gemeinsamen Prinzipien, weil sich physische Materialien unter bekannten Kräften vorhersehbar verhalten. Sprachmodelle sind probabilistische Systeme, trainiert auf gelernten Repräsentationen, die wir nicht vollständig verstehen.

Die „Theorie“, die im Prompt Engineering entsteht, wird der Strukturmechanik mit ihren deterministischen Gleichungen vielleicht nie ähneln. Sie könnte immer eher der Ökonomie oder der Verhaltenspsychologie gleichen: Frameworks, die Ergebnisse verbessern, ohne Garantien zu geben. Zhangs Komplexitätsmaße, bayessche Optimierung, Muster-Taxonomien: Sie helfen, aber sie arbeiten an Systemen, für die die Fragilitätsbefunde von Meincke und Mollick im Grunde weiter gelten.

Das entwertet die Arbeit nicht. Es bedeutet, dass wir systematische Ansätze für von Natur aus unsichere Systeme entwickeln, und die sind auch ohne die Vorhersagbarkeit klassischen Engineerings wertvoll. Wir sollten aber klar sagen, was erreichbar ist: bessere Methoden, um probabilistische Ergebnisse zu verbessern, keine deterministische Kontrolle.

Der aktuelle Stand

So sieht es aus: Die Forschung von 2025 zeigt echte Fortschritte, nämlich frühe theoretische Frameworks, Optimierungsmethoden, Monitoring-Werkzeuge und Musterbibliotheken. Sie machen Prompt Engineering systematischer als reine Empirie. Erfahrene Praktiker haben heute bessere Ressourcen und Frameworks als 2023.

Systematisch heißt aber nicht gelöst. Zhangs Theorie braucht eine Validierung über Reasoning-Benchmarks hinaus. Bayessche Optimierung verlangt Ressourcen, die den meisten Teams fehlen. GPR-bench zeigt Probleme, ohne sie zu lösen. Musterbibliotheken helfen, bis sie auf Randfälle treffen. Und die Fragilität, die Meincke und Mollick dokumentiert haben, bleibt bestehen, egal wie gut die Werkzeuge werden.

Das Feld sammelt Wissen und baut Infrastruktur auf, bleibt dabei aber grundlegend empirisch und kontextabhängig. Glücksspiel ist das nicht: Erfahrene Praktiker schneiden durchgängig besser ab als Anfänger, was bei reinem Zufall nicht der Fall wäre. Klassisches Engineering ist es aber auch nicht.

Vielleicht passt dieser Rahmen am besten: Prompt Engineering reift zu einer Disziplin, die ihrem Gegenstand entspricht, also zu systematischen Ansätzen, mit denen sich Ergebnisse bei probabilistischen Systemen verbessern lassen, die man nicht vollständig kontrolliert. Die Frameworks, die 2025 entstehen, sind echter Fortschritt. Sie machen die Praxis besser lehrbar, besser übertragbar und verlässlicher. Sie beseitigen aber nicht (und können es wohl auch nicht) die Notwendigkeit eines geschulten menschlichen Urteils im Umgang mit unvermeidlicher Unsicherheit.

Die Frage ist nicht, ob Prompt Engineering „echt“ ist. Die Frage ist, ob die professionelle Infrastruktur, die gerade entsteht, mit den praktischen Anforderungen Schritt halten kann und ob Organisationen in diese Infrastruktur investieren oder sie als vorübergehenden Notbehelf behandeln, bis die Modelle „besser werden“.

Nach dem Verlauf von 2025 zu urteilen, finden wir das gerade heraus. Anders als bei der Iron Bridge, die bewies, dass Eisen funktioniert, und eine ganze Industrie in Gang setzte, können wir aber noch nicht sicher sein, dass diese Fundamente halten.

Aus dem Englischen übersetzt: zum Originalbeitrag