Prompt Engineering erreicht Grenzen – Context Engineering gewinnt an Bedeutung

Warum die Art der Fragestellung nicht mehr ausreicht

---

Management Summary

Kernbotschaft: Die Ära des Prompt Engineering als alleinige Königsdisziplin im Umgang mit KI-Systemen neigt sich dem Ende zu. Unternehmen, die heute noch übermäßig Ressourcen in die Optimierung einzelner Prompts investieren, verschenken Potenziale. Der entscheidende Erfolgsfaktor für KI-Systeme ist nicht mehr ausschließlich wie man fragt, sondern zunehmend was das System bereits weiß. Context Engineering – die systematische Bereitstellung relevanter Informationen, Rahmenbedingungen und Wissensschatten – entwickelt sich zum neuen Differenzierungsmerkmal. Organisationen, die Kontext beherrschen, erzielen nachweislich bessere Ergebnisse.

---

Einleitung: Das falsche Problem adressiert

Erinnern Sie sich an die ersten Gehversuche mit ChatGPT? Wahrscheinlich wurden Stunden damit verbracht, Prompts zu formulieren, zu testen und zu verfeinern. Eventuell wurden sogar Kurse erworben, die die „perfekte Prompt-Struktur“ versprachen. Drei magische Worte am Anfang. Spezifische Anweisungen zur Formatierung. Die berühmt-berüchtigten „Chain-of-Thought“-Techniken.

Die Praxis zeigt: Bei der Integration von KI-Systemen in Unternehmensprojekte lag die Überzeugung lange Zeit in der Optimierung der Formulierung. Mit Dutzenden produktiven KI-Implementierungen bei mittelständischen und DAX-Konzernen im Rücken zeichnet sich eine andere Erkenntnis ab: Es wurde das falsche Problem adressiert. Die zentrale Frage ist nicht, wie die perfekte Anweisung formuliert wird. Die Frage ist, warum dem System so wenig Kontext gegeben wird, dass es auf die perfekte Anweisung angewiesen ist.

Das Problem liegt nicht im Prompting an sich. Das Problem ist, dass das Modell nicht versteht, worum es geht.

---

Was ist Prompt Engineering? (Und warum es an seine Grenzen stößt)

Prompt Engineering bezeichnet die Kunst und Wissenschaft, Eingaben für Large Language Models (LLMs) so zu formulieren, dass sie optimale Ausgaben erzeugen. Die Grundidee: Durch geschickte Formulierung, Strukturierung und technische Methoden (wie Few-Shot-Beispiele oder Chain-of-Thought-Aufforderungen) lässt sich die Leistung eines Modells erheblich steigern.

Dies funktionierte auch. Zumindest vor zwei Jahren. Als GPT-3.5 die Szene eroberte, war Prompt Engineering der Schlüssel zur Schatzkammer. Mit den richtigen Techniken konnte man aus einem allgemeinen Sprachmodell spezialisierte Assistenten zaubern.

Das Problem dabei:

Prompt Engineering behandelt das Symptom, nicht die Ursache. Es geht davon aus, dass das Modell grundsätzlich in der Lage wäre die richtige Antwort zu geben, wenn es nur richtig gefragt würde. Das ist bei vielen realen Geschäftsanwendungen schlicht falsch.

Ein Fallbeispiel aus der Industrie zeigt die Problematik: Ein mittelständischer Maschinenbauer wollte den Kundenservice mit KI unterstützen. Der Plan: Ein Chatbot sollte technische Fragen zu Pumpen beantworten. Monate wurden in Prompt-Optimierung investiert. „Sei ein freundlicher Support-Mitarbeiter. Antworte präzise. Wenn du etwas nicht weißt, sage es ehrlich. Nutze diese spezifische Terminologie…“

Das Ergebnis? Der Bot war höflich, gut strukturiert – und halluzinierte bei jedem zweiten technischen Detail. Grund: Er kannte die Pumpen nicht. Nicht wirklich. Es fehlte der Kontext über die spezifischen Baureihen, die Wartungsintervalle, die bekannten Fehlerbilder.

