Context Engineering: Die Fähigkeit, die Prompt Engineering 2026 ersetzt hat

Andrej Karpathy sagte es klar: „Prompt Engineering" ist ein irreführender Begriff. Er impliziert, dass die Kunst der Arbeit mit Sprachmodellen darin besteht, Anweisungen sorgfältig zu formulieren — den magischen Satz zu schreiben, der den richtigen Output freischaltet. Diese Sichtweise hat die eigentliche Arbeit immer unterschätzt, und 2026 beschreibt sie nicht mehr, was ernsthafte KI-Teams tatsächlich tun.

Was sie tun, ist Context Engineering: die bewusste, systematische Praxis, zur Laufzeit die richtigen Informationen im richtigen Format zum richtigen Zeitpunkt zusammenzustellen, um das Kontextfenster eines LLMs beim Inference zu befüllen. Es ist Teil Retrieval, Teil Memory-Management, Teil System-Design und Teil UX. Es ist kein Prompt. Und Teams, die es so behandeln, lassen den Großteil der Modellfähigkeiten ungenutzt.

Warum „Prompt Engineering" immer der falsche Rahmen war

Die Phrase „Prompt Engineering" stammt aus der GPT-3-Ära: Modelle waren undurchsichtig, die richtige Formulierung öffnete versteckte Fähigkeiten, und die Fertigkeit war im Wesentlichen beschwörend. Schreib den Zauber richtig und das Modell funktionierte.

Dieses Denkmodell ist aus drei Gründen zusammengebrochen:

1. Kontextfenster haben sich erweitert. Als Modelle 4K Tokens hatten, waren Prompts kurz. Bei 128K, 200K und 1M+ Tokens ist das, was man ins Fenster packt, ein System-Design-Problem, kein Schreibproblem.
2. Systeme wurden dynamisch. Moderne KI-Anwendungen verwenden keinen statischen Prompt. Sie rufen Dokumente ab, nutzen Tools, halten Speicher über Sitzungen hinweg aufrecht und verarbeiten Zwischenergebnisse. Der „Prompt" wird zur Laufzeit aus vielen Quellen zusammengestellt.
3. Das Signal hat sich verlagert. Empirisch kommen die größten Performance-Unterschiede zwischen Teams aus der Kontextqualität, nicht aus der Prompt-Formulierung. Dasselbe Modell mit besserem Kontext übertrifft konsistent ein größeres Modell mit schlechtem Kontext.

Die sechs Schichten des Kontexts

Context Engineering bedeutet, bewusst über sechs verschiedene Komponenten nachzudenken, die das Kontextfenster eines Modells beim Inference belegen können:

• Schicht 1 — System-Prompt und Anweisungen. Rollendefinition, Aufgabenbeschränkungen, Output-Formatspezifikation, Tool-Schemata. Dies ist fest und relativ klein — typischerweise 5–10% des Budgets.
• Schicht 2 — Few-Shot-Beispiele. Input/Output-Demonstrationen, die Format, Ton und Edge-Case-Behandlung verankern. Gute Few-Shots erledigen zuverlässiger Arbeit als aufwändige Anweisungsabsätze.
• Schicht 3 — Working Memory und State. Das Scratchpad des Agenten: Zwischenüberlegungen, Aufgabenfortschritt, strukturiertes Output-Schema. Diese Schicht wächst während einer Aufgabe und benötigt aktives Management.
• Schicht 4 — Abgerufene Dokumente (RAG). Externes Wissen, das zur Inference-Zeit abgerufen wird: Vektorsuchergebnisse, Datenbankabfragen, Codebase-Snippets, Echtzeit-Daten.
• Schicht 5 — Tool- und Action-Ergebnisse. Die Ausgabe von API-Aufrufen, Code-Ausführung, Suche und anderen Tool-Aufrufen. Diese sind oft ausführlich und benötigen Kürzung oder Zusammenfassung.
• Schicht 6 — Gesprächsverlauf. Vorherige Turns, zusammengefasstes Gedächtnis und persistierte Benutzerpräferenzen. Lange Gespräche erfordern Komprimierungsstrategien.

Die wichtigste Erkenntnis: Ein „Prompt" ist bestenfalls Schicht 1. Context Engineering ist die Praxis, alle sechs Schichten gleichzeitig innerhalb eines endlichen Token-Budgets zu verwalten.

Kontextqualität schlägt Modellgröße

Der praktisch wichtigste Befund in der Context-Engineering-Literatur ist auch der kontraintituitivste: Ein kleineres Modell mit gut entwickeltem Kontext übertrifft routinemäßig ein größeres Modell mit schlechtem Kontext.

