Ein Buzzword auf dem Rückzug
2023 hatten plötzlich alle einen neuen Berufstitel auf LinkedIn: Prompt Engineer. Es gab Kurse für 2.000 Euro, „Prompt Libraries" als SaaS-Produkte und Stellenausschreibungen mit Gehältern jenseits der 200.000 Dollar. Der Tenor: Wer die richtigen Worte für ein Modell findet, hat einen entscheidenden Wettbewerbsvorteil.
Drei Jahre später ist von diesem Hype wenig übrig. Nicht weil das zugrunde liegende Problem verschwunden wäre – sondern weil sich gezeigt hat, dass die Wahl der Worte nur ein winziger Teil der Aufgabe war. Der eigentliche Hebel liegt anderswo.
Was Prompt Engineering richtig gesehen hat
Es wäre unfair, Prompt Engineering rückblickend abzutun. Der Begriff hat eine wichtige Einsicht popularisiert: LLMs sind keine Suchmaschinen, sondern Sprachsysteme, die auf Kontext reagieren. Die Art, wie man eine Frage stellt, beeinflusst die Antwort dramatisch. Few-Shot-Beispiele, klare Instruktionen, strukturierte Aufgabenbeschreibungen – das alles sind Techniken, die heute zum Handwerkszeug jeder seriösen KI-Entwicklung gehören.
Das Problem war nicht die Idee. Das Problem war die Reduktion auf einen einzelnen Textbaustein – als ob die ganze Disziplin daraus bestünde, drei Sätze in einem Eingabefeld zu polieren. Echte Anwendungen funktionieren nicht so. Sie haben System-Prompts, Tools, abgerufene Daten, Gesprächsverlauf, strukturierte Output-Formate, Caching-Strategien und Eskalationspfade. Der „Prompt" ist davon vielleicht zehn Prozent.
Was Context Engineering meint
Context Engineering ist der breitere Begriff für das, was tatsächlich passiert, wenn man ein LLM in Produktion bringt. Er umfasst alles, was im Kontextfenster landet, bevor das Modell antwortet:
System-Prompt: Die Rolle, die Leitplanken, die Stilvorgaben. Selten der Hebel, der über Erfolg oder Misserfolg entscheidet, aber das Fundament, auf dem alles andere aufbaut.
Retrieval: Welche Dokumente, Datensätze oder Code-Schnipsel aus internen Quellen geholt werden, bevor das Modell antwortet. Die Qualität dieses Schritts ist in den meisten Anwendungen wichtiger als jede Prompt-Optimierung.
Tools: Welche Funktionen das Modell aufrufen kann – Datenbankabfragen, API-Calls, Berechnungen, Suchen. Das richtige Tool im richtigen Moment ersetzt seitenweise Prompt-Anweisungen.
Gesprächsverlauf: Was aus früheren Turns mitgeführt wird, was zusammengefasst wird, was verworfen wird. Bei längeren Sessions oft der entscheidende Faktor für Konsistenz.
Output-Schema: Strukturierte JSON-Antworten statt freier Prosa. Erspart Parsing, reduziert Fehler, macht Pipelines robust.
Memory: Persistente Informationen zwischen Sessions – Nutzerpräferenzen, frühere Entscheidungen, projektspezifischer Kontext. Inzwischen ein eigenes Subsystem, kein Teil des Prompts mehr.
Wer von „Prompt Engineering" spricht, meint heute meist eines dieser Felder – oder verwechselt sie. Context Engineering trennt sie sauber.
Wo der eigentliche Hebel liegt
In unserer Praxis ist die Reihenfolge klar: Bessere Daten schlagen bessere Worte. Konkret heißt das:
Besseres Retrieval > besserer Wortlaut. Ein RAG-System, das die richtigen drei Dokumente findet, liefert mit einem mittelmäßigen Prompt bessere Antworten als ein perfekt formulierter Prompt mit den falschen Quellen. Wir haben mehrfach erlebt, dass Tage in Prompt-Tuning gesteckt wurden, während das eigentliche Problem ein schlecht konfigurierter Vector Store war.
Richtige Tools > clevere Instruktionen. Wenn ein Agent eine Berechnung machen soll, gib ihm einen Calculator. Wenn er aktuelle Daten braucht, gib ihm einen API-Call. Tausend Worte Prompt, die das Modell überreden sollen, Mathematik richtig zu machen, sind durch eine zehnzeilige Tool-Definition ersetzbar – und zuverlässiger.
Strukturierter Output > Prosa-Parsing. „Antworte im folgenden JSON-Format" ist eine Notlösung. Ein erzwungenes Output-Schema über die API ist Standard. Wer in Produktion noch reguläre Ausdrücke auf LLM-Output anwendet, hat ein Architekturproblem, kein Prompt-Problem.
Eviction-Strategie > Kontextfenster vollstopfen. Selbst bei einer Million Token muss man entscheiden, was reinkommt. Ältere Turns zusammenfassen, irrelevante Tool-Outputs verwerfen, Memory selektiv nachladen. Wer alles reinkippt, bekommt schlechtere Ergebnisse, höhere Kosten und langsamere Antworten.
Warum lange Kontextfenster die Disziplin nicht beerdigt haben
2024 dachten viele, das Problem löse sich von selbst. Wenn ein Modell eine Million Token verarbeiten kann, kippe man eben das gesamte Firmen-Wiki rein und sei fertig. Das hat sich als Trugschluss erwiesen.
Erstens leiden Modelle bei voller Kontextlänge unter Aufmerksamkeitsproblemen – relevante Information mitten in 800.000 Token findet das Modell oft nicht zuverlässig. Zweitens explodieren Kosten und Latenz. Drittens ist der „Lost in the Middle"-Effekt empirisch dokumentiert: Was zwischen Anfang und Ende steht, wird systematisch schlechter berücksichtigt.
Lange Kontexte haben Context Engineering nicht abgeschafft, sondern verschoben. Statt „Wie passt das alles rein?" lautet die Frage jetzt „Was gehört wo hin, damit das Modell es nutzen kann?". Das ist mehr Arbeit, nicht weniger.
Häufige Fehler
Aus unseren Projekten kristallisieren sich Muster, die immer wieder schiefgehen:
Überfüllter Kontext: Teams werfen vorsichtshalber alles rein, was relevant sein könnte. Das Modell wird langsamer, teurer und ungenauer. Weniger ist fast immer mehr.
Keine Eviction-Strategie: Bei langen Sessions wächst der Kontext unkontrolliert, bis er ans Limit stößt. Dann fliegt willkürlich etwas raus – meist das Falsche. Wer sich nicht aktiv um Verdrängung kümmert, übergibt diese Entscheidung dem Zufall.
Vermischte Rollen: System-Prompt, Nutzer-Eingabe und Tool-Outputs werden in eine einzige Textwurst geschrieben, statt die Rollen sauber zu trennen. Modelle reagieren empfindlich darauf – und Sicherheitslücken wie Prompt Injection werden viel schwieriger zu verhindern.
Statisches Retrieval: Einmalige Vektor-Suche am Anfang eines Gesprächs, danach nichts mehr. In komplexen Aufgaben ändert sich der Informationsbedarf – Retrieval muss dynamisch und mehrstufig sein.
Kein Logging des Kontexts: Wenn ein Output schiefgeht und niemand weiß, was genau im Kontextfenster stand, ist Debugging unmöglich. Den vollständigen Kontext zu protokollieren ist nicht optional, sondern Voraussetzung für stabile Systeme.
Was Teams jetzt brauchen
Die Skills, die heute den Unterschied machen, sind nicht „Prompt-Wizardry". Es sind klassische Engineering-Disziplinen, angewendet auf einen neuen Stack:
Information Retrieval: Solides Verständnis von Embedding-Modellen, hybriden Suchstrategien, Reranking, Chunk-Größen. Weniger glamourös als Prompt-Tweaking, aber wirkungsvoller.
API-Design: Tool-Definitionen sind APIs für Modelle. Wer schon mal saubere REST-APIs entworfen hat, hat einen Vorsprung.
Datenmodellierung: Output-Schemas, strukturierte Eingaben, Pydantic- oder Zod-Definitionen. Klassisches Backend-Handwerk.
Observability: Logging, Tracing, Evaluation-Pipelines. Ohne lässt sich kein Kontextsystem im Betrieb verbessern.
Wir bei nh labs stellen seit Mitte 2025 keine „Prompt Engineers" mehr ein – nicht weil wir die Aufgabe nicht hätten, sondern weil sie ein Teilaspekt von Software-Engineering geworden ist. Die besten Ergebnisse erzielen Entwickler, die saubere Systeme bauen können, nicht Texter mit ChatGPT-Erfahrung.
Fazit
Prompt Engineering verschwindet nicht – es schrumpft auf seine tatsächliche Größe. Es ist ein Werkzeug im Werkzeugkasten, kein eigenständiger Beruf. Was bleibt und an Bedeutung gewinnt, ist die Fähigkeit, das gesamte Kontextfenster bewusst zu gestalten: was reinkommt, in welcher Form, in welcher Reihenfolge, mit welchen Tools, in welchem Schema. Wer das beherrscht, baut zuverlässige KI-Systeme. Wer noch Prompts poliert, optimiert das letzte Prozent, während die ersten neunzig brachliegen. Der Begriff Context Engineering wird nicht für immer bleiben – die Disziplin dahinter schon.