Prompt Engineering hat drei fundamentale Grenzen:

1. Es kann kein Wissen ersetzen. Ein Modell, das Produkte nicht kennt, wird sie auch nicht durch bessere Prompts verstehen.
2. Es skaliert schlecht. Jeder neue Use Case erfordert neue Prompt-Experimente. Neue Modelle erfordern neue Prompt-Anpassungen.
3. Es ist zerbrechlich. Kleine Änderungen an der Eingabe können große Änderungen in der Ausgabe bewirken. Das ist im Enterprise-Betrieb untragbar.

---

Was ist Context Engineering? Der neue Ansatz

Context Engineering verschiebt den Fokus vom wie zum was. Statt zu optimieren, wie man fragt, optimiert man, was das System weiß, bevor es antwortet.

Die Kernidee ist denkbar simpel: Ein Large Language Model ist eine Inferenzmaschine über Text. Je relevanter, strukturierter und vollständiger der Kontext, desto besser die Inferenz. Context Engineering systematisiert die Bereitstellung dieses Kontexts.

Dabei geht es nicht nur darum, „mehr Informationen reinzuschieben“. Context Engineering ist eine Ingenieursdisziplin mit mehreren Dimensionen:

1. Kontext-Erfassung

Systematisches Identifizieren, welche Informationen für eine Aufgabe relevant sind. Aus Dokumenten, Datenbanken, APIs, Wissensgraphen.

2. Kontext-Strukturierung

Informationen so aufbereiten, dass das Modell sie effektiv nutzen kann. Das bedeutet oft: Chunking, Embeddings, hierarchische Strukturen, Metadaten.

3. Kontext-Selektion

Intelligentes Auswählen des relevanten Kontexts aus einer riesigen Wissensbasis. Retrieval-Augmented Generation (RAG) ist hier das Schlagwort.

4. Kontext-Integration

Nahtlose Einbettung des Kontexts in die Interaktion mit dem Modell – über System-Prompts, Tool-Calls, oder direkte Kontext-Injektion.

Zurück zum Maschinenbauer: Nach dem Prompt-Engineering-Desaster implementierten sie Context Engineering. Sie bauten einen Vector Store mit allen technischen Dokumentationen. Implementierten semantisches Retrieval. Strukturierten Kontext nach Produktlinien und Fehlerkategorien. Der gleiche Support-Chatbot – jetzt mit Kontext statt nur mit cleveren Prompts – erreichte eine Genauigkeit von über 95%. Ohne ein einziges Prompt-Tuning.

---

Der entscheidende Unterschied: Wie vs. Was

Der Unterschied zwischen Prompt Engineering und Context Engineering lässt sich auf eine einfache Formel bringen:

Prompt Engineering	Context Engineering
Optimiert wie man fragt	Optimiert was das System weiß
Fokus auf Formulierung	Fokus auf Informationsbereitstellung
Tricks und Techniken	Architektur und Datenpipelines
Modell-agnostisch (funktioniert überall ähnlich)	Anwendungsspezifisch (kontextabhängig)
Skaliert mit Prompt-Länge	Skaliert mit Wissensbasis
Zerbrechlich (empfindlich gegenüber Änderungen)	Robust (basierend auf Fakten)

Die entscheidende Erkenntnis: Prompt Engineering fragt „Wie sage ich es am besten?“ Context Engineering fragt „Was muss das System wissen, um eine gute Antwort zu geben?“

Das ist der Unterschied zwischen einem Schauspieler, der eine Rolle spielt (Prompt Engineering), und einem Experten, der sein Fachgebiet tatsächlich beherrscht (Context Engineering).