Dies wurde über mehrere Benchmarks hinweg demonstriert. In Code-Generierungsaufgaben übertrifft GPT-4o mit sorgfältig kuratierten Few-Shots und relevantem Codebase-Kontext o3 mit einem generischen System-Prompt. In Enterprise-RAG-Deployments erzeugt der Wechsel von naivem Full-Document-Retrieval zu semantischem Chunking mit Re-Ranking größere Genauigkeitsgewinne als ein Modell-Upgrade.

«Wir verbrachten drei Monate damit, verschiedene Modelle auszuprobieren. Ein Sprint für Kontextqualität brachte uns die gleichen Gewinne, die wir ein Quartal lang gesucht hatten.» — Entwickler auf Hacker News

Das Kontext-Budget: Tokens als endliche Ressource behandeln

Die nützlichste mentale Modellverschiebung im Context Engineering ist, Tokens als Budget zu behandeln. Das Kontextfenster ist eine knappe Ressource. Alles, was hineinkommt, verdrängt etwas anderes.

Budget-Management-Techniken, die wiederholt in Produktionssystemen erscheinen:

Gestuftes Retrieval

Keine vollständigen Dokumente abrufen. Eine zweistufige Pipeline verwenden: Ein schnelles, günstiges Retrieval-Modell wählt Kandidaten aus; ein Cross-Encoder-Re-Ranker wählt die relevantesten Passagen. Ein Top-5 re-geranktes Ergebnis enthält typischerweise mehr Signal als ein Top-20-naives Retrieval bei einem Bruchteil der Token-Kosten.

Progressive Zusammenfassung

Gesprächsverlauf und Zwischenzustand wachsen ohne Grenzen, wenn sie nicht verwaltet werden. Das Produktionsmuster ist die Zusammenfassung nach einem Schwellenwert — typischerweise nach jedem N-ten Turn oder wenn die Geschichte X Tokens überschreitet.

Dynamische Few-Shots

Wenn Sie eine Bibliothek von 200 Beispielen haben, rufen Sie die 3–5 ab, die dem aktuellen Input semantisch am ähnlichsten sind. Diese Technik — Retrieval-augmentierte Few-Shot-Auswahl — ist eine der effektivsten Kontext-Optimierungen.

Das Retrieval-Qualitätsproblem

RAG ist dort, wo das meiste Production-Context-Engineering scheitert. Häufige Fehler:

Chunk-Grenzfehler

Feste Chunking-Größen teilen semantisch kohärente Passagen oft über Chunks auf und liefern halbe Antworten zurück. Dokumentbewusstes Chunking — Splitting an Abschnittsgrenzen, Absätzen oder semantischen Einheiten — übertrifft konsistent festes Chunking.

Fehlender Kontext für abgerufene Chunks

Anthropics «Contextual Retrieval»-Technik stellt jedem Chunk beim Indexieren eine chunk-spezifische Kontextzusammenfassung voran. In ihren Benchmarks reduzierte dies Retrieval-Fehler um 49% in Kombination mit Re-Ranking.

Query-Dokument-Mismatch

HyDE (Hypothetical Document Embeddings) adressiert dies, indem es eine hypothetische Antwort auf die Abfrage generiert und diese einbettet, anstatt die rohe Abfrage einzubetten.

Was zuerst gebaut werden sollte

Die Prioritätsreihenfolge für Context-Engineering-Investitionen basierend auf beobachtetem ROI in Produktionssystemen:

1. Retrieval-Pipeline prüfen. Von festen zu semantischen oder dokumentbewussten Chunks wechseln. Einen Re-Ranking-Schritt hinzufügen.
2. Gesprächszusammenfassung implementieren. Gesprächsverlauf auf ein Token-Limit begrenzen und zusammenfassen, wenn es überschritten wird.
3. Dynamisches Few-Shot-Retrieval hinzufügen. Eine kleine Bibliothek hochwertiger Beispiele aufbauen. Zur Inference-Zeit die Top-3 abrufen, die dem aktuellen Input am ähnlichsten sind.
4. Agenten-State externalisieren. Wenn Sie Multi-Agenten-Systeme bauen, sollten Sie Zwischenzustand von Anfang an in strukturierte externe Stores verschieben.
5. Kontextqualität instrumentieren. Logging für Kontextfenster und Ergebnisse hinzufügen.

Der tiefere Punkt

Context Engineering ist keine Technik. Es ist eine Perspektivverschiebung: vom Behandeln von Sprachmodellen als Textgeneratoren, die auf Anweisungen reagieren, hin zum Behandeln als Inference-Engines, deren Performance durch die Qualität der zur Laufzeit bereitgestellten Informationen begrenzt wird.

Die Modelle sind bereits fähig genug für das meiste, was Teams zu bauen versuchen. Die Lücke zwischen dem, was Teams erreichen, und dem, was möglich ist, ist fast immer eine Kontext-Lücke. Diese Lücke ist ein Engineering-Problem. Und wie alle Engineering-Probleme reagiert sie auf systematische Investitionen.

Der Zauber waren nie die Worte. Es waren immer die Informationen dahinter.