Prompt Engineering ist tot. Was zählt, ist der Code, der die Antwort des Modells prüft.

Warum der Prompt nicht das Problem löst

Es gibt Berufsbilder, die ihre eigene Ablösung schon im Namen tragen. Der Telefonist. Der Setzer. Der Webmaster. Der Prompt Engineer reiht sich gerade ein.

Das ist keine Provokation. Es folgt aus der Funktionsweise der Technik.

Ein Prompt ist eine Textanweisung an ein Sprachmodell. Das Modell erzeugt seine Antwort aus Wahrscheinlichkeiten. Dieselbe Anweisung mit demselben Input liefert deshalb nicht immer dieselbe Antwort. Für einen Versuch am Schreibtisch ist das in Ordnung. In einem Geschäftsprozess, der jeden Monat einige tausend Mal läuft, ist es ein Betriebsrisiko. Jede abweichende Antwort ist ein Fall, den jemand nachprüfen muss.

Die Unternehmen, die mit KI verlässlich arbeiten, optimieren keine Prompts. Sie bauen Systeme. Sie packen die Antwort des Modells in gewöhnlichen Code, der Fehler abfängt, Ergebnisse prüft und erst dann etwas auslöst. Der Prompt ist darin ein Detail, nicht die Strategie.

Das ist derselbe Schritt, den die Informatik bei jeder neuen Abstraktionsschicht gemacht hat. Niemand schreibt heute noch Maschinencode von Hand. Man baut Werkzeuge, die das übernehmen. Genau das passiert gerade mit Prompts.

Was die Geschichte der Programmierung dazu sagt

In den 1950ern schrieben Programmierer Maschinencode. Jede Anweisung wurde als Zahlenfolge notiert. Fehler waren schwer zu finden.

In den 1960ern kam Assembler. Kurze Befehlswörter ersetzten die Zahlenfolgen. Der Programmierer musste die Hardware aber weiter im Kopf haben.

In den 1970ern und 80ern kamen Hochsprachen wie C und Pascal. Ein Übersetzungsprogramm, der Compiler, erzeugte daraus den Maschinencode. Der Programmierer dachte in Logik, nicht mehr in Registern.

Ab den 1990ern übernahmen Bibliotheken und Frameworks ganze Aufgaben. Niemand schreibt heute noch einen Sortieralgorithmus selbst.

Prompt Engineering ist die Assembler-Phase der KI. Entwickler formulieren Textanweisungen, testen Varianten und sammeln Beispiele, die gerade gut funktionieren. Der Mensch bleibt der Übersetzer zwischen Absicht und Ausführung.

Function Calling, Tool Use und die Aufteilung auf mehrere spezialisierte Agenten sind die Compiler-Phase. Das System übersetzt eine Absicht in eine geprüfte Aktion. Der Mensch legt Ziele und Grenzen fest.

Der entscheidende Punkt: Assembler-Programmierer wurden nicht überflüssig, weil sie schlecht waren. Eine höhere Schicht hat ihre Handarbeit überflüssig gemacht. Dasselbe passiert mit dem Feilen an Prompts.

Wie sich die Arbeit mit Prompts in vier Phasen verändert hat

Phase 1, Prompt-Vorlagen (2022 bis 2023): Unternehmen entdecken, dass die Formulierung der Anweisung die Qualität der Antwort bestimmt. Es entstehen Sammlungen von Rollen-Prompts, Formatanweisungen und Beispielen. Der Mensch ist Prompt-Handwerker.

Phase 2, schrittweises Denken (2023 bis 2024): Forscher zeigen, dass Modelle bessere Ergebnisse liefern, wenn man sie zum Denken in Zwischenschritten auffordert. Die Qualität steigt, die Streuung bleibt. Dieselbe Anweisung liefert morgen ein anderes Ergebnis als heute.

Phase 3, Function Calling (2024 bis 2025): OpenAI, Anthropic und Google bieten strukturierte Ausgabeformate an. Das Modell antwortet nicht mehr mit Fließtext, sondern mit einem Datensatz in einem vorgegebenen Format, etwa “sende E-Mail an diese Adresse mit diesem Betreff”. Der Prompt steuert jetzt Aktionen, nicht Texte.

Phase 4, mehrere Agenten (2025 bis 2026): Einzelne Modellaufrufe werden durch Systeme aus spezialisierten Agenten ersetzt. Ein Agent verteilt die Aufgabe. Einer sammelt Daten. Einer führt aus. Einer prüft das Ergebnis. Die Prompts sind das interne Verbindungsstück zwischen diesen Bausteinen. Niemand außerhalb des Systems sieht sie.

In Phase 1 war der Prompt das Produkt. In Phase 4 ist er ein Detail, das die Architektur erzeugt.