In der Praxis bedeutet das konkret: Ein Prompt wie „Du bist ein erfahrener Steuerberater. Erkläre mir die Vor- und Nachteile der GmbH-Gründung“ ist klassisches Prompt Engineering. Context Engineering wäre: Das Modell hat Zugriff auf die aktuellen Steuergesetze, den individuellen Finanzplan des Gründers, Branchenbenchmarks zu Kapitalgesellschaften, und relevante EuGH-Urteile der letzten Monate.

Der Context-Engineering-Ansatz liefert keine schauspielerische Performance – er liefert fundierte Beratung.

---

Praxisbeispiele für Context Engineering

Theorie ist schön, aber wie sieht Context Engineering in der echten Welt aus? Hier vier konkrete Anwendungsbereiche, die den Unterschied machen:

1. Dokumenten-Kontext im RAG

Das Szenario: Ein Rechtsabteilung will 50.000 Verträge durchsuchbar machen. Juristen sollen komplexe Fragen stellen können: „Welche unserer Lieferverträge haben Force-Majeure-Klauseln, die auf Pandemien eingehen?“

Prompt Engineering würde: Eine lange, detaillierte Anweisung formulieren, wie der Bot Verträge analysieren soll, welche Klauseltypen es gibt, wie er antworten soll.

Context Engineering macht: Baut einen semantischen Index über alle Verträge. Implementiert intelligentes Chunking (nicht einfach alle 500 Wörter, sondern bei Absatzgrenzen und Klauselanfängen). Strukturiert Metadaten (Vertragspartner, Datum, Vertragstyp). Wenn der Jurist fragt, werden nicht nur die relevanten Klauseln, sondern auch der umgebende Kontext (welcher Vertrag, welche Parteien, welches Datum) injiziert.

Das Ergebnis: Der Bot findet nicht nur die Klausel, sondern kann sagen: „In Vertrag #4711 mit Lieferant XYZ vom 15.03.2022 findet sich eine Force-Majeure-Klausel in § 12, die explizit Pandemien als Befreiungsgrund nennt. Der Vertrag läuft bis 31.12.2025.“ Das ist keine Prompt-Optimierung – das ist Context-Architektur.

2. System Instructions als Kontext-Grundgerüst

Die System Instructions – die Anweisungen, die einem KI-Modell vor der eigentlichen Konversation gegeben werden – sind ein mächtiges Context-Engineering-Werkzeug. Hier definiert man nicht, wie das Modell sprechen soll, sondern was es wissen muss.

Beispiel: Ein System für medizinische Erstberatung könnte System Instructions erhalten wie:

„Du bist ein Unterstützungssystem für medizinische Erstberatungen. Du hast Zugriff auf folgende Kontext-Informationen:

• Aktuell gültige Leitlinien der Fachgesellschaft XYZ (Stand: November 2025)
• Die Patientenakte des Anfragenden (Name, Alter, Vorerkrankungen, aktuelle Medikation)
• Das Formular der aktuellen Beschwerden, das der Patient ausgefüllt hat
• Eine Datenbank häufiger Wechselwirkungen mit Standardmedikamenten

Deine Aufgabe: Hilf dem Patienten zu verstehen, ob ein Arztbesuch dringend ist oder ob Selbstmaßnahmen ausreichen. Niemals Diagnosen stellen. Immer auf die Notfallnummer 112 hinweisen bei…“

Das ist kein Prompt. Das ist eine Kontext-Landschaft, die das Modell zu einem spezialisierten Werkzeug macht.

3. Few-Shot Context für konsistente Ausgaben

Few-Shot Learning – das Bereitstellen von Beispielen für Input/Output-Paare – ist ein Context-Engineering-Instrument. Statt dem Modell zu sagen „Formatiere das als Tabelle“, zeigt man ihm drei Beispiele, wie die Tabelle aussehen soll.

Der entscheidende Unterschied zum klassischen Prompt Engineering: Die Beispiele werden nicht irgendwie formuliert, sondern aus einer kuratierten Wissensbasis gezogen. Sie repräsentieren die „goldene Standard“-Ausgabe des Unternehmens.

