Context Engineering: Die Fähigkeit, die Prompting ablöst

Ein Kunde schreibt dem KI-Chatbot eines Fahrradladens: "Ist das E-Bike bis Freitag lieferbar?" Der Bot antwortet freundlich: "Ja, üblicherweise liefern wir innerhalb von 3 bis 5 Werktagen." Das Modell ist seit zwei Wochen ausverkauft. Das steht im Lagerbestand, nur hat niemand dem Bot den Lagerbestand gezeigt.

Kommt dir das bekannt vor? Der Prompt war nicht schlecht. "Beantworte Kundenanfragen freundlich und korrekt" steht sogar in der Systemanweisung. Das Problem liegt woanders. Der Bot hatte im Moment der Antwort schlicht keinen Zugriff auf die Information, die er gebraucht hätte.

Genau das beschreibt Context Engineering, zu Deutsch etwa Kontextgestaltung. Es geht nicht mehr nur darum, wie du eine Frage formulierst. Es geht darum, was das Modell in dem Moment sieht, in dem es antwortet.

Context Engineering ist die Fähigkeit, die Prompting abgelöst hat

Prompt Engineering ist das Schreiben einer guten Anweisung. Rollenbeschreibung, Beispiele, klare Grenzen wie "antworte in maximal drei Sätzen". Das funktioniert immer noch und bleibt wichtig.

Context Engineering ist eine Ebene darüber. Anthropic beschreibt es als die Strategie, bei jeder einzelnen Anfrage an ein Modell genau die Informationen bereitzustellen, die es für diesen einen Schritt braucht, nicht mehr und nicht weniger. Es umfasst den Prompt, aber auch alles andere, was das Modell bei einer Anfrage zu sehen bekommt: den Lagerbestand des Fahrradladens, die letzten drei Nachrichten des Kunden, die Rückgaberichtlinie, die Werkzeuge, die der Bot aufrufen darf. Ein Prompt ist eine Zeile. Context Engineering ist das ganze System drumherum.

Und dann gibt es noch eine dritte Stufe, die gerade an Fahrt aufnimmt: Loop Engineering. Dabei geht es nicht mehr darum, eine einzelne Anfrage gut zu beantworten, sondern ein System zu bauen, das sich selbst wiederholt anstößt, prüft und korrigiert. Dazu später mehr, denn genau das macht Boris Cherny bei Claude Code inzwischen hauptberuflich.

Diese drei Stufen bauen aufeinander auf. Ein schlampiger Prompt in einem sauber gestalteten Kontext liefert trotzdem mittelmäßige Ergebnisse schneller. Aber die Stellschraube, an der sich am meisten drehen lässt, hat sich verschoben. Weg vom einzelnen Satz, hin zu dem, was drumherum passiert.

Das Kontextfenster ist kein größerer Ordner

Jedes Sprachmodell hat ein Kontextfenster, also die Gesamtmenge an Text, die es in einem Moment verarbeiten kann. Das schließt alles ein, was du hineinschickst (Systemanweisung, deine Nachricht, angehängte Dokumente) und alles, was das Modell zurückschickt. Reicht das Fenster nicht mehr aus, bricht die Anfrage ab oder das Modell "vergisst" den Anfang der Unterhaltung.

Die Grenze wird in Tokens gemessen, kleinen Textbausteinen, grob ein bis vier Zeichen pro Token. Aktuell haben Opus 4.8, Sonnet 5 und Fable 5 ein Kontextfenster von 1 Million Tokens, Haiku 4.5 kommt auf 200.000 Tokens. Ein Fenster von einer Million Tokens klingt nach viel, das sind ungefähr 750.000 Wörter, ein mittelgroßes Softwareprojekt oder ein Jahr Chatverlauf auf einmal.

Nur: Größer ist nicht automatisch besser. Warum, das steht im nächsten Abschnitt.

Warum ein volleres Kontextfenster nicht zu besseren Antworten führt

Modelle haben ein bekanntes Problem beim Abrufen von Informationen aus einem großen Kontext, ähnlich der Suche nach einer Nadel im Heuhaufen. Eine Stanford-Studie von Liu und Kollegen zeigte das schon früh: Bei 20 abgerufenen Dokumenten kann die Genauigkeit von 70 bis 75 % auf 55 bis 60 % fallen, je nachdem, wo im Kontext die relevante Information steht.