Woran Prompt-only-Systeme im Alltag scheitern

Stell dir vor, ein Prompt verarbeitet eingehende Rechnungen. Meistens liest er die Daten richtig aus. Manchmal erfindet er eine Rechnungsnummer, verwechselt Brutto und Netto oder übersieht eine Position. Bei ein paar hundert Rechnungen im Monat entstehen so jeden Monat Fälle, die jemand von Hand korrigieren muss. Jeder davon verzögert eine Zahlung.

Kein noch so ausgefeilter Prompt löst das Problem. Denn das Problem ist nicht die Formulierung, sondern das Fehlen einer Prüfung. Was hilft, ist eine Prüfschicht aus gewöhnlichem Code: Sie nimmt die Antwort des Modells entgegen, prüft Struktur und Werte und schreibt erst dann etwas ins Zielsystem, wenn alle Prüfungen bestanden sind.

Das Muster, mit dem wir in Projekten arbeiten, hat vier Stufen. Das Modell liest Daten aus. Ein Prüfprogramm kontrolliert, ob alle Felder da sind und den richtigen Typ haben. Ein Regelwerk prüft die Werte gegen die Geschäftsregeln. Ein Sicherheitswert entscheidet, ob das Ergebnis automatisch weiterläuft oder ein Mensch draufschaut. In Projekten sehen wir häufig, dass erst dieser Aufbau aus einem Versuch einen Prozess macht, den man laufen lassen kann. Das Modell wird dabei nicht besser. Die Architektur gleicht seine Schwäche aus.

Merkmal	Nur Prompt	Prompt plus Prüfschicht
Antwortformat	Im Prompt erbeten	Von der Schnittstelle erzwungen
Fehlerbehandlung	Im Prompt, etwa “antworte nicht mit”	Im Code, gegen Schema und Regeln
Fehler im Betrieb	Fällt erst bei Stichproben auf	Wird abgefangen oder an einen Menschen gegeben
Modellwechsel	Alle Prompts neu testen	Modell austauschbar, Prüfung bleibt
Nachvollziehbarkeit	Schwer, Antwort kommt aus dem Modell	Jede Prüfung ist im Protokoll

Ein typischer Fall aus der Kreditprüfung

Ein Finanzdienstleister bearbeitet jeden Monat einige tausend Anträge. Der erste Ansatz ist promptbasiert: Ein Modell liest den Antrag, bewertet das Risiko und schreibt eine Empfehlung als Text. Nach einigen Wochen Feinschliff stimmt die Empfehlung in den meisten Fällen mit den Analysten überein. Das klingt gut, bis man rechnet. Ein zweistelliger Prozentsatz an Abweichungen bedeutet bei einigen tausend Anträgen jeden Monat hunderte Fälle, die jemand nachprüfen muss. Die Nachprüfung frisst die Ersparnis auf.

Der architektonische Ansatz sieht anders aus. Das Modell liest nur strukturierte Daten aus dem Antrag: Name, Einkommen, Bonitätswert, Sicherheiten. Ein festes Regelwerk bewertet das Risiko anhand definierter Schwellen. Ein Nachschlagesystem zieht vergleichbare Fälle aus der eigenen Historie heran. Ein Sicherheitswert entscheidet, ob der Fall automatisch entschieden wird oder an einen Analysten geht.

Der Effekt: Der Großteil der Anträge läuft ohne menschliches Zutun durch. Die Analysten sehen nur noch die Grenzfälle. Wie groß dieser Anteil ist, hängt von deinem Ausgangszustand ab, von der Qualität der Anträge und davon, wie streng du den Schwellenwert setzt.

Der Prompt in diesem System ist trivial. Er lautet sinngemäß: “Lies folgende Felder aus dem Dokument aus.” Keine Rollenbeschreibung, keine ausgefeilten Beispiele. Die Intelligenz sitzt nicht im Prompt. Sie sitzt in dem Code, der die Antwort weiterverarbeitet.

Was das für Kosten und Personal bedeutet

Der Prompt-Ansatz ist schneller gebaut. Der architektonische Ansatz braucht am Anfang mehr Entwicklungszeit, weil Schema, Regelwerk und Schwellenwerte entworfen und getestet werden müssen. Dafür sinkt der laufende Aufwand für Nachprüfung deutlich und die Prüfschicht bleibt bestehen, wenn du das Modell wechselst.

Genau das ist der Grund, warum Stellenanzeigen für Prompt Engineers am Bedarf vorbeigehen. Es erinnert an die Social-Media-Manager um 2012, die den ganzen Tag Beiträge optimierten. Wenige Jahre später war das eine Grundfähigkeit jedes Marketing-Teams und die eigene Stelle verschwand. Gute Prompts schreiben wird in Entwicklerteams so selbstverständlich wie SQL oder Git. Niemand stellt einen Git Engineer ein.