Ein Versicherungskonzern könnte beispielsweise eine Bibliothek von 50 Beispiel-Schadensmeldungen pflegen – alle nach internen Qualitätsstandards formatiert. Wenn ein neuer Schaden bearbeitet wird, werden die drei ähnlichsten Beispiele aus der Bibliothek abgerufen und dem Modell als Kontext gegeben. Das Ergebnis: konsistente, qualitätsgesicherte Ausgaben, die dem Unternehmensstandard entsprechen – ohne dass jemand Prompts optimieren muss.

4. Tool Context für Agenten-Systeme

Das mächtigste Context-Engineering-Prinzip ist die Integration von Tools. Moderne KI-Systeme können nicht nur Text generieren, sondern auch Funktionen aufrufen: APIs ansprechen, Datenbanken abfragen, Berechnungen durchführen, E-Mails senden.

Die Kunst liegt darin, dem Modell den Kontext seiner Tools zu geben. Nicht nur „Du kannst eine Datenbank abfragen“, sondern:

„Du hast Zugriff auf die Kunden-Datenbank über die Funktion query_customer_db. Diese Funktion akzeptiert folgende Parameter:

• customer_id (Pflicht): Die eindeutige Kundennummer
• fields (Optional): Liste der zurückzugebenden Felder [’name‘, ‚email‘, ‚contract_type‘, ‚last_contact‘]
• date_range (Optional): Zeitraum für Kontakthistorie

Beispielaufruf: query_customer_db(customer_id='12345', fields=['name', 'contract_type'])„

Das Modell „weiß“ jetzt nicht nur, dass es eine Datenbank gibt – es versteht die Schnittstelle, die Parameter, die Nutzungsmuster. Das ist Context Engineering auf Architektur-Ebene.

---

Wann braucht man was? Eine Entscheidungshilfe

Nicht jede Anwendung erfordert vollständiges Context Engineering. Hier eine pragmatische Entscheidungshilfe:

Prompt Engineering reicht, wenn:

• Es um allgemeine Sprachaufgaben geht (Zusammenfassungen, Übersetzungen, Stilanpassungen)
• Die Aufgabe modell-agnostisch ist (funktioniert mit GPT-4, Claude, Llama gleichermaßen)
• Keine domänenspezifischen Kenntnisse erforderlich sind
• Schnelle Prototypen gebaut werden sollen
• Die Anforderungen sich häufig ändern

Context Engineering wird notwendig, wenn:

• Spezifisches Unternehmenswissen benötigt wird
• Reproduzierbare, qualitätsgesicherte Ergebnisse gefordert sind
• Die Anwendung skalieren muss (viele Nutzer, viele Anfragen)
• Compliance und Nachvollziehbarkeit wichtig sind
• Das Modell als „Experte“ fungieren soll, nicht als „Assistent“

Die meisten Enterprise-Anwendungen landen im zweiten Bereich. Wer ernsthaft KI in Geschäftsprozesse integrieren will, kommt um Context Engineering nicht herum.

---

Fazit: Die Zukunft gehört dem Kontext

Prompt Engineering war ein wichtiger Zwischenschritt. Es hat gezeigt, dass die Interaktion mit Sprachmodellen gestaltbar ist, dass man durch geschickte Formulierung bessere Ergebnisse erzielen kann. Aber es war ein Fix für ein Problem, das wir selbst geschaffen haben: dass wir den Modellen zu wenig mitgeben.

Context Engineering löst das eigentliche Problem. Es macht KI-Systeme zu Experten statt zu Schauspielern. Es schafft robuste, skalierbare, verlässliche Anwendungen statt zerbrechlicher Trickkisten.

Die Unternehmen, die 2026 und darüber hinaus führen werden, sind nicht die mit den besten Prompts. Sie sind die mit dem besten Kontext. Diejenigen, die verstanden haben: Es geht nicht darum, perfekt zu fragen. Es geht darum, dass das System überhaupt etwas zu sagen hat.

Die Ära des Prompt Engineering endet. Die Ära des Context Engineering beginnt.