Informationen am Anfang und am Ende einer Unterhaltung bekommen vom Modell mehr Aufmerksamkeit als das, was in der Mitte steht. Das nennt man Lost-in-the-Middle-Effekt. Menschen ticken übrigens ähnlich, das kennst du vielleicht als Primacy- und Recency-Effekt: An den Anfang und das Ende eines Vortrags erinnerst du dich meist besser als an die Mitte.

Der Entwickler und Analyst Drew Breunig hat das Problem in vier Muster aufgeteilt, die zusammen unter dem Begriff Context Rot bekannt wurden:

• Context Poisoning: Eine Halluzination landet im Kontext und wird von da an immer wieder als Fakt behandelt.
• Context Distraction: Der Kontext ist so lang geworden, dass das Modell sich an ihm festbeißt, statt einen frischen Plan zu machen.
• Context Confusion: Überflüssige Informationen lenken das Modell in die falsche Richtung.
• Context Clash: Zwei widersprüchliche Informationen liegen im selben Kontext, das Modell entscheidet sich für die falsche.

Zurück zum Fahrradladen: Wenn der Bot Zugriff auf drei verschiedene, teils veraltete Preislisten hat, ist das ein klassischer Context Clash. Die Lösung ist nicht ein längerer Prompt, sondern ein aufgeräumterer Kontext.

Karpathy: Dein Kontextfenster ist dein Programm

Im April 2026 hielt Andrej Karpathy, Mitgründer von OpenAI und ehemaliger KI-Chef bei Tesla, bei der Sequoia-Konferenz AI Ascent einen Talk, der zur meistgesehenen Session der Konferenz wurde. Sein Rahmen: Software 3.0. Bei Software 1.0 schreiben Menschen expliziten Code. Bei Software 2.0 trainieren Menschen neuronale Netze mit Daten. Bei Software 3.0 programmieren Menschen Modelle über Kontext, sprich über Prompts, Werkzeuge, Beispiele und Anweisungen.

Schon 2025 hatte Karpathy den Begriff in einem vielzitierten Beitrag zugespitzt: "Context engineering is the delicate art and science of filling the context window with just the right information for the next step." Auf Deutsch: Context Engineering ist die feine Kunst und Wissenschaft, das Kontextfenster mit genau der richtigen Information für den nächsten Schritt zu füllen.

Stell dir das Modell wie einen Prozessor vor und das Kontextfenster wie den Arbeitsspeicher. Ein Betriebssystem entscheidet, was gerade in den Arbeitsspeicher passt und was warten muss. Context Engineering übernimmt genau diese Aufgabe für ein KI-Modell.

Die vier Hebel: Write, Select, Compress, Isolate

Aus dieser Denkweise hat das Entwicklerteam von LangChain vier Techniken destilliert, die inzwischen als Standardwortschatz für Context Engineering gelten.

Write heißt, Notizen außerhalb des Kontextfensters zu speichern. Statt jede Zwischeninformation in die nächste Anfrage zu quetschen, landet sie in einer Datei oder einem Notizzettel, den der Agent bei Bedarf wieder aufruft.

Select heißt, nur das zu holen, was gerade gebraucht wird. Für den Fahrradladen-Bot heißt das: nicht der komplette Produktkatalog, sondern nur der Lagerbestand des einen Modells, nach dem gefragt wurde.

Compress heißt, lange Verläufe zusammenzufassen, sobald sie zu groß werden. Die letzten fünf Nachrichten bleiben im Original, alles Ältere wird zu einer Kurzfassung verdichtet.

Isolate heißt, Teilaufgaben in eigene, saubere Kontexträume zu packen. Ein Unteragent liest die Bestelldaten, ein zweiter prüft die Rückgabefrist, ein dritter formuliert die Antwort. Jeder bekommt nur das, was er für seinen Teil braucht. Am Ende gibt er nur eine kurze, verdichtete Antwort zurück statt seines kompletten Arbeitsverlaufs.

Wenn du mit KI-Agenten arbeitest, sind das genau die vier Stellschrauben, an denen sich die Qualität deiner Ergebnisse entscheidet, nicht der ursprüngliche Prompt.

So siehst du deinen Kontext in Claude Code

Theorie ist schön, aber wie sieht das konkret aus, wenn du mit Claude Code arbeitest? Der Befehl /context zeigt dir genau, wie voll dein Kontextfenster gerade ist. Bei einer Unterhaltung mit 200.000 Tokens Limit siehst du zum Beispiel: 95.000 von 200.000 Tokens verbraucht, davon rund 8 % Systemanweisung und 40 % die bisherige Unterhaltung. Der Rest ist noch frei.