Was Unternehmen stattdessen brauchen: Leute, die Prüfschichten und Regelwerke bauen. Leute, die die Infrastruktur für Agenten betreiben. Leute, die die Datengrundlage für Nachschlagesysteme pflegen. Keine dieser Rollen hat Prompt im Titel.

Die vier Schichten der Prüfschicht

Schicht 1, festes Antwortformat: Das Modell wird nicht nach Text gefragt, sondern nach Daten in einem vorgegebenen Format. Function Calling und Tool Use erzwingen das über die Schnittstelle. Die Fehlerquelle “falsches Format” verschwindet, weil die Schnittstelle nichts anderes annimmt.

Schicht 2, Prüfung gegen ein Schema: Jede Antwort wird gegen eine feste Beschreibung der erwarteten Felder geprüft. Fehlt ein Pflichtfeld, wird sie abgelehnt. Hat ein Feld den falschen Typ, wird sie abgelehnt. Liegt eine Zahl außerhalb des erlaubten Bereichs, wird sie abgelehnt. Das ist keine KI. Das ist gewöhnlicher Code, wie er seit Jahrzehnten geschrieben wird.

Schicht 3, Geschäftsregeln: Geprüfte Daten laufen durch ein Regelwerk. Kreditantrag über einer festgelegten Summe? Zusätzliche Prüfung. Rechnungsbetrag weicht zu stark vom Vertragsbetrag ab? Weiterleitung. Kundenstatus gesperrt? Ablehnung. Diese Regeln sind Geschäftslogik und ändern sich nicht mit dem Modell.

Schicht 4, Sicherheitswert und Weiterleitung: Ein eigener Mechanismus bewertet, wie sicher die Antwort ist. Hohe Sicherheit: automatisch ausführen. Niedrige Sicherheit: ein Mensch entscheidet. Der Schwellenwert steht im Code, nicht im Prompt.

Das Modell macht weiter Fehler. Die Architektur fängt sie ab, so wie ein Compiler Tippfehler abfängt, bevor das Programm läuft.

Warum ein festes Antwortformat die Prompt-Tricks überflüssig macht

Der Prompt-Ansatz für eine Rechnung lautet etwa: “Lies aus der folgenden Rechnung Betrag, Rechnungsnummer und Fälligkeitsdatum aus. Antworte ausschließlich als JSON mit den Schlüsseln amount, invoice_number und due_date. Wenn ein Feld fehlt, setze null. Erfinde keine Werte.”

Das funktioniert meistens. Manchmal antwortet das Modell trotzdem mit Fließtext, erfindet eine Nummer oder schreibt “ca. 1.500 EUR” statt einer Zahl.

Der Ansatz mit festem Format definiert stattdessen eine Funktion mit typisierten Feldern: Betrag als Zahl, Rechnungsnummer als Text, Fälligkeit als Datum. Das Modell muss in diesem Format antworten. Die Schnittstelle lehnt alles andere ab. Die Formatfehler sind damit weg. Die inhaltlichen Fehler fangen Schicht 2 bis 4 ab.

Das ist der Unterschied zwischen einem Prototyp und einem System, das du laufen lassen kannst.

Was du jetzt prüfen kannst

Erstens: Sieh dir deine bestehenden KI-Prozesse an. Wenn einer davon nur auf einem gut formulierten Prompt beruht, ohne Schema, ohne Regelwerk, ohne Schwellenwert für die Weitergabe an einen Menschen, dann läuft ein Prototyp im Echtbetrieb.

Zweitens: Miss die tatsächliche Fehlerquote. Nicht die aus der Vorführung, sondern die aus dem laufenden Betrieb über viele Vorgänge. In Projekten sehen wir häufig, dass diese Zahl niemand kennt. Das allein ist ein Befund.

Drittens: Baue die vier Schichten. Festes Format, Schema-Prüfung, Geschäftsregeln, Schwellenwert. Dieser Aufbau ist unabhängig vom Modell. Erscheint morgen ein besseres, tauschst du es aus und die Prüfung bleibt.

Viertens: Stell keine Prompt Engineers ein. Such Entwickler mit Erfahrung im Umgang mit Sprachmodellen, die Prüfschichten bauen können.

Wenn du unsicher bist, wo dein Prozess zwischen Prototyp und System steht, kannst du das mit uns durchsprechen: Kontakt. Ob sich ein Umbau lohnt, hängt von deinem Ausgangszustand ab und lässt sich nur am konkreten Prozess beantworten.

Weiterführend: Tod der Chatbots | Die Firewall bin ich | Warum dein wertvollster Mitarbeiter ein Vektor ist | Legacy Tax