Ab wann solltest du eingreifen? Eine grobe Faustregel: Bei unter 50.000 freien Tokens wird es eng. Dann hast du zwei Optionen:

• /clear leert die Unterhaltung komplett und gibt dir eine leere Seite zurück. Gut, wenn du zu einer neuen, unabhängigen Aufgabe wechselst.
• /compact fasst die Historie zu einer Zusammenfassung zusammen, aus 70.000 Tokens Nachrichtenverlauf werden dann zum Beispiel noch 4.000. Gut, wenn du an derselben Aufgabe weiterarbeitest und die bisherige Absicht behalten willst.

Details zu beiden Befehlen und wann du welchen brauchst, stehen im Claude Code Tutorial.

Eine Warnung noch: MCP-Server, die externe Werkzeuge anbinden, sind praktisch, aber sie füllen dein Kontextfenster erstaunlich schnell. Jedes angebundene Werkzeug bringt seine Beschreibung mit. Die liegt permanent im Kontext, egal ob du sie gerade brauchst oder nicht. Halte deine claude.md deshalb bewusst schlank. Eine große Regel-Datei kostet dich nicht nur Tokens, sie erhöht auch das Risiko, dass wichtige Regeln im Lost-in-the-Middle-Effekt untergehen.

Cherny: "Ich promptete Claude nicht mehr"

Boris Cherny hat Claude Code gebaut und nutzt es täglich. In mehreren Interview-Ausschnitten, die sich im Juni 2026 rasant über die Entwicklerszene verbreiteten, beschrieb er, wie sich seine eigene Arbeit verändert hat: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." Sinngemäß: Er prompte Claude nicht mehr selbst, sondern lässt Loops laufen, die das für ihn übernehmen und entscheiden, was zu tun ist. Seine eigentliche Aufgabe sei es, diese Loops zu schreiben.

Das ist Context Engineering, nur einen Schritt weitergedacht. Ein Loop übernimmt bei jedem Durchlauf genau die vier Hebel von eben: Er schreibt Zwischenergebnisse in eine Datei (Write), lädt beim nächsten Lauf nur das Relevante (Select), fasst alte Durchläufe zusammen (Compress) und gibt Teilaufgaben an eigene Unteragenten weiter (Isolate). Läuft dieser Kreislauf ohne saubere Kontextgestaltung, produziert er einfach schneller Mittelmaß statt guter Arbeit.

Chernys wichtigster Hinweis dazu betrifft nicht den Prompt, sondern die Prüfung:

Ein Loop, der seine eigene Arbeit verifizieren kann, etwa durch einen Test, der grün oder rot zurückmeldet, verbessert die Ergebnisqualität nach seiner Einschätzung um das Zwei- bis Dreifache. Ohne diese Prüfung stimmt ein Loop im Zweifel nur mit sich selbst überein, wieder und wieder. Wie du solche Prüfmechanismen für eigene KI-Agenten aufbaust, zeigt der Artikel zu KI-Agenten mit Evals testen. Und wie du das konkret als wiederkehrenden Ablauf in Claude Code einrichtest, also mit /loop und Hooks, steht ebenfalls im Claude Code Tutorial.

Was Context Engineering nicht löst

Ein sauber gestalteter Kontext senkt die Fehlerquote deutlich. Er beseitigt sie nicht. Ein Modell kann trotz bestem Kontext etwas erfinden, das nirgendwo in den Daten stand. Deshalb bleibt der Verifier aus dem letzten Abschnitt kein optionales Extra, sondern die letzte Absicherung.

Und mehr Kontext ist, wie du jetzt weißt, nicht automatisch die Lösung. Eine 200 Zeilen lange claude.md, in der jede Zeile wirklich gebraucht wird, schlägt eine 2.000 Zeilen lange Textwüste, die kaum jemand liest, auch das Modell nicht wirklich.

Und die Fähigkeit selbst ist neu. Die meisten Teams haben sie noch nicht. Es geht nicht darum, hübschere Sätze zu formulieren, sondern darüber nachzudenken, was ein Modell in einem bestimmten Moment tatsächlich sehen muss, um seine Aufgabe zu lösen. Das ist eine andere Denkweise als klassisches Prompten. Sie lässt sich lernen, aber eben nicht in einem Nachmittag.